But? loool after all these years, there's still treasures waiting to be discovered and/or highlighted...

Materials can be animated, a master dial can control material values. It's probably a master dial driving an HSV value.

WooHoo!!!

A small drawback of driving material properties with special magic dials is that as soon as a new material is loaded, those dials will just sit there useless because the parameters they were driving no longer exist. I think there's a chance to circumvent that by using well-designed materials plus a little bit of trickery, but I'll have to investigate. I'll probably put my material setup into the beta either way and see what people think.

Also, regarding the problem I mentioned with the pose symmetry (where Poser thinks arm pose symmetry includes leg pose symmetry but not vice versa) I have absolutely no idea what to look for, so I might just ask in the technical forums once the beta is out and see if any of the experts have an idea. That said, if you consider yourself an expert, feel free to investigate Antonia 1.2 right now, because she's got that same issue and Antonia 1.3 only inherited it. Also, I still haven't purchased P11 and am a little bit behind on P12, so it's entirely possible that the problem disappears in the latest version of either or both.

So now I'm watching the DAZ announcement video for G9 while working on Antonia, as one does. What can I say, I enjoy watching Jay Versluis. He's quite soothing.

Playing with the new bump dial...

odf posted at 9:59 PM Wed, 21 September 2022 - #4444993

A small drawback of driving material properties with special magic dials is that as soon as a new material is loaded, those dials will just sit there useless because the parameters they were driving no longer exist. I think there's a chance to circumvent that by using well-designed materials plus a little bit of trickery, but I'll have to investigate. I'll probably put my material setup into the beta either way and see what people think.

(...and obviously how it should work, but one never knows with Poser, and also, I have to admit my mental model of how dependencies work may have been a bit twisted up. :blush:)

How is this for a Pinocchio morph? The whole truth and nothing but the truth on the left, Toni's default conk in the middle. 

Are you preparing something for Renderotica?

Are you preparing something for Renderotica?

Y-Phil posted at 6:29 AM Thu, 22 September 2022 - #4445026

Are you preparing something for Renderotica?

Not specifically. Why do you ask?

The old joke as to why Snow White got kicked out of the magic kingdom?

I won't reiterate it here.

odf posted at 10:06 PM Wed, 21 September 2022 - #4444995

Also, regarding the problem I mentioned with the pose symmetry (where Poser thinks arm pose symmetry includes leg pose symmetry but not vice versa) I have absolutely no idea what to look for, so I might just ask in the technical forums once the beta is out and see if any of the experts have an idea. That said, if you consider yourself an expert, feel free to investigate Antonia 1.2 right now, because she's got that same issue and Antonia 1.3 only inherited it. Also, I still haven't purchased P11 and am a little bit behind on P12, so it's entirely possible that the problem disappears in the latest version of either or both.

For Nova i made a script to do pose symmetry. It is completely agnostic on hierarchy so it works on Antonia also. It currently does only complete left-and-right swaps but could easily add a filter and share if you want. As said I to not expect the devs will give this high priority.

Are you preparing something for Renderotica?

Y-Phil posted at 6:29 AM Thu, 22 September 2022 - #4445026

Are you preparing something for Renderotica?

Fuck knows.  :D

odf posted at 10:06 PM Wed, 21 September 2022 - #4444995

Also, regarding the problem I mentioned with the pose symmetry (where Poser thinks arm pose symmetry includes leg pose symmetry but not vice versa) I have absolutely no idea what to look for, so I might just ask in the technical forums once the beta is out and see if any of the experts have an idea. That said, if you consider yourself an expert, feel free to investigate Antonia 1.2 right now, because she's got that same issue and Antonia 1.3 only inherited it. Also, I still haven't purchased P11 and am a little bit behind on P12, so it's entirely possible that the problem disappears in the latest version of either or both.

Pose symmetry problems with Antonia 1.2 still exist in P12. Guess it has to do with the hierarchy where hip is a child of waist and waist is the top body part. Poser relies on specific naming of the bones and makes certain assumptions on the hierarchy. For me this became clear with the Nova figure. I raised a bug report but I can imagine it does not have high priority for the developers. I did not realize the issue also held for Antonia.

