Quote - > Quote - Rightio.  But suppose I want to set my focal length to something close to the human eye, 100mm, for example?

I'll have to take some photos out of my window when there are some interesting clouds, just to show you what I mean.  I know, a picture is worth a thousand words and all that. 

The human eye is 50 mm. And Poser's focal length is wrong by a factor of 1.4. To accomplish a human eye type of field of view, you want 50 / 1.4 = 35 HAHAHAH.

Just stumbled across this. Where does the sqrt(2) come into it? I.e., what is the source of the error?

Whichway

Turns out with some experiments and a look into the geometry files, the density is in grown hairs per square display unit, independent of the polygon density. So, if your Preferences set the display units to feet, it's hairs per square foot; centimeters, then hairs per square centimeter. What is actually stored in the file is hairs per square Poser Unit, i.e., per (8.6 feet)**2. Rather a lot, usually. [17,000,000 for average human hair.] The total number of hairs value is correctly given and is the density multiplied by the area of the hair group, which, unfortunately, is not shown in the UI, but is contained in the file in square Poser Units, however, it does not include guide hairs, only grown hairs, so the actual number of hairs is larger. For a fine mesh and low hair density, the guide hairs can actually overwhelm the grown hairs. [Been there, done that.] At least that part of the Hair Room now makes sense to me.

Whichway

P.S. - If you change the Preferences display units on the fly, you probably have to at least close the document and reopen it to get the density calculation updated.

I'm dropping this here just because I had a mail session with Anatis (@DAZ, Silke here, I'd guess) about it and she(?) pointed me here. I've not read the thread yet so apologies on that score, and this was one of my earliest experiments in the Material Room so some things are a little funky.

Render is here:

http://forum.daz3d.com/viewtopic.php?p=1719732#1719732

Screen shot of a material is here:

http://harpsichordyet.com/gallery2/main.php/v/Misc/Hairy+Material.jpg.html

Whichway

However, if I save out a Material Set with the changed GC values, they remain set to the value I picked when reapplied in another Poser Pro invocation. So, if I sort out my workflow properly, it shouldn't be too bad.

Whichway

Hmm. Ok, thanks guys. Setting the GC value by hand before applying the VSS Prop is what I've been doing, but was looking for an automated way. Maybe Bagginsbill knows off the top of his head if the file property table is preserved across invocationns of Poser Pro; Then I'd only have to set it up once in the lifetime of the file. If he doesn't know, I suppose I could force myself to check.

Whichway

P.S. - I checked and the table is not preserved across invocations. Not surprising, I suppose, but it means I have to fiddle the GC value once each time I use the file in any Poser Pro session. sigh

I tried that edit out and it does exactly what I wanted. Thanks again, PhilC.

Whichway

Oooo - thanks PhilC. I'd tried editing them to off in the CR2 files, but didn't know to change the names. Too late to do tonight (aka this morning) but will give it a try later.

Whichway

bagginsbill - So, what shader are you using on the bathroom? Glossy? Blinn? Are you using IDL? Could you post some renders, please?

Whichway

mariner - Yep, same version of matmatic works fine in both Poser 8 and Poser Pro 2010 beta.

Whichway

I'm glad to hear that something is happening with Poser Pro 2010. I've been using the beta for some time now, but there hasn't been a peep out of SmithMicro about it nor any way to feedback impressions short of bug reports (and no way to see outstanding issues other than my own, as far as I can tell.) Mind you, it's working quite well for me so far.

Whichway

Actually, I lost track of the VSS version numbers. I was working from VSS pr3. That was the template material set I started from. I think I like my eye shader better; at least I can justify it to myself better. Basically, I modeled the surface of the eye as covered by a film of water, so I used a form of Fresnel reflection off the EyeSurface with some Glossy folded in. I used a transparency mask so that the transmitted part of the light over the sclera passes straight through to the sclera's color map underneath. Over the cornea, the light refracts through a transparent cornea down to the iris. Tear is basically a fresnel node with glossy added so the direct lights show up. Lacrimal is the same as skin, but with glossy added. For the sclera, I used the straight colormap. It looked to me as though the VSS pr3 Template Eyewhite was practically the same as the Template Skin in VSS pr2. Since the sclera is such a different tissue from skin, things like SSS, bumps, etc. probably don't apply. Anyway, that was my thinking.

Whichway

Last one for the moment. As far as I can tell, the VSS2 Template Skin is structurally the same as the VSS3 Template Skin; there are a few minor parameters changed. The biggest difference is the SSS value and here I have adjusted mine to the same value.

Whichway

Oh, pucky. I need to make myself a check-list. I'd fixed the internal gamma's but missed the global one when I rebuilt the scene with BB's file. Since it was for P8, PP2010b by default did *not* do the global gamma correction. Here is that corrected, with the eye highlights turned up along the way. I think that tackles a good bit of the red.

I will look into the details of VSS3 next.

Whichway

I thought I'd post my variation on BB's tutorial scene using M4 with Standard Resolution textures and the soft lighting along with a version of the VSS pr2 material ball thingy, not the latest one. I used Poser Pro 2010 beta, which handles gamma correction and color space calculations in a more consistent, linear fashion; I had to adjust the VSS gamma setting to 1, the overall scene gamma to 2.2 and go through and set the various bump, displacement and specular maps to ignore the automatic gamma correcction PP2010b applies, I also lowered a variety of ray biases on lights and things to get rid of some artifacts, some of which really only show up at higher resolution. The VSS ball I used is one I've been modifying somewhat from VSS pr2. The biggest difference is a complete reworking of the eyes, mostly to better match in my own mind, at least, how light actually interacts with the surfaces modeled in M4. I'd appreciate any comments. Thanks.

Whichway

It does seem a little odd that it is lighting up the back of the hand.

Whichway