Quote - I get what you're saying, but you have to be exaggerating when you say its less than a dozen vertices to move around.  If you are that low poly, even with Catmull-Clark, then you can't possibly produce the curves I made.

[Added Later]

Perhaps you mean control points of a surface of revolution. Then I can see it being less than a dozen, because that's how I made it.

Fair enough. The "less than a dozen vertices" would apply to my current model, in which the complete pupil has only 9 vertices - one in the center and 8 on the outline. To get the funnel shape you are using I'd have to add at least another ring inside. But Wings3D has a number of tools that let you select several vertices at once and slide them along in a synchronized fashion. So it's not a lot of effort to make these kinds of morphs at any rate. Of course your method definitely wins if many different variations of this kind are needed. But hey, there's only so many things one can sensibly do with pupil and iris shapes.

That said, I could certainly just adapt a reasonably low-detail version of your model to my process, and then we'd have both the parametric and the hand-modeled option.

BB, If I'm understanding you correctly on what your parametric geometry is, you have created a script that enables you to make geometry according to a set of input parameters, but also what some programs would refer to as with a history stack.
So, you can create your objects and input any setting you want as you are creating, and even after it's created you can still adjust the parameters, allowing you to create various resolutions and various shapes such as pupil dilation.

What happens when you export it as OBJ and bring it back into Poser? Can your script adjust parameters on what has become a static OBJ file without a history? Or is it forever locked within Poser as a .py file and subject to the user needing to have the script?

That's what I meant by morphing the pupil - without the script and the unique Poser object, it's only good old regular 3D geometry that needs to be dealt with as a regular 3D mesh.

Unless I'm misunderstanding it, it sounds to me like something only for Poser and only exists as it is with its unique properties as long as it remains in Poser. The problem with that, of course, is many many people use other apps for rendering.

Bottom line is, I assumed you took all this into account and had an actual *.obj file made and ready to be dealt with in traditional ways.

Just to elaborate on the above...

Programs such as Max, Maya, and Softimage allow you to create parametric geometry and then go on to further edit and manipulate the geometry in various ways, storing every operation in a history, or as Max calls it, a modifier stack.
And as long as you don't delete that history (which you should do from time to time after being satisfied with your object, to save memory and speed up future operations), it will always be there and you can edit the basic parameters of every operation minutes, hours, days...weeks after creating it.
But once it's exported to another format, that history is gone. Your Maya  object has to forever be a Maya file, for example, and you also lose all the history if you export it as a different 3D file and re-import it.

So if that's the case with this parametric geometry in Poser, it's great for Poser, but couldn't be used elsewhere. While the geometry itself can be used elsewhere, everything that makes it "parametric" is lost.

MikeJ: As I understand the process, bagginsbill uses a Python script that creates the eye geometry and saves it into an .obj file. A variation of the script (or a call with different parameters, whichever happens to be the case) generates a variation of the geometry like, say, one with a wider pupil. This is also saved as an .obj file, which can then be loaded into Poser as a morph target.
The point is, it doesn't matter how many vertices the eye object has because the geometry for the morph is created by the script, which stoically computes as many or as few of them as necessary. No manual vertex pushing is required.
 

Oh right. I'm surprised I didn't see that. Of course, if you can create one mesh, you can create another to use as a morph target for the first.

Quote - MikeJ: As I understand the process, bagginsbill uses a Python script that creates the eye geometry and saves it into an .obj file. A variation of the script (or a call with different parameters, whichever happens to be the case) generates a variation of the geometry like, say, one with a wider pupil. This is also saved as an .obj file, which can then be loaded into Poser as a morph target.
The point is, it doesn't matter how many vertices the eye object has because the geometry for the morph is created by the script, which stoically computes as many or as few of them as necessary. No manual vertex pushing is required.
 

But what about being able to use the eye in Daz Studio if it uses a python script to call for the morph?

I've been following this (and confess not completely understanding all of it) and she's a gorgeous character. I'm eagerly waiting for the final result, but have tried her in Studio. She looks great.

Quote - But what about being able to use the eye in Daz Studio if it uses a python script to call for the morph?

That's not how it works. The script is called only once to create an obj file. That obj file is then used to make the morph deltas. The script is not needed at all in order to use the morph.

**Oh, that's wonderful! Then it means I can use my favorite rendering program with her still.

btw...I warned you I didn't understand it all. lol
**

Do users of Maya really buy crap like this?

http://www.creativecrash.com/maya/marketplace/3d-models/c/eye-1

$35 for that? It's childish noob garbage - and it was just updated in August!

So what would my eye be worth, $1000? 

