Feature Request: Terrain First, Sky Second Render Order

[Cyber-Angel]

This feature request comes out of practical experience of using the Technology Preview, but since the most complex aspects of rendering a scene is the terrain and bodies of water (Clouds excluded due to them been a sky issue) could we in future have an option of having the renderer (If technically feasible) to render the terrain first then the sky which is less complicated and generally is faster to render?

The second part of my request for the renderer is to have a better means of indicating which area of the terrain is been worked on currently, as it is difficult some times to tell which is the current area been rendered, thusly making it hard to discern how long that section will take to render.

I realize that this request will not be high on the priority list any time soon however it could save some time under certain circumstances which is always a good thing. '

Regards to you.

Cyber-Angel   

[Oshyan]

I don't really see the benefit of the first request. It's also extremely difficult to estimate how long something might take to render, even if you know what area is being rendered, so I'm not sure how useful the 2nd idea would be for that purpose, although I do think it's nice to know what area is being rendered. That would definitely be low priority to implement though.

- Oshyan

[moodflow]

Hi Oshyan,

On a tangent (though related) subject - do you know if back face culling will be implemented in this next release?  I think this would speed up render times for some scenes significantly (especially those with plenty of terrain relief).

[Oshyan]

As previously discussed backface culling *is* implemented and it certainly does help render times. It's not perfect, but it works fairly well. Occlusion culling is also implemented but is more problematic and would have a bigger impact on render time. It's difficult to do properly because of the heavy use of displacement for terrain shape. The displacement is computed at render time dynamically so it's difficult to pre-determine what areas of the scene will be covered and not render them pre-emptively. I believe a coarse version of the displacement is used for occlusion culling at present, which is why it's not ideal, but this is a trade-off for speed in other areas and memory use.

- Oshyan

[moodflow]

As previously discussed backface culling *is* implemented and it certainly does help render times. It's not perfect, but it works fairly well. Occlusion culling is also implemented but is more problematic and would have a bigger impact on render time. It's difficult to do properly because of the heavy use of displacement for terrain shape. The displacement is computed at render time dynamically so it's difficult to pre-determine what areas of the scene will be covered and not render them pre-emptively. I believe a coarse version of the displacement is used for occlusion culling at present, which is why it's not ideal, but this is a trade-off for speed in other areas and memory use.

- Oshyan

Ahh ok, I was still under the impression it was not.  Thanks for clearing that up - thats very good to know. 

I did notice however, that certain areas behind a ridge in one of my images was still being rendered, even though it was eventually going to be blocked by the ridge.  This is what solidified my belief that it was not in effect, though this was likely due to the effects you just mentioned.  I have noticed render times have improved somewhat compared to the initial release.