Forest shots

Started by KyL, November 14, 2016, 12:27:40 PM

Previous topic - Next topic

Kadri

Quote from: KyL on December 02, 2016, 11:31:39 AM
...
For the last shot though I couldn't get a clean render without ridiculous rendertimes so I ended up doing a lowres version of the forest and bring it in Nuke to project two 4k frames on it. This worked surprisingly well!

Exported the forest object and used front projection from 2 different angles? Have i understand it correctly Kyl ?

KyL

Yes. I replaced all the trees with a low resolution mesh so I could export everything as a .fbx through the micro exporter. I brought this geo into nuke and projected a render of the first and last frame onto that so I could then animate the shot camera. This made Nuke hit my 32Gb limit when rendering a 4k sequence of this though!

Oshyan

With evergreens, sometimes the very fine foliage (needles) can make it very hard to antialiasing during rendering, thus requiring higher-than-normal AA settings. A possible solution is to use simpler tree geometry and textures, if you can get away with it.

- Oshyan

KyL

That's what I did acutally, the geometry was quite simple but using branches/needles textures with opacity. I am reworking the trees for a future project with this time real geometry for each needle, I will see if it get any better or worse...

But this kind of shot with so much fine details will always require crazy high AA, regardless of the render engine. 16 AA is not that bad actually!

KyL

Quote from: Ariel DKMultimedia on December 02, 2016, 12:28:35 PM
I'm sorry if I misunderstand what you meant, but are you saying that it took 3.5 or 4 hours each frame?? BTW I also understand that you use AA of 16?
If so, let me tell you: that, is an extremely high setup and render time. rarely I use AA 8 or higher. if you have noisy renders, there is something in the scene that cause it. maybe you forgot, or you ignore it, but there is many ways to optimize any scene in TG: for example check the atmos quality, if you are using fog, check there is an excessive setting or unnecessary like "recive shadows from surface" enable or "cloud quality" in 0.2, for example. GI settings can also very problematic. I dont know, just to keep it in mind for your next animation, assuming I understood correctly what you meant :D

yes that was per frame render time  :P.

And actually I can tell you it's not bad!
I ran many tests and spent lots of time finding the best compromise between quality and render time. I was running crop regions with different AA settings, detail and even lower resolution texture but it all came to the same result: fine details requires high AA.  Atmo quality was set to 24, clouds to 0.3 and of course surfaces were not tracing shadows on the atmosphere or clouds.

But to be honnest it makes sense as most of the time is spent on the raytracing process of the objects. This was one of the things Terragen was a bit slow at that time, but with the implementation of the Embree core in TG4 it is much faster (thumbs up Matt!). Now I can have the same scene rendered in twice the time, or I can trace the objects shadows into both atmosphere and clouds at no additional cost (compared to TG3)

Considering that this was a 2K full cg environment with displacement, billions of triangles plus the extra shading time, I find it to be pretty good. I am still waiting to see any other renderer rendering the same scene faster.
I know for sure that a scene like this rendered in Arnold for example would take at least the same time, if not (much) longer. And usually most of the time you don't have atmosphere or volumetric clouds as this comes as an extra pass and therefor extra render time. This would also be without the spectral lighting, which would also be quite expensive. However a brute force renderer like Arnold would probably give much nicer GI.

Speaking of GI, I could have had a better GI solution I think as interpolating 5-frames caches was adding a solid 15-20min per frame which seemed a bit heavy. But I was to lazy to run too many tests on it that so I just let it run. The indirect illumination in this scene is not really important anyway.

But I can assure you that 3.5-5h per frame is quite standard in the vfx industry. I've seen and continue to see much (much MUCH) higher render times at work!  :o

Kadri

Quote from: KyL on December 02, 2016, 04:46:07 PM
Yes. I replaced all the trees with a low resolution mesh so I could export everything as a .fbx through the micro exporter. I brought this geo into nuke and projected a render of the first and last frame onto that so I could then animate the shot camera. This made Nuke hit my 32Gb limit when rendering a 4k sequence of this though!

Thanks.

dorianvan

Quote from: KyL on December 02, 2016, 04:46:07 PM
I replaced all the trees with a low resolution mesh so I could export everything as a .fbx through the micro exporter. I brought this geo into nuke and projected a render of the first and last frame onto that so I could then animate the shot camera.

