I mentioned the problem with hotkeys before. Now I find another one. Poser 5 apparently no longer exports figure names to obj files. HOW DID THAT HAPPEN??

Figure Circle. In P4, you can turn it off ... and it stays off.

Crosstalk. Some clothes use Crosstalk to fit your character (example: the DAZ Ultra Bodysuits. Poser 5 eliminated Crosstalk. Now the clothes won't fit properly.

I only use Poser 5. My copy exports figure names to object files. I have turned off my figure circle, and it has been off for a year now. Crosstalk was an error in Poser 4. Someone exploited the error to make a model work. Then they fixed the error in Poser 5, now you complain that the model doesn't work.

Which version are you using, numanoid ... Mac or PC?

PC. With latest service pack and a clean install.

Hmmm. * starts comparing default scene files *

Actually I'm complaining because people can't fix the items so they don't rely on Crosstalk to work.

Actually Bobbie, it's more that "most" people WON'T fix the items to not rely on crosstalk, rather than can't. When it works, it's a great feature to have - almost making up for Poser's complete lack of "expressions". When it starts doing things you DON'T want (such as when there are multiple V3's in the scene) - it's the bug from hell. The biggest problem I see with crosstalk is that there are some big figures in the industry (DAZ & some artists) that rely too much on JCM's for fixing bad joint parameters. As such, developers need to add JCM's to clothing which will only work with crosstalk, copying poses, or manual dial tweaking. All of which are unacceptable...

Show Origin for props doesn't actually allow you to adjust the position of the origin, the way it did in P4. In P4, switching geometry would filter morphs so that the only morphs displayed were the ones that would work on the particular geometry being displayed at the time. P5 shows all morphs for all geometries regardless of whether they work with the geometry being used.

Good thread, but I'm sure the list would be longer if you listed the things P5 can do that P4 can't. Just a thought.

Well, of course it would, but the point is that something that worked correctly in version X shouldn't be broken in version X+1. So how does numanoid get figure names in obj files when I just get Figure_1 etc?

Attached Link: http://secure.daz3d.com/shop.php?op=itemdetails&item=1305

Well, I still am not quite sure what is "broken". But then again, my GIF animator that came out in 1988 won't work on XP. It worked correctly in version x, but not version x+1. There are many things that don't work in newer programs. Vue 3 files won't work in VuePro. That doesn't mean VuePro is broken, does it? No, it just means that newer programs may use different methods to achieve results, and sometimes they have to lose some of the old, and often outdated functionality, to get the new functions. I started on Poser 5. I never used Poser 4. I have not missed any of these "amazing" functions that Poser 4 was supposed to have. But I will sure miss all the functions in Poser 5 if I had to go back to version 4. I will try to see about the figure names thing when I get home.

Softriver is pretty close -- the choice is "include figure names in polygon groups" -- and it works everytime for the team here in P5. We will have ynsaen look at the Show Origin function, and would request a link or repost of the hotkeys info.

Heh, sorry... I didn't realize I had the internal names box hi-lighted... my arrow was for the figure names line. Thanks for the heads up, OddDitty. ;)

Hey OddDitty, As long as you're having Ynsaen look at things, you might ask her to look at the scale parameters on the 3D texture nodes in the material room. Logically, if you have, for example, yscale of the turbulence node set to 4 and you connect a constant value of O.5 into it's input, the turbulence node should behave as though it's yscale were set to 2 (2=4*0.5). It doesn't work though. Something weird happens with most of the parameter inputs on the 3D texture nodes.

Ah no, the x/y/z_scale inputs of turbulence (and I think fBM and fractal_sum too) don't work that way. If you don't have anything plugged into them, they use the xyz coordinates as input, multiplied by the factors - which are of course varying over a surface. If you plug something into them, they take that input value instead of the xyz coordinates. For example you can plug the u and v variables into them to fix the texture to your object's uv coordinates instead its position.

Message edited on: 08/26/2004 08:05

Eternl night wrote "some big figures in the industry (DAZ & some artists) that rely too much on JCM's for fixing bad joint parameters." While I don't consider myself a "big figure" , have you ever tried doing a JCM? Trust me it is MUCH easier to tweak a joint parameter than to make a JCM. I'll only make one if I have absolutely no other way of getting rid of the pokethru, they are hell to make. I have spent days making a JCM for a Michael3 pant, it would have been much easier for me to tell the user hey make the thigh invisible why don't you! The coding part is easy enough, but the actual modelling of them is not.And while some people consider that ERC is a hack, in my opinion it was one of the great advancements in poser clothing. Curious Labs could have fixed it so that ERC worked in P5 while eliminating cross talk between figures. Clothes makers have begged them to do so, but they have been deaf to our pleas, it's not just the artists but Curious labs who should listen to the user base, because the more content there is and the easier said content is to use, the more copies of their software they are likely to sell. Unless of course P5 users prefer to manually adjust multiple body morphs on clothing to match the figures every movement, instead of it adjusting itself automatically, but somehow I think the average user would rather it be automatic.

I believe Curious Labs has more interest in dynamic clothing than in those crosstalk/JCM issues. At least, I've seen no changes in JCM behavior and functionality over the different service packs, while the cloth room functionality has been greatly improved. With dynamic cloth, you don't have to worry about crosstalk and morph adjustments. I believe conforming clothing using ERC is a deprecated feature. What I consider a major flaw in the Poser CR2 structure is the lack of a "thisFigure" keyword. There is a "conformingTarget" keyword, which is useful when creating ERC stuff, but a "thisFigure" would effectively eliminate all crosstalk problems without losing crosstalk functionality. Another major flaw in the internal workings of Poser: it isn't really designed to work with multiple figures. The figure/prop list is not maintained in a hashtable or dictionary, it's based on the order of addition to the scene. This is a major cause of the crosstalk problems. I'm rather disappointed at DAZ since none of their stuff uses P5 features. While I fully understand their wish to make P4 compatible stuff, it isn't too hard to add P5 features (better materials, Face Room compatibility, grouped dials, hierarchic folder structure) without breaking P4 compatibility. A few of the merchants here support both P4 and P5, it can be done!

Something I'm not sure about: when you parent a figure to another figure in P5, you can't unparent it anymore - that's a bug. It should be possible to parent the figure to UNIVERSE again. I don't know how P4 handles parented figures.

Having done some of the work on them thar nodes and stuff, I'll bet stewer's got a purty good idea baout the behavior you're seeing, Ajax. It also happened to explain something to me that I was wondering about, lol Also, just real quick, I'd like to point out that JCM's do work in Poser 5. They work as originally hacked, and JCM's are a wonderful advance. Careful study of the Poser 5 figures will reveal some mighty interesting things about Poser 5 and JCMs. However, superconforming -- that magical ability of clothing to assume the jcm's of the figure to which it is conformed -- is based on crosstalk, and crosstalk is a bug. Since this was not developed by the company itself, that makes it a Hack -- which doesn't mean it's a good thing or a bad thing, just a different thing, and a thing that will probably not work with future versions of Poser, either. There are about 60 hacks for Windows 3.1 that I happen to love to death that were "ignored" by microsoft, and there are a few for Macintosh that seem to have been left out of OSX, and some nice ones for Linux that different distributions don't seem to want to include. Expecting a company to support something they didn't develop is sorta like expecting a merchant who doesn't make things for Poser 5 to support Poser 5 -- both cases are rather silly, and will simply get you more frustrated. You can try, and sometimes it will happen and sometimes it won't. And JCM's really are a lot harder to make work right than JP tweaks. As for parenting props, you can unparent anything that is not dynamic -- but once a dynamic prop has a simulation on it, it get's sorta glued to the parent. However, you can save it "unglued". To unparent, go to the properties panel, click parenting, and select universe again. It does work -- just did it three times on different things to be sure :) I'm off to piddle with show origin and hotkeys -- really could use a list of broke hotkeys, though (I'm terrible -- nevah use 'em)

Parenting and unparenting props works fine, no problem. But when I have used the "Set Figure Parent" command on the Figure menu, I have to hack the PZ3 to unparent the figure.

ahhhh!!!! ok. Figure parenting... mumbles to self about maybe paying closer attention next time and wanders off to play with figures and parents and children and interns...

softriver, OddDitty - no that doesn't work at all for me. I just tested again. Open Poser 5; create a figure (Posette); rename figure "Girl"; export obj file with "include figure names in polygon groups"; open obj file in text editor; search for string "Girl"; it's not there - "Figure_2" is there instead.

With regard to crosstalk: There actually is a line in the ERC code that should tell a slave dial which figure to take as it's master. That line doesn't work. Poser just ignores it. In Poser 4 that caused crosstalk. In Poser 5 it causes Poser to always take the figure containing the slave as the master, regarless of which figure has actually been specified as master. So the problem has changed, but either way it doesn't work the way it should. I guess the reason they did that is that, since figure names are assigned dynamically, it would be near impossible to come up with a way to make the line for specifiying the master figure work. However, surely it wouldn't have been so hard to permit crosstalk between figures when one is conformed to the other.

Stewer, Thanks for that info on the 3D node scale inputs. I've been looking for a way to make them use a sample other than the unmodified xyz, so this'll be really useful. More useful than just being able to control the scale in fact :-)

About figure naes when exporting to OBJ: Daz1971 found out that Poser 5 DID export the right names in SR1 and SR2, but since SR3 it's Figure_1, FIgure_2 and so on. Apparently a new bug.. But since SR3 and especially SR4 fix more things than they break, I'll stick with SR4...

Awesome! Just been trying it and I can finally animate turbulence the way I've always wanted to. You don't know a way to control the sample point for the clouds node do you? Not being able to animate clouds is another one that really annoys me.

.

Ok, yep, it does not work the way it used to work. Now to adjust origin, you have to open the jP panel, fiddle a sec, then then scroll down in the paramters palette to get to the origin wheels. just fixed a new plant I made using it (and I'm really glad you made me find this -- I would not have fixed it properly if you hadn't said something...) no picture, I'm afraid. Already got more to do tonight than I can stand, lol

ynsaen: do you use a Mac? Because on Windows XP Pser 5 WILL change the name to Figure_xxx, I just tried the exact settings you show here. No VickiTest - and yes, I confirmed the name using Enter, it's easy to see in the dialog title - but Figure_2. Beats me!

nope, all my boxes here are XP now (though only one is SP2 at this point) with Poser. WOuld love to have a mac here, though. anyone want to send one? It's got me stumped, svdl. THere's got to be something between us that isn't being done the same. multiple figures, perhaps? Are conforming clothing items involved (they are an additional figure, after all)? (is very strange)

I used one Vicki 2 figure (but she's also wearing a clothing prop). I tried exporting figure only, without universe, and I tried exporting including the universe. No difference - it remains Figure_2. Got to try this on my other box, but first I'm going to bed.

I loaded a figure. Changed the name from Figure 1 to Ammocrate.

Where is it that you people see the Figure 1 after export?

Open up the .OBJ using a text editor, or import it into another program (I see this problem when importing into 3D Max). There you'll find the Figure_xxx - or maybe the figure name.

OK, I see what you mean. I have never needed to export the figure with checking all those other things, because it would be quite useless without all the body part names and things. I export to UVMapper, Wings, Cinema4D and ZBrush, and have never ever seen the figure 1 thing before, I always just have the name of the .obj file (which I type in on export) as the object name, and then the names of the various object groups. Why is this such a problem? I don't understand? When do you need to export that you end up with Figure 1 as the object name? I am really quite confused here?

Well, try exporting a complete scene as an OBJ and then run it through Grouper to get it into Bryce. It is extremely useful to have the correct figure names there! For importing into Max it's merely a nuisance, then I only import a single figure, not a complete scene, and renaming is easy.

That's odd. I import entire scenes into Vue, and I have never had a problem there with figure names. Still, that's besides the point, it is still a bug that should have been fixed, which is what this thread is all about. Thanks for explaining.

svdl is right - it's important when exporting to Bryce. Vue is different as it reads the pz3. It's actually worse for me because I have a huge bank of saved map files for Grouper which are now useless as they reference the correct figure names. In fact, since Poser 5 now allocates the X in Figure_X dynamically, I can't even edit the map files or make new ones. This is a major headache. I'm having to switch back to Poser 4 for a current project.

You don't know a way to control the sample point for the clouds node do you? Not being able to animate clouds is another one that really annoys me. Not directly, no. Let mee see if I can find a good cloud procedural based on fBm or turbulence, that could be a substitute.

Thanks again, stewer.