If I had an oracle to tell me which assumptions, specifically, I was violating, I'd have a chance to do something about it. But oracles are hard to come by these days, so I guess I'll just have to let it go.

odf posted at 10:06 PM Wed, 21 September 2022 - #4444995

Also, regarding the problem I mentioned with the pose symmetry (where Poser thinks arm pose symmetry includes leg pose symmetry but not vice versa) I have absolutely no idea what to look for, so I might just ask in the technical forums once the beta is out and see if any of the experts have an idea. That said, if you consider yourself an expert, feel free to investigate Antonia 1.2 right now, because she's got that same issue and Antonia 1.3 only inherited it. Also, I still haven't purchased P11 and am a little bit behind on P12, so it's entirely possible that the problem disappears in the latest version of either or both.

For Nova i made a script to do pose symmetry. It is completely agnostic on hierarchy so it works on Antonia also. It currently does only complete left-and-right swaps but could easily add a filter and share if you want. As said I to not expect the devs will give this high priority.

The script works well. I have a copy. Perhaps this isn't a bad idea, including a customized version of the script (as FVerbaas proposes) with the runtime and a little note for Poser tech heads. A frill, but maybe useful to someone.

FVerbaas posted at 4:32 PM Thu, 22 September 2022 - #4445059

odf posted at 10:06 PM Wed, 21 September 2022 - #4444995

Also, regarding the problem I mentioned with the pose symmetry (where Poser thinks arm pose symmetry includes leg pose symmetry but not vice versa) I have absolutely no idea what to look for, so I might just ask in the technical forums once the beta is out and see if any of the experts have an idea. That said, if you consider yourself an expert, feel free to investigate Antonia 1.2 right now, because she's got that same issue and Antonia 1.3 only inherited it. Also, I still haven't purchased P11 and am a little bit behind on P12, so it's entirely possible that the problem disappears in the latest version of either or both.

For Nova i made a script to do pose symmetry. It is completely agnostic on hierarchy so it works on Antonia also. It currently does only complete left-and-right swaps but could easily add a filter and share if you want. As said I to not expect the devs will give this high priority.

The script works well. I have a copy. Perhaps this isn't a bad idea, including a customized version of the script (as FVerbaas proposes) with the runtime and a little note for Poser tech heads. A frill, but maybe useful to someone.

Also, general policy on frills: let's put them in separate packages so they can't mess up the timeline now, and if they work well and folks find them useful, earmark them for inclusion in a future release.

Not a bad idea, but since this apparently affects other independent figures as well, maybe it should be a separately maintained and distributed script that comes with a mini database of figure hierarchies.

In general a database of figure metadata would be of great benefit. Part of the relative success of DAZ is due to their system approach to content: once you select the figure you get an overview of 'smart' content that can be used with it. Conversions are largely transparent and many parameters are set automatically. This greatly helps acceptance of their figures. The system is effectively under their control and of course this gives them great power as developers. One can debate the degree to which they use it to 'stimulate' sales, but that is another discussion.

Poser works fom clean slate all the time,  leading either to complex and fragile procedures that re-do the same work over and over again. You cannot tell the Fitting Room the garment is tailored for V4 and it does not recognise the target figure is LF, so each time it has to use complex and fragile wrapping procedures and 'easily going wrong' regrouping. To my knowledge EZSkin is an exception maintaining a database of conversions. It uses the name of the geometry file as a key. 

The acceptance of Antonia was hindered by the various branches,  which people noted because their content did not work correctly. I therefore think Antonia would be helped if there were, to begin with, a metadatabase including hierarchy and other data relevant for converting and applying content. When it works it could be used for other figures also.

But yes, this need not affect current developments and would be one of the frills. 

Here's another view of the "beak reduction" morph. I think I've given up on putting any vulva morphs into the base figure, so this weekend I'll start building a runtime and cleaning things up.

The acceptance of Antonia was hindered by the various branches,  which people noted because their content did not work correctly. I therefore think Antonia would be helped if there were, to begin with, a metadatabase including hierarchy and other data relevant for converting and applying content. When it works it could be used for other figures also.