You still did your final rendering in TG, right?
What do you mean by "low resolution mesh"? Did you create it within TG? Was it still individual trees, just super low res?
The first/last frame was projected onto the mesh in Nuke? Why first/last? I can't imagine what that looked like on a Nuke preview render (I use AE ((cheaper!)).
I had frames on one scene (filled with palm trees, grasses, etc.) that took 13 hours per frame (300 of them!), but I still think I did something inefficient.
Thanks.
-Dorian

KyL

Yes the frames were rendered in Terragen.
The Nuke part I did was only to have the camera motion.
The trees were created in Speedtree and by low resolution mesh I meant a super light tree, something like less than a hundred poly each. I had to do this because of the number of trees. Trying to export the default ones would have created a file of several GB, and there would be no way you could use that in any compositing software.
I did the first and last frame because of the camera animation: if I were to project only one frame there would be stretching if the camera moves too far from the projected image.
You could probably do the same thing in AE though I am not sure how well it handles heavy geometry. I used it for my lens flare btw.
There is a free version of Nuke available if you want to learn, you can do quite a lot of things with it!

13h sounds like a lot but sometime that's what it takes!

Ariel DK

Quote from: KyL on December 02, 2016, 08:17:43 PM

yes that was per frame render time  :P.

And actually I can tell you it's not bad!
I ran many tests and spent lots of time finding the best compromise between quality and render time. I was running crop regions with different AA settings, detail and even lower resolution texture but it all came to the same result: fine details requires high AA.  Atmo quality was set to 24, clouds to 0.3 and of course surfaces were not tracing shadows on the atmosphere or clouds.

But to be honnest it makes sense as most of the time is spent on the raytracing process of the objects. This was one of the things Terragen was a bit slow at that time, but with the implementation of the Embree core in TG4 it is much faster (thumbs up Matt!). Now I can have the same scene rendered in twice the time, or I can trace the objects shadows into both atmosphere and clouds at no additional cost (compared to TG3)

Considering that this was a 2K full cg environment with displacement, billions of triangles plus the extra shading time, I find it to be pretty good. I am still waiting to see any other renderer rendering the same scene faster.
I know for sure that a scene like this rendered in Arnold for example would take at least the same time, if not (much) longer. And usually most of the time you don't have atmosphere or volumetric clouds as this comes as an extra pass and therefor extra render time. This would also be without the spectral lighting, which would also be quite expensive. However a brute force renderer like Arnold would probably give much nicer GI.

Speaking of GI, I could have had a better GI solution I think as interpolating 5-frames caches was adding a solid 15-20min per frame which seemed a bit heavy. But I was to lazy to run too many tests on it that so I just let it run. The indirect illumination in this scene is not really important anyway.

But I can assure you that 3.5-5h per frame is quite standard in the vfx industry. I've seen and continue to see much (much MUCH) higher render times at work!  :o

Thanks, and good to know that. indeed, Arnold is little more faster than TG managing vast and complex geometry, but add a little bit volumetric fog/ clouds, etc
or inclusive the "skin shader" and "glass shader" for example, and you will see how change the render times drastically (more longer). actually I'm using AtoC4D
Hmmm, what version of Terragen does God use?

Oshyan

Ah, good to know. Thank you for the details KyL. :)

I shouldn't say too much, but we're working on further optimizations to the rendering which might make it even a bit faster (though nothing so dramatic as the reduction in times from switching to Embree). You might also want to take a look at Matt's Twitter or G+ account some time... :D

- Oshyan

dorianvan

Quote from: KyL on December 03, 2016, 11:37:58 AM
...if I were to project only one frame there would be stretching if the camera moves too far from the projected image.
The camera in the forest shot I saw was a great distance from start to finish. I must be missing something.
-Dorian

KyL

Quote from: dorianvan on December 03, 2016, 06:26:02 PM
Quote from: KyL on December 03, 2016, 11:37:58 AM
...if I were to project only one frame there would be stretching if the camera moves too far from the projected image.
The camera in the forest shot I saw was a great distance from start to finish. I must be missing something.

I was talking about the third shot I posted on the first page of this thread, not the day helicopter shot or the night one.

Quote from: Oshyan on December 03, 2016, 02:24:39 PM
Ah, good to know. Thank you for the details KyL. :)

I shouldn't say too much, but we're working on further optimizations to the rendering which might make it even a bit faster (though nothing so dramatic as the reduction in times from switching to Embree). You might also want to take a look at Matt's Twitter or G+ account some time... :D

- Oshyan

I just found something very interesting indeed! Can't wait to see a first implementation of this. This looks really promising!!!