rendering a large outdoor scene with GI

[Hos]

I was wondering if someone could give me some advice with choosing the best GI method for rendering a huge outdoor scene with a lot of grass and trees.
In this scene I am flying through a about 100km2 large environment populated with a few thousand trees, grass and a few buildings.
For the grass I am using our own created plugin which works about the same way vrayscatter works.
Only this plugin only generates the grass a few 100 meters near the camera and gradually pushes the grass into the ground the further away it is from the camera.
And I am using proxys for all the objects in the scene.
There are 3 methods I know off I can try:
-Using irradiance as a primary and light cache as secondary bounce and then rendering 1 frame with both on the single frame mode and both with camera path on.
Then I save the maps and use those for the rendering.
-Irradiance as primary and light cache as secondary bounce. Irradiance on multiframe incremental with autosave. Light cache on flytrough with autosave.
Then I render the whole sequence on 1 machine on the farm with "don't render final image" checked in the vray globals. Then I render the sequence with the saved irradiance and light cache files.
I don't exactly know what the difference is between the 2 methods is, but it can give me a really large irradiance map file as a result.
If it is larger the a few gigabytes I can't render it because it uses too much ram.
The last method is using brute force for both bounces, but this gives me a really high render time.
I hope I was a bit clear in my explanation. Am I using this methods the right way or is there a better way to do this? And is there a way too use multiple machines to calculate the GI maps?
thanks,

Arjan van Meerten

[aweidenhammer]

I've rendered outdoor scenes with Primary-Brute Force Secondary-lightCache. No baking. Render times are pretty good to me, but to be honest, I do avoid baking solutions as much as possible. If there is really nothing animated in your scene, you could do baking methods. I'm wary of them, due to the length of time it takes to solve/avoid artifacts. I've resorted to baking in scenes that are indoors, and rely on a lot of indirect light. But outside should be very efficient for brute force/light cache.

Andrew

[aweidenhammer]

I've rendered outdoor scenes with Primary-Brute Force Secondary-lightCache. No baking. Render times are pretty good to me, but to be honest, I do avoid baking solutions as much as possible. If there is really nothing animated in your scene, you could do baking methods. I'm wary of them, due to the length of time it takes to solve/avoid artifacts. I've resorted to baking in scenes that are indoors, and rely on a lot of indirect light. But outside should be very efficient for brute force/light cache.

Andrew

[Morbid Angel]

So the plugin that you are using does animate the grass up as the camera gets closer? this would mean animation of objects and baking would not really be an option. However what we did recently was created a method where we would render a single frame irradience map per frame for the entire sequence and then use irradience map viewer to merge all of the maps together into one large map and reuse it for rendering of animation, but keep in mind the geometry in our scene was not animating.

For that method I used irmap for primary and lc for secondary where irmap was set to -3/-1 150/100 samples (high samples are needed to get good gi in trees and grass) and lc with 1000 samples and "use camera path" mode.

[super gnu]

hey Dmitry.. im wondering what the advantage is of your method to create an imap per frame and merge them after? using imapviewer i presume? i cant see how this would be preferable to doing a "multiframe incremental" map set to every frame? id imagine it would be much slower as in the second case vray only calculates the bits not covered by previous frames. ive tried something similar to this in the past (years ago we made a "temporal blender" system that did what "animation mode" does now.

it calculated and saved one imap per frame, then went through,merging each imap with a specified number on either side of the frame, before saving a new merged file. worked ok, but the imaps were very memory hungry ,rendered much slower, and introduced a few artifacts, as there were tons of overlapping samples. )


and regards baking vs. brute force, id lean towards baking every time if no geometry is animated, since -yes, it takes a long time to calculate a decent sharp imap, but a) it can be distributed and b) you save a hell of a lot more time than that when rendering the final frames.