Quote - So what would my eye be worth, $1000? 

All I know is that extraction is always included.

Quote - Do users of Maya really buy crap like this?

http://www.creativecrash.com/maya/marketplace/3d-models/c/eye-1

$35 for that? It's childish noob garbage - and it was just updated in August!

So what would my eye be worth, $1000? 

I don't know. Maybe if someone needed it for a project he would, if he didn't want to take the time to model. Maya is used for a whole lot of stuff, mostly animation, and that which is "photoreal" is only a small portion of it. If you're a freelancer and making several thousand dollars to deliver a 30 second animation for someone's commercial, 35 bucks to save yourself some time on the modeling is no big deal.

But I'm glad you found that. This is the type of thing I was hinting at in your procedural geometry thread. You're showcasing your talents in the wrong market. You ought to be trying to juice the people with the money and the ever-looming deadlines. ;-)

Something completely different: does someone know a good dynamic hair tutorial? I've never used it, but apparently it's working really well in P8 and is now supposed to beat transmapped hair.

Wow, Bagginsbill, you are amazing with Python!

Just a silly question: can the pupils dialete (spelling?) based on the amount of light in the scene? 

That hair looks pretty good, Olaf, I guess you found a tutorial. ;-)
The shading on the edges in the back looks kind of strange though - like haze or something.

Quote - That hair looks pretty good, Olaf, I guess you found a tutorial. ;-)
The shading on the edges in the back looks kind of strange though - like haze or something.

No, it's just some pre-done hair for Alyson (originally for Jessi, in fact) that I put on Antonia's head. And it looks awesome, as Poser hair goes, which is why I'd like to learn to make my own.

The edges look strange because I forget to render with the correct background color when transparency is involved. Or put differently, because Poser does something not quite correct with the alpha channel.

Did you use Texture filtering for the hair?
digitalbabes.jp/dload/texturefiltering.html
Hair is the only thing it is good to use on.

bagginsbill that's the best looking eye I've seen. It would be great for swapping out the geometry to get better looking eyes on many figures. :)

Kerya: It's dynamic hair. Texture filtering does not apply.

That was just a quick test image. Don't worry about the render quality.

Well Olaf, the only good tut on dynamic Hair is in German, so no prob for you. So you should look at :

www.adorana.de

Quote -
The edges look strange because I forget to render with the correct background color when transparency is involved. Or put differently, because Poser does something not quite correct with the alpha channel.

Transparency? Isn't that strand-based dynamic hair? Why would transparency have anything to do with it?

Quote - > Quote -

The edges look strange because I forget to render with the correct background color when transparency is involved. Or put differently, because Poser does something not quite correct with the alpha channel.

Transparency? Isn't that strand-based dynamic hair? Why would transparency have anything to do with it?

Sorry, not transparency as such. It's fine details at the outline of the render that got mixed with the original background color via anti-aliasing. When one saves a render with an alpha mask that shouldn't happen, but it does.

Quote - Well Olaf, the only good tut on dynamic Hair is in German, so no prob for you. So you should look at :

www.adorana.de

Ah, thanks a bunch! I thought of her, but couldn't remember the name.

I am currently working on some Hand (.hd2) files for Antonia. A few things have come up that I think are worth mentioning. I am just thinking aloud here. Not saying that things should change. Just wondering if they should or not, and perhaps playing devil's advocate for the "should" argument.

This is about the ERC "CTRL" hand dials that control the bend and spread of the fingers and thumb. This ERC system is different than that used in say the P4 figured, which use special Grasp and Spread channels that work differently than ERC. The main difference with the true Grasp channels is that they set the bend parameters in the finger joints themselves, then return to a zero state once you release them.

There are two advantages that I see in the P4 type system, as compared to the ERC system used in Antonia:

**1). Hand files (.hd2) saved after using P4 type Grasp or Spread can be applied to the opposite hand without problems. The same operation will not work successfully in Antonia if Grasp or Spread has been used (there is a fix, see below).

2). Pose files (.pz2) will record P4 type Grasp and Spread, even if the "Include morph ..." option is not used. With Antonia you would have to use "Include morph ..." to save data for the Grasp and Spread channels.**

That's the plus side for using P4 type Grasp in Antonia, but there are downsides.  With the P4 type dials, using Restore on the hand will not undo the action of the Grasp and Spread dials, you would need to restore each finger joint individually. Also with the P4 type dials using them in reverse won't exactly undo what was done using them forwards, this is most noticeable with the Spread dial. The Spread dial has never worked well with any figure. Th P4 type Thumb Grasp does not work well with Antonia, and this seems to be down to Antonia and the the rigging of her thumbs. Possibly the 'orientation' lines are at the root of this, but it would probably take someone who knows a lot more about rigging than I do to sort it out.

