I just bought Poser Pro 2010 (sidegrade from P8), and it worked great the first day.  Now, though, a mysterious problem has cropped up.  I'd been told a while ago that AO is unnecessary whenever IDL is activated, because AO is included in the IDL.  My own experience with P8 contradicted this (leaving the "Evaluate in IDL" box unchecked caused no loss of AO, but deleting the AO node did seem to result in AO-less renders), so I continued to use material-based AO along with IDL.  I decided to test the IDL-AO connection in Poser Pro 2010 shortly after installation, and it seemed to hold true this time.  My characters have two complete MAT sets.  One has both procedural gamma correction and material-based AO, while the other has neither.  I applied a MAT pose from the latter set and activated automatic GC.  The resulting render still had AO!  I thought, "Great!"

Well, sometime today, something changed, and I have no idea what it is!  Now, activating automatic GC in render settings seems to give me distinctly flat-looking renders that I recognize from prior experience as lacking ambient occlusion.  I tried tinkering with the render settings a bit.  I also tried rendering default V4 to see if my MAT poses were somehow the culprit.  I tried restarting Poser Pro and even restarting my computer.  No luck.  I would be eternally grateful to anyone who can give me some idea of what the heck's going on! 

Thanks in advance! 

There are several things you will need to do when you activate FC... much of it has to do with lighting, and most of it has to do with your non-colour info images, such as bump maps and trans maps and spec maps, etc... anything not giving poser pro colour information needs to be modified in the ImageMap node itself. When you click on image_source, you will see additional options... which is where you need to set the radio box option Custom Gamma Value on and put 1.00 in the text box.

There are entire threads on here about GC and this issue, as well as lighting issues, which I'd rather let someone describe that is better versed in the subject.

AO and IDL/Global Illumination don't really have that much to do with each other.  AO is not dependent on lighting, basically polygons are shaded darker if there are other polygons near them with no regard to light.  The shading applied by AO is always one color - normally black but I'm pretty sure you could make it another color if you wanted to, but at any rate just one color with no regard to nearby surfaces.

IDL tries to take into account where light is coming from, how intense it is, and will be affected by color of surfaces it bounces from - a lot more like how real light behaves, although still an approximation.  It does the thing that people usually use AO for ("contact shadows") but it does it in a much more realistic way.  There is no mechanic that will prevent you from rendering both AO and IDL in the same image, and if you really want to run both I suppose you can, but I don't recommend it.

I don't have any info for you about gamma correction as I don't use it.  My advice is to pick one feature, work with it until you understand it (maybe not at a mathematical level but at least well enough to predict how it will behave) before trying to integrate another major feature.

Quote - There are several things you will need to do when you activate FC... much of it has to do with lighting, and most of it has to do with your non-colour info images, such as bump maps and trans maps and spec maps, etc... anything not giving poser pro colour information needs to be modified in the ImageMap node itself. When you click on image_source, you will see additional options... which is where you need to set the radio box option Custom Gamma Value on and put 1.00 in the text box.

Robynsveil I'm actually pretty glad you mentioned this, as I'm looking into trying to work with GC today and this was an immense roadblock until I realized what you were talking about here.  Side note, I really don't much like the way this is presented in the interface - it seems to me that as long as they were changing the structure of the Poser file format to accommodate CG per texture, it would have been smarter to have added a control to the Image_Map node (e.g. a checkbox and a textbox in which you could enter a GC value) rather than the excessive number of clicks required to control it in the current version.  If you only had one map per material this wouldn't matter too much, but for many skin materials this is something you're going to have to screw with for two or more grayscale maps for nearly every material zone.  Guess I'll write a script to manage this.

Quote - Robynsveil I'm actually pretty glad you mentioned this, as I'm looking into trying to work with GC today and this was an immense roadblock until I realized what you were talking about here.  Side note, I really don't much like the way this is presented in the interface - it seems to me that as long as they were changing the structure of the Poser file format to accommodate CG per texture, it would have been smarter to have added a control to the Image_Map node (e.g. a checkbox and a textbox in which you could enter a GC value) rather than the excessive number of clicks required to control it in the current version.  If you only had one map per material this wouldn't matter too much, but for many skin materials this is something you're going to have to screw with for two or more grayscale maps for nearly every material zone.  Guess I'll write a script to manage this.

When you change the gamma on one texture (i.e. headB.jpg for the bumpmap), it is set to that value on every material node in that figure that uses that texture.

Thanks, I halfway noticed that was going on but I hadn't realized exactly the pattern to why.  Still some wasteful clicking but I guess it doesn't have to be done all that often at least.

There is already a built-in script which will change the Gc for all transparency, displacement, bump, and normal maps present in all scene objects. Yes, it requires several clicks, but it does a thorough job.

I guess it would have been too much to hope for, to have the name have "Gamma" or "GC" in it.  What's it called/where is it?

"changeGamma.py"?

Yep, that's it.

Thanks :)