That sounds interesting, but a tad abstract. What kind of content would be converted, and who would write the converters? Or put another way, what would be a good first application to introduce the metadatabase with? Something to do with poses, like the symmetry tool we talked about?

Looks much better. :)

odf posted at 4:24 AM Fri, 23 September 2022 - #4445094

That sounds interesting, but a tad abstract. What kind of content would be converted, and who would write the converters? Or put another way, what would be a good first application to introduce the metadatabase with? Something to do with poses, like the symmetry tool we talked about?

Information for poses support could be which bones need to be adjusted when doing the standard operations like swap left-right, tight to left and left to right, and how to translate split-up upper arms and thighs info like in G8/Nova to the rig arrangement usual in Poser. Rotation angles/quaternions that let the figure take a standard T pose (or whatever the agreed reference pose is), so converters can take the conversion from there.
Yes, all still pretty abstract but that is where it needs to be at at this moment.   

Recent updates to the Python API include CopyMorphFromFigure(). There are still a few rough edges, but once they are solved it means automatic geometry conversion of garments and hair like in the Prefitter-CR2 has become feasible and will likely be on my worklist, along with the autorigging tools. I now use hard-coded figure data. Maintaining figure specific scripts is a nightmare so better have central database.  

Applications and data are like the old chicken-or-egg issue. To resolve the situation one must start somewhere and hope for the best.   

Here's another view of the "beak reduction" morph. I think I've given up on putting any vulva morphs into the base figure, so this weekend I'll start building a runtime and cleaning things up.

I like the smaller nose. But I also prefer the aesthetics of Asian features, so don't go by my opinion. But if it's included in the package, I would use it.

rokket posted at 8:26 AM Fri, 23 September 2022 - #4445103

odf posted at 4:10 AM Fri, 23 September 2022 - #4445093

Here's another view of the "beak reduction" morph. I think I've given up on putting any vulva morphs into the base figure, so this weekend I'll start building a runtime and cleaning things up.

I like the smaller nose. But I also prefer the aesthetics of Asian features, so don't go by my opinion. But if it's included in the package, I would use it.

primorge : It's true that she is damn' gorgeous...

Here's another view of the "beak reduction" morph. I think I've given up on putting any vulva morphs into the base figure, so this weekend I'll start building a runtime and cleaning things up.

What is people's position on "internal" channels such as JCMs or the per-actor parts of FBMs - hide them away because users shouldn't normally dial them in individually, or put them in appropriately named groups? Also re FBMs: I'm not sure I understand what "master synced" does and what it's good for. Do I need to? I think my preferred setup is that every user-facing dial other than individual actor transforms is a targetGeom channel in the body actor.

I did some spring cleaning on the channels today plus a few additional tweaks, but I think now I'm really ready to put a runtime together. Incidentally, here's a little update on the skin tone dial, now with the hue adjusting to the amount of melanin. 

The body morphs used here will not be part of the main package, but I might release a separate one with "assorted morphs" or something. Or maybe I'll just do an "Antonia odds and ends" with my little collection of favorite morphs and poses for Toni.

odf posted at 8:08 PM Fri, 23 September 2022 - #4445142

What is people's position on "internal" channels such as JCMs or the per-actor parts of FBMs - hide them away because users shouldn't normally dial them in individually, or put them in appropriately named groups? Also re FBMs: I'm not sure I understand what "master synced" does and what it's good for. Do I need to? I think my preferred setup is that every user-facing dial other than individual actor transforms is a targetGeom channel in the body actor.

Master sync is best left 'off' I think. Tony was not made for it so it can only cause trouble.

Antonia should work with all new Poser features. "Master synced" is enabled by default, so Poser users are used to it.

http://www.posersoftware.com/documentation/12/Poser_Reference_Manual/Tools/Modifying/Editing_Master_Parameters.htm

Scroll down a bit to "The driven value" to learn more about "Master synced".

I use master sync on most of the time. It's very useful for setting up dependencies that are masters driving sub masters. At the return to 0 the subs automatically back out.