The "CTRL" dials are named differently in each of Antonia's hands. Dropping the "L" and "R" from theri names would probably take care of point #1 above, as a hd2 file automatically saves data for a targetGeom channel without the need for user intervention. I would recommend that you make this change.

As to the broader question of ERC versus P4 style Grasp and spread channels. I just wanted to raise it for consideration and debate.

I just wanted to mention Adorana's site - Jules was quicker It's worth reading it, I've learnt a lot from it although I do'nt use dynamic hair a lot. Most of all because I have trouble to fit the premade one's I haave (from the same site) to other figures...

But maybe someone would like to create a skull cap as a base for dynamic hair for Antonia?!

Quote -
But maybe someone would like to create a skull cap as a base for dynamic hair for Antonia?!

I will if someone tells me what Poser needs in a skull cap to get good, thick hair, without overkill on the polygons. Does Poser grow a fixed number of strands based on the number of polygons, or can it grow as many or as few strands per poly as you tell it to?
Does it need to sit on the surface of the head, or be slightly below and slightly smaller? Can Poser grow hair roots based on a starting point from the distance from the geometry, or does it start each strand right from the surface itself?
I've messed around with it in Maya and Softimage, but I have no idea how to do it in Poser,or what Poser's requirements are for a good skull cap.
I bet Olaf has already made one though. ;-)

lesbentley: Very useful info as usual. Thanks!

Giving the grasp and spread channels identical names for both hands shouldn't be a problem. Some external programs might get confused into thinking that it's the same morph, and I imagine that's why phantom3D used different names. But I see the advantages of using identical names outweigh the disadvantages (unless of course there's some drawback I'm not aware of). So I'll make that change and see how that goes.

I haven't really done a lot with the hands, but I think there's a consensus that the rigging of the thumb in Antonia is more useful than in most other figures, where it tends to be quite painful to achieve any useful thumb poses. So I guess that trumps having a working "Thumb Grasp" dial.

Since both methods of posing the hands have their pros and cons, I wonder if we couldn't support both and let the users choose. I always found the classical method a bit confusing and definitely prefer it the way it is now in Antonia. But the fact that the setting is not normally saved with the pose is rather annoying. Saving with morphs included is only really practical as long as there are no other morphs applied to the hands. I'm not planning to put any in the base figure, though, so I guess this would be a workable solution, at least for the time being.

It would actually be nice to have some finer control over what gets saved into a pose file. I imagine someone could write a Python script for that. Or is there already such a thing that I'm not aware of?

I have uploaded a set of 56 Hand poses (.hd2) for Antonia 114, to the developers site. Also includes some Lock and Zero poses.

They are not all great poses, but perhaps they will suffice to fill a gap until something better comes along. Feel free to improve on them, add your own poses, or use them in any way you want. The image above shows thumbnails of the poses.

Lesbentley you got gun poses and smoke poses, I think this is the definitive collection.

odf,

Quote - Since both methods of posing the hands have their pros and cons, I wonder if we couldn't support both and let the users choose.

The ERC Grasp and Spread in Antonia is definitely a lot better than in other figures I have seen. I think that so long as the naming of the CTRL channels is fixed, that I would prefer Antonia's current system over the P4 system, even though there are some limitations. As to including both systems, I think two sets of Grasp dials would confuse many users. Perhaps a good compromise would be to include the P4 style Hand Grasp and Spread, but hide the dials. There could be an unhide pose, not part of the standard package, but a separate download. That way the functionality is still there for developers and advanced users, but it is less confusing for the average user. IMO there would be no point in adding a P4 type Thumb Grasp, as that plays very poorly with Antonia's thumb.

When I made my Hand poses, I wanted to have the bends recorded in the individual joints, not an ERC master, but I could not face the idea of bending each joint from scratch, so added the P4 type dials. But if I had been posing the figure for a render I would have used the CTRL dials.

GeneralNutt,

Quote - Lesbentley you got gun poses and smoke poses, I think this is the definitive collection.

Actually I am quite ashamed of the "Pistol Grip" pose  , I think it is the worst one in the set. I almost did not include it, but thought that even a bad pistol pose is better than none at all. Perhaps someone who is better at posing than me can come up with a replacement that could be put in an update of the set? Any way I have an excuse, I'm British, and most of us don't even know which end of a hand gun to hold. :blink:

Now give us a rifle, and that's a different story!

*Any way I have an excuse, I'm British, and most of us don't even know which end of a hand gun to hold.