Sorry, I've been a bit slack in getting back to this. Since I tend to change a few more things than just the gamma value when I look at a shader (diffuse_value to .85 and specular_color to white for all materials except metals and adding a blinn() node, and setting Texture_Filtering from Quality to None for almost all ImageMaps, among other things) I sort-of end up setting this value manually. Wish that when I change ImageMap Texture Filtering for one node, it would change it for the rest, like it does for the gamma value, but there's probably a reason why it isn't set to work that way.

Attached Link: http://www.renderosity.com/mod/freestuff/details.php?item_id=39676

Forgotten about that, and yet, I was using one of these before BB included this functionality in Matmatic. :blushing: thanks for reminding me.

I guess what I meant was: when you set Diffuse_Value to .85 in one material, you could have the option to do so for others as well at the same time. DS includes this feature, IIRC.

I did a simple script for that purpose, although it sets it to 0.8 it's pretty simple to modify.  Note this isn't ideal for all surfaces in all applications, e.g. you don't want a reflective surface to have a diffuse_value of 0.8.

http://sites.google.com/site/fleshforge2/Home/free-stuff/set-diffuse_value-to-0-8-script

Quote - There is already a built-in script which will change the Gc for all transparency, displacement, bump, and normal maps present in all scene objects. Yes, it requires several clicks, but it does a thorough job.

The problem with the gamma setting from the image_map node is however, that the gamma-setting is not tied to the node, but rather to the actual image that this node has loaded, as Taren already noted. This is most likely a bug, but it prevents effectively any side-by-side comparison from a figure with gamma to one without. Also one cannot use the same image for a bumpmap and for e.g. diffuse-color at the same time.

But Poser2010 has a 'gamma'-node in the math-nodes which does effectively the same and which actually works like the gamma-setting should work; giving a nice parameter where the gamma-value can be set. Alas there is no script that inserts the gamma node into the shader-tree, or is there?

Quote - I did a simple script for that purpose, although it sets it to 0.8 it's pretty simple to modify.  Note this isn't ideal for all surfaces in all applications, e.g. you don't want a reflective surface to have a diffuse_value of 0.8.

http://sites.google.com/site/fleshforge2/Home/free-stuff/set-diffuse_value-to-0-8-script

That's a good point, Paul... thanks. Downloading the script - thank you!

Quote - The problem with the gamma setting from the image_map node is however, that the gamma-setting is not tied to the node, but rather to the actual image that this node has loaded, as Taren already noted. This is most likely a bug, but it prevents effectively any side-by-side comparison from a figure with gamma to one without. Also one cannot use the same image for a bumpmap and for e.g. diffuse-color at the same time. But Poser2010 has a 'gamma'-node in the math-nodes which does effectively the same and which actually works like the gamma-setting should work; giving a nice parameter where the gamma-value can be set. Alas there is no script that inserts the gamma node into the shader-tree, or is there?

I didn't even notice the new gamma node!  That'll come in handy!

In the meantime, I've bitten the proverbial bullet and spent an entire day creating a third set of MATs with AO but no GC.  I now have three sets of 22 MATs each: one with neither material-based AO nor node-based GC, one with both of those, and another with material-based AO but no node-based GC intended for use with the automatic GC.   It was tedious but ultimately worth it.  I actually discovered a bug in my original MATs while preparing the new ones.

As long as we're on the subject of Poser Pro 2010, I was wondering if anyone knows about its rendering speed.  If anything, it should be faster than P8, and yet I find that it's actually slower even with comparable render settings.  Renders that usually take about 10 minutes in P8 are taking 15 or 20 in Pro, and if I add in some hair (transparency), then Pro only gets halfway through the IDL pass in roughly the same time it takes P8 to finish the whole render.  Does anyone have any idea what's bogging down the engine?  I really want to use Pro full-time, but I can't afford to if it's going to slow down my workflow like this.

In any case, thanks for your help so far folks!  I'll keep tinkering with render settings while I wait hopefully for suggestions.

I find rendering in Poser Pro 2010 infinitely faster with exactly the same settings as P7, and quite acceptable with IDL and pixel samples up to 10... one thing I do is I set displacement bounds to .008... this has sped things up quite a bit in P7 and now PP2010.

I'm actually taking all my saved scenes - those I created in P7 - and redoing the lights and shaders (adjusting for renderer GC) and then using BB's IDL lighting... oh, bloody WOW! It's like a new scene. And it's what I'd been after in the first place.

Quote - I just bought Poser Pro 2010 (sidegrade from P8), and it worked great the first day.  Now, though, a mysterious problem has cropped up.  I'd been told a while ago that AO is unnecessary whenever IDL is activated, because AO is included in the IDL.  My own experience with P8 contradicted this (leaving the "Evaluate in IDL" box unchecked caused no loss of AO, but deleting the AO node did seem to result in AO-less renders), so I continued to use material-based AO along with IDL.   

I'm pretty sure that rendering using IDL disables light-based AO, but doesn't disable material-based. In any event, in Poser Pro 2010 if you do want to use AO (without IDL) you should use light-based, since it is now better looking and faster than material-based. (This is the opposite advice than from P7 and, IIRC, P8.)