Carrara Rendering with Render Node - image differences
kylborn
Posts: 0
Hello everyone,
I have set up a render node for Carrara 8.5 Pro but when I do a render, the portions of the picture that the render node handled don't quite match the parts handled by the host PC. I'm not sure what to call the phenomenon (artifacting?) so I'm not really having any luck searching for similar cases.
I have attached a sample picture with the effect using one of the prepackaged scenes (not very pretty, just using it to test out the render node). You can see that there are blocks where the colors don't quite match up across the couches, coffee table, and some of the floor and walls.
Here are my machine details if that helps (no overclocking on either machines):
Host
CPU: i7-3770k, 16GB RAM, Win 7 Pro 64-bit, GPU: GTX 680
Render Node
CPU: i7-3770, 16 GB RAM, Win 7 Pro 64-bit, GPU: GT430
As I mentioned, I'm running Carrara 8.5 Pro on the host and installed the Node software on the second pc, both pieces of software are the 64-bit versions. I didn't change any of the preferences from the defaults.
I've read that the GPU doesn't really take part in the rendering and that the process is CPU based, but that is the only real difference between the two machines. I stuck the old GT 430 in the render node mainly because I had it laying around doing nothing, otherwise the render node would be using the built in Intel Graphics.
I'm fairly new to 3D rendering and still have a lot to learn about lighting, shaders, textures, and all that jazz. Any help or enlightenment you can provide would be greatly appreciated. Thanks for your time!
Dave
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Does the render use global illumination?
If you look at the presets where you loaded the room from, you may see some options that say Indirect Lighting or Skylight. Both are a function of GI (which means Global Illumination). There should be a preset with that same room that uses faked GI. Try rendering that and see if you get the artifacts. I have a theory that it is a bug with GI or certain procedural shaders, as I get it with Carrara 7 Pro occasionally and one of my culprits seems to be GI and the Realistic Sky, though not every time.
I suspect the batch renderer does not honor scene scale correctly... Wasn't there a thread that compared differences in GI in scenes where the scale has been set differently?
There may have been. I know that some shader functions won't render properly over a network, such as squares. Well, that's not entirely true. My PPC based Macs render the squares correctly, but the Intel iMac renders them differently. The scale looks the same, just the state that the square is supposed to be in, say a color. If I have black and white squares, the PPC Macs are in sync with each other as to which are black and which are white. The Intel iMac will render the pattern differently. This will happen using the standard renderer with no GI as well as with GI.
Another area that gets screwy is if I have intersecting volumetric clouds. There will be a distinct difference between the PPC and Intel nodes. The gamma looks different. If I have multiple clouds and they don't intersect then all seems well.
I also have a problem with Howies' trees rendering differently, even though the leaf shapes are on the nodes. Carrara's native trees work just fine.
Could it be that how the PPC and Intel chips handle the math required for these functions be the cause?
Thanks for the replies.
Yes, the scene I was rendering uses GI. It is the first indoor default scene. I have attached a screen clipping of what the render panel shows are the defaults when I load it into the batch queue.I loaded up the FAKE GI scene and on top of it rendering over 100 times faster, it does seem more uniform, but also darker (I'm guessing because of the different settings). I have attached that result as well.
Sounds like I just happened to pick a test subject that has inherent node-rendering issues (the scene renders uniformly without the render node). I will toy around with Global Illumination settings and see where the node starts to have problems. Even if I don't completely understand the technical reasons behind it al least I can try to establish some hardware limits for myself.
Not sure if this information will be useful for anyone else, but before I saw any replies to this thread I figured I'd take out the two discrete graphics cards from each machine so that they were both running the Intel HD Graphics 4000. There was no appreciable difference in the results in render quality or duration.
You two have given me plenty of new stuff to research, as well. Thanks again for taking the time to comment.
Learning to fake or simulate GI effectively is not a bad thing. One big advantage is the time hit that you get when rendering with GI. Still shots don't matter as much, but for an animation it is a very useful skill to have.
If you wish to use GI to render your scenes, there are some tricks to help with that as well.
The important thing to remember is that usually there are multiple ways to get to a goal, and as long as you get the result you want, then they're not wrong.
I've been developing a scene lately that I think looks better with faked GI than with GI. I've also had scenes that I have had a devil of time getting to look without GI. I have an old computer, so I tend to avoid GI as much as possible. If I had a new machine with multiple cores, and tons of memory, I may go the other way.
By the way, your observations about the graphics are correct. Carrara's render engine is strictly CPU based. There is a plugin for Luxrender and one in development for Octane, which holds the promise of GPU rendering, but those are outside of Carrara. The real help that a powerful graphics card provides is in the Assembly Room view. That is an OpenGL preview, so the faster the card, the smoother the performance.
Hi kylborn.
I haven't used the render nodes yet, but it appears that one PC is calculating the global illumination differently than the other. So what happens is, one computer calculates the lighting(photon maps) in slightly different configuration. This results in the render tiles borders showing up in the image.
Its similar to what happens with GI animations where each new frame causes flickering because the photons are calculated differently at each frame. When I tested this, the lighting seem to crawl along surfaces.
Carrara Pro has an irradiance map feature that might work to eliminate the issue. It creates a map of the light bounces from a GI render and saves it out as a map file. I'm guessing the render nodes can use this map as well. Let me know if you need more irradiance map info.
edits: added a better description and I'm using C8.1 Pro 64 bit, so this could still be a bug with GI in C8.5.
I really appreciate everyone's input.
To create the uniform irradiance map, I used only the host computer to render the scene and saved the map.
Then I added the scene to the batch queue, chose network rendering (host + node), and launched.
Results: The host computer made use of the irradiance map but the node did not.
I'm making this deduction because:
1) The blocks rendered by the host were done in a few seconds (using the precalculated light from the saved map) instead of several minutes.
2) The blocks rendered by the node took minutes instead of seconds (calculating it's own light behavior), and
3) The blocks rendered by the node still did not match the lighting of the host (render tile borders still showing).
That was a great suggestion and it seems to have narrowed down the cause (at least in this instance). I will keep digging. Maybe this is already on their list of things to fix.
To be continued...
Wow. That almost cancels out the need for nodes in the first place. :wow:
In the example above where it took seconds to render, there was no change in the scene at all (camera in the same position and orientation). So I did the following to further my understanding of how the irradiance maps work:
1) Rendered scene (Preset-Indoor-Day) with an initial camera angle (label it angle 1 for this purpose). No irradiance map is used to render but this render generates an irradiance map which is saved to the hard drive as it's own file.
2) Adjust camera angle in the same scene (angle 2) and render again without irradiance map to establish an initial render time. (Result= 4 minutes, 39 seconds).
3) Keep camera at angle 2 and render scene using irradiance map generated from scene using camera angle 1. (Result= 1minute, 47 seconds)
So it looks like if you render a scene that has no changes using an irradiance map it will go incredibly fast, but you are really just rendering the same scene again.
Use of the irradiance map in the scene where I changed the camera angle resulted in a render duration of less than half the time it took to render a scene without an irradiance map (1min 47sec vs 4min 39sec).
Note: No render nodes were used to generate any of the renders in this post.
In the example above where it took seconds to render, there was no change in the scene at all (camera in the same position and orientation). So I did the following to further my understanding of how the irradiance maps work:
1) Rendered scene (Preset-Indoor-Day) with an initial camera angle (label it angle 1 for this purpose). No irradiance map is used to render but this render generates an irradiance map which is saved to the hard drive as it's own file.
2) Adjust camera angle in the same scene (angle 2) and render again without irradiance map to establish an initial render time. (Result= 4 minutes, 39 seconds).
3) Keep camera at angle 2 and render scene using irradiance map generated from scene using camera angle 1. (Result= 1minute, 47 seconds)
So it looks like if you render a scene that has no changes using an irradiance map it will go incredibly fast, but you are really just rendering the same scene again.
Use of the irradiance map in the scene where I changed the camera angle resulted in a render duration of less than half the time it took to render a scene without an irradiance map (1min 47sec vs 4min 39sec).
Note: No render nodes were used to generate any of the renders in this post.
The manual states the irradiance map calculates the photons for the entire scene, so you can use the same map for multiple camera angles, and as long as you leave the objects or lighting in the scene alone, it won't have an effect. You could even animate the camera moving through the scene, though not elements in the scene.
Also, you can render a low-res radiance map by reducing the resolution of the render that generates the map, and still use the low-res irradiance map for your full resolution render.
The irradiance map is the same as the render room output tab Multi-Pass Global Illumination pass. It's the diffuse light bounce in the scene. It doesn't bounce light from reflective or shiny materials surfaces like a mirror shader though. Caustics is needed for that.
Adding to what EP said. Because you are viewing a previously saved map from any angle, its perfect for architectural stills and fly through camera animations. While you can move/exclude objects, change shader's, and even load other maps, the scene or animation might not look correct then. The PDF manual suggests you can get some nice scene effects by doing this.
Since the render nodes appear to have issues with GI scenes, the link below has suggestions on photon mapping and scene scales to help speed up GI rendering.
http://www.daz3d.com/forums/discussion/30935/
This information is great and I'm very appreciative for all your input.
It's too bad that the render node doesn't play well with global illumination since it seems like the perfect situation to be able to use a node to help with the heavy calculations/computations. Maybe there is a setting I am missing that allows the node to reference the irradiance map. I'll let you know if I dig up anything else on the subject.
I have had successful GI renders over nodes in the past. I have had some hit and miss luck manually transferring the irradiance map to the node. I'm not sure where it resides on a PC, but on a Mac, the daz temp file is in the Documents folder. When network rendering, the scene file and any texture maps are transferred to the temp file, so moving the irradiance map manually to the temp file ahead of time,may let the node use it. Sometimes it works for me, other times it doesn't. I haven't figured out a rhyme or reason to it. Then again, I haven't really studied it much.
Speaking of the node's temp file, it is a good idea to clean that out once in awhile as it doesn't get emptied out automatically, and it is easy to get hundreds of megs. or even gigs of data left in there.