• ...and that's a good thing! But wait... even no waterpistols in Great Britain?! :laugh:*

Thanks a lot for the set, I'll have pretty much use for it!

About the skull cap: The website that holds the (german) tutorials about dynamic hair has some skullcaps available for download, they're all made for V3. Maybe they can "tell" you something about what is needed for Antonia... here is the direct link:
http://www.adorana.de/index.php?option=com_remository&Itemid=0&func=select&id=6

As far as I understood the process of creating your own dynamic hair you can add as many groups with as many hairs as you want - in other words: It seems that the computer is the limit here. But I may be wrong... than hopefully someone will correct me!

Great hand poses, Lesbently.

Gotta take a short  break from mt Toni tex to finish an M4 set.
I'm trying to figure out the workings of Daz Studio so I can include a set for it...sigh.

I feel your pain - I am still lost within DS3...

The hand poses look pretty good there, Les!

Thanks for the skull cap links, SaintFox, I'll have a look over those.
(Sent you a site mail a few minutes ago, BTW)

odf,

Many Poser figures are commonly referred to by an abbreviation of their name, eg V4 (Victoria 4), G2 (The Girl 2), SP3 (Stephany Petite 3), etc. This has two advantages, it provides a quick way to refer to then in posts, and it provides a way to refer to content that is specific to them, such as the names of pose files, props, folders, etc. Can I take it that "AP" and "AP114", "AP116", etc, are now the officially approved abbreviations for Antonia Polygon?

I guess the alternative would be "A", "A114", "A116", etc.

My understandings  is that the Registration Process for Poser Character Abbreviations (RPfPCA) is expensive and time-consuming. Since I haven't set up a Pay-Pal account for donations yet, I think we'll have to go with unofficial abbreviations for the time being.

Quote - The "CTRL" dials are named differently in each of Antonia's hands. Dropping the "L" and "R" from theri names would probably take care of point #1 above, as a hd2 file automatically saves data for a targetGeom channel without the need for user intervention. I would recommend that you make this change.

lesbentley: I tried that. What happens now is that if I apply a left hand .hd2 file to the right hand, the CTRL dial is applied on top of the values in the finger joints, so in effect I get double the grasp. This happens consistently in Poser8 and Poser6.

If I use the current channel names, Poser complains when I apply a left hand .hd2 file to the right hand, but sets the finger bends correctly anyway, and in effect I get the pose that I wanted. Again, this happens the same way in P6 and P8. So now I'm a bit confused, because you reported that applying a .hd2 file to the other hand wouldn't work.

Maybe a solution would be to move the hand controls into the body so that Poser would save only the resulting finger settings but not the control values themselves? I'll give that a try.

To answer my own question: when I move the control channels from the hands into the body, pose the hand using those dials and then save as a hand pose, the .hd2 file doesn't capture any of my settings at all. So from my limited experiments, it actually seems that the way phantom3D originally set up these dials is what works best for saving and restoring hand poses.

I've just uploaded a new preview version, Antonia-118.

Link: sites.google.com/site/antoniapolygon/Antonia-118.zip

Please note that this does not yet include MikeJ's new UV-mapping, any of the new textures or the new eyes proposed by bagginsbill. But I've made a number of significant changes since August, so I thought it would be good to put this version out there.

I'll wait until the end of the week before I'll update the "official" links und block the previous preview from my locker, just in case someone spots a really bad bug.

odf,

I must admit that when I gave you the advice about renaming the channels, I was working on theory, and had not done the tests. I should know better by now! every time I say something about Poser without doing the tests first, I end up with egg on my face, and I've got a double yolker this time  :sad:. I have started to do some tests now.

I'll tackle your points in backwards order.

Quote - If I use the current channel names, Poser complains when I apply a left hand .hd2 file to the right hand, but sets the finger bends correctly anyway, and in effect I get the pose that I wanted. Again, this happens the same way in P6 and P8. So now I'm a bit confused, because you reported that applying a .hd2 file to the other hand wouldn't work.

The error message "Some information...does not pertain to a figure of this type" is easily fixed by editing the file to add the line "setChannelWarning 0" as the line just above the closing brace of the file. In P6 (and probably other versions) if you open a hd2 that came with Poser you will see this line. However when P6 writes a hd2 it does not add that line. The error may be caused by Poser encountering unexpected dial names in the hand, but I am not sure.

Quote - ... but sets the finger bends correctly anyway, and in effect I get the pose that I wanted.