finally wrt the trick of animating the grass.. its quite possible to do this in forestpack.. put the axis ofthe grass patch a few metres below the grass object, then map the vertical scale to a distance texture, or to distance from camera. when the grass scales down it immediately dissapears below ground due to the offset axis. if you set this to happen gradually, a few hundred metres away from the camera, then once its below ground, set the density to 0, you can render unlimited grass. i generally fade the ground texture to a darker more saturated one over the same distance to compensate for the lack of shadowing whent he grass goes.

and it works fine with a precacluated imap btw. the change is so subtle and distant, that you cant see any gi errors, and even if you could, they are static ones.

[Hos]

Thanks for the suggestions,
I also didn't saw any artifacts with rendering the animated grass with a prebaked global illumination map. I think it is to subtle to see. It would made the project a lot more difficult if the there where noticeable artifacts.
But what is exactly the difference between the two first methods I described ("use camera path" and "multiframe incremental")?
Is the difference that you can render the map distributed with the camera path method and with multiframe incremental method you have to render the whole sequence on 1 machine?

[Morbid Angel]

hey Dmitry.. im wondering what the advantage is of your method to create an imap per frame and merge them after?

The advantage is that you use the farm to calculate the entire sequence of frames. Yes you end up with a large file, but for us it was fine.

[Neilg]

I'd go with your second option and distributed rendering.

Turn glossy effects off (and reflection/refraction if possible) when doing the IRmap for a massive speed increase.

[Hos]

I just tried that, but it can render really slow. 80% of the rendertime is spend, translating the scene and transferring the irradiance map.
Eventually I get a huge irradiance map of multiple gigabytes when I use medium irradiance settings.
When I use the camera path method, it will do the scene translation and the irradiance map transfers only once, but I get a small irradiance map (100mb) as a result with the same medium irradiance settings.
Do I just use higher irradiance settings to get the same result as the multiframe incremental method?
It seems to me that this is the most efficient way to pre calculate the irradiance map in my case, but is it possible to get a good detailed irradiance map for the whole flytrough animation with the camera path method?

[CAPTURE_MM]

Our workflow for flights through static environments involves creating the LightCache first (primary+secondary Engine set to LC + the mode set to flythrough, use camerapath NOT checked) The LC hast to be generated on a single machine.
Then the second step is creating the IR-Map with multiframe incremental (camerapath NOT checked) for secondary engine Lightcache with mode "from file" and the LC generated in step1.
The IRMap is then send to the renderfarm, but as a single task on one single machine. Depending on the speed of your camera it´s enough to render every 5th, 10th or maybe even 25th frame)

For rendering the environment Irradiance Map + LC set to "from File" with the files generated in step1+2
Plus we always check "use LC for glossy rays"
Works perfect for static flythrough and is exactly the method described by Chaosgroup in this Max-Tutorial (http://www.spot3d.com/vray/help/150S...ials_imap2.htm)
We are using this method in an actual project with huge outdoor scenes as well.

U could try to render the static part with this method and exclude the animated gras from it.
For the gras u could try rendering it with a Lightdome which uses the same texture ur environment GI does and comp it together afterwards via Mattes etc.
Could be a quite renderintensive solution though, but definatley flickerfree.


Another approach for a whole in one rendering would be to try the Animation (prepass) + Animation (rendering) Modes with LightCache set to single frame (camera path NOT checked) for both passes.
For the prepass u can generate the whole ir-maps on your renderfarm without the need to use a single machine.
There will be 1 IrradianceMap file for each frame which are blended together/interpolated in the rendering process.

Sometimes this method works very well with some tweaking (sometimes it doesn´t and there´s still some flickering :/ )

[Hos]

Thanks for your detailed explanation. I think this would be one of the best ways to get good detailed ir and lc cache for my scene.
Because I don't have that much time anymore, I am still using the camera path method, because I can use all the computers on the farm to calculate 1 ir map.
The only problem with this method is, that it is hard to get a good detailed map. Because I think vray is spreading all the ir samples it would normally use for 1 image over the whole camera path.
I never tried the "use LC for glossy rays" option. I could be very handy for some other shots. For this scene I am working on, I only use speculars. I didn't dare to use glossy reflections with this many trees and grass.