I know a lot of focus is on the GPU rendering because it's so much faster. Who wouldn't want a render done in 5 minutes rather than 5 hours? But has anyone tried the problematic shaders in a CPU rendering. If I recall, the GPU and CPU rendering always was different.

from what i've seen so far there's no diff. but then again i'm colourblind. ;)

Same issue with shaders regardless of what you render with, CPU or GPU. Updated Cycles break Superfly rendering of previously used skins and a lot of material shaders.

@RedPhantom The issue in the past with CPU renders looking different than GPU render was down to the clamp settings. In CPU it turned this off and (no clamping) so CPU would calculate for ALL the lighting while it turns clamping on for GPU and you can experiment with how much clamping there is. The issue was that it was never really explained to the users this would have a profound impact on SOME renders. It matters how many lights you have and how small and intense they are. It took me more than a year to figure out what exactly was going on with the renders just because it wasn't all renders. Very puzzling.

Wow. So, this should have been in the manual or at least in some tutorials and never got there?

It looks more like no one either never notices or didn't bother to pursue further testing. I wonder if anyone opened a ticket on it.

hborre posted at 9:38AM Wed, 04 November 2020 - #4403213

It looks more like no one either never notices or didn't bother to pursue further testing. I wonder if anyone opened a ticket on it.

It's not a bug, It's just the way Superfly is. It's just that there was never any official explanation as to why renders would look different. Turning clamping off makes fireflies in renders with super high dynamic range lighting. The HDR images that are dark with one or more super bright points of light in them are the ones that show this the best. The fireflies are not render errors, they are HIGHLIGHTS that take a huge amount of time to calculate. If you let the image render for 100 samples or more you will see the patterns emerge and turn into bright highlights from the sun or small, bright lamps in the hdri. Using the background to light a scene works way better but the background image is all twisted around.

Ah, that explains a bit of what I've been seeing in conjunction with some information I read in the manual. Believe me, I read those paragraphs multiple times just to make sure I understood the concept. Now, you mentioned super high dynamic range lighting and its effect on increased fireflies with unclamped rendering, am I correct to assume that if I use a lower range HDRI under the same conditions I would eliminate most, if not all, fireflies sacrificing some highlighting? This is intriguing and deserves a closer look. Thanks.

@hborre Yes, the lower the dynamic range the cleaner the render. The cleanest will be if you use a jpg instead of an HDRI. This is if you are using a dome for lighting. If you use the background as your HDRI then it renders cleaner AND you get the highlights from lamps and the sun in the image. I still haven't figured how to sort out the way the background image is all flipped around when using that. using the background for lighting is also SUPER fast. Have a look at the lighting results. That huge highlight on the figure is from the background. There are no lights used in this render.

Thanks all for indulging me. This is interesting

This has been very insightful. I definitely want to play around with this further. I do have some sIBL and HDRI editing programs on my system that can assist in manipulating images I have downloaded. Thank you very much for the informative clarifications.

The twisted backgroundimage can be fixed with a mapping node. I posted the setup in my posting about the shadow catcher.

Rotation value in the mapping node: 4.900000, 3.150000, 0.000000

Works:

HDRI-Image on the background shader.

bantha posted at 11:12PM Wed, 04 November 2020 - #4403299

The twisted backgroundimage can be fixed with a mapping node. I posted the setup in my posting about the shadow catcher.

Rotation value in the mapping node: 4.900000, 3.150000, 0.000000

Thank you so much ?

for some reason those settings don't do anything to make the background image upright for me.

@ghostship2: I have been playing with your node arrangement for background projection of HDRI maps and I would like to make a recommendation. Use the Normal connection on the TextureCoordinate instead of Generated, and on the Mapping node change the Vector Type to Texture instead of Point. I believe this will invert the projection. Use the upper Location, Rotation, Scale values to control the translation of the background.

I think I figured it out. It's the first set of rotation numbers not the second

@hborre cool! I'll take a look at that.

Yes, the first set works.

Here we go. Quick render using LF and an 8K HDRI. The higher the resolution the better the background sharpness. To be honest, try to cap it off at 4K. Below are the changes I made to the nodes, I think it works better. Using a 360-degree panorama, I set the x rotation to 90.

yes, getting good results with this. Remember to set clamping to 0 and turn off any extra lights you have. Let the background light the scene. The highlights in her eyes really pop with this lighting.

@hborre Don't bother with huge HDRI's. I always use DOF blur to separate the figure from the background and then only need the smaller (2k) size images. More than that and you are using precious GPU ram for the background.