If you (or an end user) saved a hd2 for the rHand, it would not contain data for the lHand "CTRLL" channels, and so the Grasp and Spread could not be transferred to the lHand. You would need to make a separate hd2 for the other hand, or you could probably edit the hd2 to include the missing channels, but I have not tested that idea.

Quote - What happens now is that if I apply a left hand .hd2 file to the right hand, the CTRL dial is applied on top of the values in the finger joints, so in effect I get double the grasp. This happens consistently in Poser8 and Poser6.

I have started to do some tests and I get the same result as you on that score. I did an experiment in which I set the rHand Grasp to 1.0 then saved a hd2 from the rHand and applied it to the lHand, the master dial was set to 1.0  as it should be, but the hand had not moved, (after disabling limits) a value of 2.0 was now needed to clench the fist, and a value of 0.0 gave a negative bend. On saving and inspecting the pz3, I found k ('keys') value of each zrot channel in fingers (only) had been set to the inverse of the value in the corresponding 'deltaAddDelta' line. All this calls out for further investigation, but I have been up all night, and now I must sleep.

I can only apologise for giving bad advice and wasting your time. I had jumped to the (wrong) conclusion that because a hd2 records targetGeom channels it must be able to transfer them successfully to either hand. This does not appear to be the case, at least in situations where ERC is controlling rotations. The k value is transferred successfully to the targetGeom, but something strange happens to the rotations, which seems to be related to the 'deltaAddDelta' value, and whether or not the master has a none zero value.

I don't think I have ever said thank you for the wonderful creation that is Antonia. **So a big thanks to odf, and also to:****phantom3D
MikeJ
SaintFox
LaurieA
JOELGLAINE
BluEcho
bagginsbill
karanta
Believable3D
**

And all others who have contributed to the development of Antonia.

I love the way Antonia's feet bend. In other figures I have used, the heel tends to jut out too far when the foot is bent backwards. I think the above image shows how nice her feet are (What?... Yes she does have feet, they are on either side of the place you are looking at). The leaping pose is part of a collection I am slowly building up, between several other things I an trying to do. When and if I get enough poses together to make a decent package, I will post them to the developers site.

I did a little experiment with the new eye. This is Antonia 118. I replaced one eye with the new one, which uses refraction and the eye cover. On the old eye, I updated the materials a bit but I'm still using transparency.

I'm not certain there's an appreciable difference in this pretty standard light and composition. Can you tell which is which?

(Click for full size)

Rendered in P8 with IDL. The light is 90% environmental lighting. I did not use HSVETM, but rather shader GC, which I think still produces better results.

My guess would be that her right eye is the new one. It seemed to have a bit more depth, then looking closer I noticed that the iris-pupil transition is smoother.

Well, how about that. You can see the difference. You're correct, it's her right eye.

bagginsbill,

Those eyes look really great. Whether or not your eye geometry ends up being an official part of Antonia, I hope that you post it for download, as I like to have alternatives.

odf,

Has the 117 geometry changed in shape or otherwise (other than the handles) since the 114 version?

Quote - odf,

Has the 117 geometry changed in shape or otherwise (other than the handles) since the 114 version?

I made two minuscule changes: tried to fix the breast shape problem that you mentioned some time ago, and removed the butt cheek overlap. That and the handle removal is all I can remember.

BB's eyes... I think I would need some brighter light to see remarkable differences. I can easily see that the pupils look different and the reflection on the cornea is different as well (but this may be because of different settings) - so it's not easy to find out more with this rather dim (but natural) light.

As we are talking about eyes: I have tried out MikeJ's remapped sclera and it works like a charm, not a bit stretching anymore and easy to work with!
The result above does still contain the old bumpmap that, of course, doesn't match the texture and I am VERY unhappy with the transmap I've made to blend the sclera into the iris. But of course this is a low-polygon object and the high-poly version (and the matching template) will give me more orptions for better results. If we decide to use this mapping I dare to ask for a favour: May you, Mike, include a mark to show where the sclera overlaps the iris? This would make it easier to create a precise transparency to achieve this iris-melts-with-sclera effect.

SaintFox and MikeJ: if we end up keeping the current eyes and not replacing them with bagginsbill's(*), is there any good reason not to use my original UV-mapping for the eyes? It seems to me that that version always worked fine, seeing as it had the iris-sclera overlap already built in.

And if we use bagginsbill's, it seems to me that he's already mapped them as to work with the existing eye textures for my mapping, so there'd be no reason for a new UV-mapping, either.

This is not to diminish the efforts of either of you. It just seems to me as if you might be wasting your time on reinventing a perfectly functional wheel.

(*) And that's a big "if", because at the moment it seems to me that I'll use his as soon as I can get my grabby hands on them.