Jeff01, the Draft and Production choices are only present when the file you're working on was saved from Poser 5. This was done to ensure backward compatibility with Poser 5. Otherwise, one of the two settings would have been lost in the new render settings UI of Poser 6. If you want them around all the time, load a Poser 5 scene with your desired Draft/Production settings and save them as preset in Poser 6 (slightly different name to make sure you can distinguish them going forward). Uli

A minimum amount of displacement applied to the surface of the square will help, but you should also try the new Normals_Forward option on the Poser Surface node on the Advanced tab in the Material room. This is new in Poser 6 SR1. It might just do away with the problem instantly. Uli

Hi all, here's a word regarding the "Out of Memory" message. Let me point out a few things (partially quoted from a statement I made in this forum earlier on): There isn't or wasn't "the" memory bug. There were some problems in Poser 6 before SR1 that made an out of memory message occur even when it shouldn't have. These problems should be fixed now. I'd dare to say that the render engine is fairly solid in SR1. There are also a number of improvements to texture handling and FireFly itself that will enable you to render larger scenes or scenes with more challenging settings. But there certainly is a limit to what is possible. Once you're getting closer to a million polygons or 30 hires textures, you will have to lower the render settings a notch (btw, the FireFly rendering tutorial in the Poser 6 Tutorial manual PDF explains how this often doesn't even affect your final result). The settings labeled as final are very aggressive in terms of resource needs. It is possible that at such render settings, a complex scene consumes more memory than an application can use on a 32 bit Windows system (2 gigabytes). That's why there is a memory check during rendering and that's why there is a message that suggests lowering those settings. This is all normal operation of the application. Please also consult the above mentioned FireFly rendering tutorial for details on this matter. Please render responsibly :-) If you experience that lowering the render settings doesn't help, if your scene is not complex (100,000 polygons or less, no 4k by 4k textures, no texture filtering), then that is not normal and considered a bug. In such a case, please contact e frontier tech support through http://www.e-frontier.com/go/emailtech I if you haven't done so yet. Setting virtual memory to system managed might help in some cases. The more adventurous users can also play with the newly introduced render memory preferences - tweaking the adaption threshold can make FireFly use more or less virtual memory before it reduces the size of a render bucket. Or you can switch off the automatic adaption of the bucket size. If you know the perfect size for your current render, it might render a bit faster because the adaption takes some time when it occurs. Setting the memory limit buffer closer to 0 MB takes FireFly's safety buffer away, squeezing out some extra memory (be careful with the latter two settings, those can affect stability). Hope this helps, Uli

Hi Trav, please contact e frontier tech support through http://www.curiouslabs.com/go/emailtech if the problem persists. Is there a chance that you updated Poser 6 while it was running? That is about the only thing I could imagine forcing you to reboot before the next launch. Thanks, Uli

Hi all, please understand that there is a distinction between the general case of the FireFly renderer running out of memory and the particular problem of a scene file getting corrupted on saving that some people report. The settings labeled as final are very aggressive in terms of resource needs. It is possible that at such render settings, a complex scene consumes more memory than an application can use on a 32 bit Windows system (2 gigabytes). That's why there is a memory check during rendering and that's why there is a message that suggests lowering those settings. This is all normal operation of the application. Please also consult the FireFly rendering tutorial in the Poser 6 Tutorial manual PDF for details on this matter. If you experience that lowering the render settings doesn't help, if your scene is not complex (100,000 polygons or less, no 4k by 4k textures) or if you are affected by Poser writing a corrupted scene file, then that is not normal and considered a bug. In that case, Curious Labs tech support would like to talk to you. Please make contact through http://www.curiouslabs.com/article/articleview/18?sbss=435. Thanks a lot, Uli

Tempus Fugit, while it looks most impressive combined with Image Based Lighting, Ambient Occlusion can be used with any light style. So if you want, you can use Ambient Occlusion in the scene lit by a point light only, too.

Cath, if you are using the Wacro to set the IBL - that one is limited to image maps. Is that what you mean by "...will not allow me..."? Besides using the Wacro, you can always attach a movie node by hand to the Color channel of the Light root node (in both the simple and the advanced view). Keep up the good work...

Hi Cath, this looks awesome. I'm stoked to see that you figured animated IBL out. Movies are perfectly suitable for animated IBL. However, that's not where it ends. You can drive an Image Based Light with any animated shader tree in Poser, even if it is fully procedural.

Hi Cath, the strange black areas you're talking about sound like self-shadowing (the ray hits the polygon it was sent from and reports full occlusion). Modifying the Bias setting (raising it carefully) can avoid such problems. That said, using AO on the lights is the most convenient option and recommended in most cases.

FishNose, you're on the right track. In OpenGL, the resolution of the zbuffer (for sorting polygons back to front) is in fact limited. How limited depends on the card and the driver. Hence Netherworks' suggestion to tweak the Yon, because the less depth the scene has, the less zbuffer resolution is needed. Not sure why adjusting the yon doesn't help, but bringing the camera closer essentially does the same thing.

Thanks Danava for the update. I'm glad to hear the problem is solved for you.

Attached Link: http://www.curiouslabs.com/article/articleview/18?sbss=435

Hi Cath, great renders! If you prefer your light probes in greyscale, you actually don't have to modify the bitmap. You can just plug in the new HSV node (from the Math node category) between the light root node and the image map. Then reduce the Saturation parameter as desired. Same effect, but procedural and therefore quicker and much more flexible.

Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=1676872

Poser 5 with SR4 does not access the internet unless you connect to Content Paradise. Other than that, what your personal firewall might denote as a connection to internet is the network serial check that was introduced with Poser 4.0.3 four years ago. It is a broadcast, and broadcasts are per definition local - no router or gateway would ever forward broadcast traffic, therefore this is not a connection to the internet. In addition, most personal firewalls check the integrity of programs by creating a hash or checksum over the entire executable. If you update an application (for example through SR4), this checksum is different, because the program code has changed. Then, personal firewalls often discard the previously set rules and ask what to do. I assume this is the reason for the repeated discussion of this topic after each update. As far as bypassing the anti-piracy measurements is concerned, this was done as part of SR2. Since the Service Releases are cumulative patches, and SR3 and SR4 carry all SR2 modifications, it is justified to say that also SR3 and SR4 bypass those anti-piracy measurements, even though the logic hasn't been changed since SR2. Makes sense?