Okay, can I ask some really stupid questions? What are you putting the HDRI on? And what are those unconnected nodes in your setup?

@Rhia if the node is unconnected then don't worry about that. I have some voodoo about nodes for the background lighting setup because lighting a scene this way in P11 was serious Poser crash time. Looks like it is pretty stable now!!!!! This is what we are talking about:

Go into the Material Room and pull down the contextual menu on Object on the right. In the menu, you will see Background. The disconnected nodes are for either image projection or colorization.

another example of studio lighting with the background object. No lights used for this render.

Beautiful render.

Neat, now I just have to figure skin shaders that don't look like ass. Thanks guys!

So everything works beautifully, but the background image does not show on the render. It is an HDRI. What am I doing wrong?

Good luck. Right now, I'm experimenting with an HSV and color node to tint the background and change the HDRI light output. Getting some nice surreal effects.

Did you hide the construct?

Yeah, I start with a plain scene without construct.

The grey background is with GPU rendering. With CPU, what I am getting is the 'floor of the image, if you will.

I'm sure it's a simple answer, so sorry for all the questions. This program version forces me to stumble around like a complete noob for Poser after such a long time using it. Thanks for answering me!

The rotation first number should be set to approximately 90-degrees to appear normal. Click on the first rotation value at the top, you will notice 3 numbers separated by commas. In order, the numbers correspond to X, Y, Z-degrees global axis. Those numbers should look like this: 90.00, 0.00,0.00. Adjust as needed to match the HDRI.

Ahh. Thank you.

Lol.... I don't get anything working with your settings... I have to enter -90° for X, but in radians:![Sasha-Jinky7.jpg]

I've tried Point -> generated and texture -> normal: no success. Anyway, it looks like I've found something working, yay ?

Looks like the background node is loosing its rotation and scale parameters upon reloading a Poser project file...

Ugh. I'll test that after work today, but if so, that is a bug to be filed.

Y-Phil posted at 10:15AM Fri, 06 November 2020 - #4403582

Looks like the background node is loosing its rotation and scale parameters upon reloading a Poser project file...

Same issue here. Also after changing the rotation values back to something usable Poser still not registering a change to the file so "save" is still greyed out. Also last night I edited a file and then clicked the "X" in the upper right corner to close the program and Poser just quit without any warning about saving my work.

I just tried to force save the file after changing the rotation values of the Mapping node. "Save As..." did not save the changes either.

Saving the background shader as a preset doesnt work either. The rotation setting reset to 0,0,0

ghostship2 posted at 9:58PM Fri, 06 November 2020 - #4403620

Saving the background shader as a preset doesnt work either. The rotation setting reset to 0,0,0

You've experimented that same effects as me. I suppose that the devs consider the atmosphere, the background and probably the universe objects as more or less read-only: editable as long as nothing important is changed, except when a scene is imported for example....

From what I've understood, these parameters are effectively stored in the PZ3 file (near the end) but it looks like they are not interpreted

Y-Phil posted at 2:24PM Fri, 06 November 2020 - #4403634

ghostship2 posted at 9:58PM Fri, 06 November 2020 - #4403620

Saving the background shader as a preset doesnt work either. The rotation setting reset to 0,0,0

You've experimented that same effects as me. I suppose that the devs consider the atmosphere, the background and probably the universe objects as more or less read-only: editable as long as nothing important is changed, except when a scene is imported for example....

From what I've understood, these parameters are effectively stored in the PZ3 file (near the end) but it looks like they are not interpreted

It's a problem with the mapping node itself. I have a previous version of this background shader that is saved to presets that works fine in P11.

Everything worked in P11. Le sad sigh.

Good news: the Background node parameters seem to be restored upon loading a scene, with Poser 12.0.276

I saw the release notes and was hopeful I interpreted that correctly. Yay!

OK. Now that it's working can someone smarter than I explain the 3 coordinates? what value rotates the image by 90 degrees or 180 degrees? Is there a way to have the background show up in preview so I don't have to guess where the image is rotated to?

ghostship2 posted at 10:20AM Sat, 07 November 2020 - #4403675

OK. Now that it's working can someone smarter than I explain the 3 coordinates? what value rotates the image by 90 degrees or 180 degrees? Is there a way to have the background show up in preview so I don't have to guess where the image is rotated to?

From what I remember of trigonometry: 90° = 1.57 (rad) = 100 (grad) = a quarter of a circle