There's no issues with Antonia and master sync(h), I use it on with her hundreds of times. 

Hiding dials is kind of pointless now that Poser has a show hidden parms checkbox. But if you want a bunch of extra clicks for some reason set the parms as hidden in dial settings or by hacking the cr2. Probably doing it in a text editor is quicker I guess. I just do it as I go along in settings as necessary.

For parm groups; I create a parm group in every actor that might contain a FBM component. It helps keep things neat if you are creating and sharing a bunch of morphs.

For JCMs I create a JCMs parm group in all involved actors, so too with FBM. Though every JCM I create is in a sense a FBM as I use an empty FBM dial as a master for all controllers and JCMs. That is if the target is pmd. For cr2 embedding create new master valueParm is fine.

Save yourself the headache and create parm groups preemptively and descriptively named for destined actor specific morphs, if that makes sense. I have mine transparent to the user but collapsed initial.

I would share some screencaps of how I set up my parm groups in the actors but Poser is tied up rendering. You can see it easily enough if you have the My What Eyes or Nova Nose Morphs sets I made for Nova a while back. IIRC they are set up pretty meticulously and neatly. I've actually gotten more meticulous with that stuff since then, "moan".

So maybe I'll concentrate on sensible grouping then and forget about hiding. I'm thinking about creating an "Internals" group in each actor with subgroups for JCMs etc., anything users should not normally dial in directly.

As for master sync, I guess I'll have to do some experiments to understand how it works with complicated dependencies and then decide on a case-by-case basis. To be honest, so far it looks like a complete nuisance to me.

As for master sync, I guess I'll have to do some experiments to understand how it works with complicated dependencies and then decide on a case-by-case basis. To be honest, so far it looks like a complete nuisance to me.

"WARNING: Do not use Antonia 1.3 under any circumstance, as it will definitely physically destroy your computer on account of the author not having the faintest idea what the heck they are even doing."

Oh, another one of those little things: should I change the display names of the body part rotation channels back to the usual bend, side-side and twist? I guess I was trying to be cute with the alternative names, but now it just seems silly.

I don't think it matters, as long as we can figure out what it's supposed to be doing...

If it seems silly, change it. It never bothered me though.

Well, if it isn't bothering anyone else, I'll probably just leave it. If it ain't broke, etc...

I think I'm done with the figure setup now, as far as I wanted to take it. Some cleanup work on the geometry left. The breasts had some lumpy spots, and small asymmetries crept in that I'd rather fix.

Anyway, soon now...

Antonia 1.3 Runtime is being assembled. Another one of those silly little questions: does she need an XMP file? I mean, I don't mind filling that out for Toni, but are those things actually used for anything in practice?

XML files are a point of discussion. They could be useful when correctly filled i but I know of no actual use at this moment that would require it. 

I was told to take the .xml out of products I submitted for the marketplace.

If you leave it out I do not think anyone will miss it.

Thanks FVerbaas!

I did some spring cleaning on the channels today plus a few additional tweaks, but I think now I'm really ready to put a runtime together. Incidentally, here's a little update on the skin tone dial, now with the hue adjusting to the amount of melanin. 

The body morphs used here will not be part of the main package, but I might release a separate one with "assorted morphs" or something. Or maybe I'll just do an "Antonia odds and ends" with my little collection of favorite morphs and poses for Toni.

The problem with the melanin hue adjustment is areas around the hand palms and foot soles are where the skin is entirely different in those regions making them lighter in color.  Either you need to apply a mask or define those areas as separate material zones.  This reminds me of the old Sci-fi TV show 'The Invaders' created by Larry Cohen where the aliens could not replicate human skin precisely because the hand palms retained the same coloration as the rest of the body.

To represent suntan with any realism I think you will need to use a mask anyhow. Even without a bikini print some parts of the skin are simply more exposed to the sun than others. 

Just in case: EZSkin has an example of suntan lines: using the Cycles module for the skin (I don't remember its name just now)

I realise that the skin tone dial by itself will not create completely realistic results over the full range, but in my mind that’s not a reason not to have it. Like with many things, it’s a starting point and up to the individual artist or content creator to expand on it as needed.