Backface Culling / Clipping?

Started by Tangled-Universe, November 20, 2007, 04:35:26 PM

Previous topic - Next topic

Tangled-Universe

Currently I'm rendering a medium intensive render (1 'hero' object and 2 small populations, single powerfractal terrain, 6 layers of displaced fake stones and about 8 surface layers).
So nothing really impressive. However, it takes ages to render. One of the populations is situated behind a rock and only the tops of the trees are visible.
However, they're being rendered completely, THEN being considered as being 'non-visual' in the final image and THEN the rendered trees are covered by the rock. See what I mean?

I know about backface culling in TG0.9x and about the difficulties of backface culling in the current renderer (due to displacements etc.).
So my questions are:
Is there a work-around for this?
Will the next update have more 'agressive' backface culling/clipping capabilities?
It would be a great improvent I think and would save lots of rendertime.

Martin

old_blaggard

Backface culling is something that Planetside has said they will try to implement here, although I don't think that it will be coming along anytime soon.
http://www.terragen.org - A great Terragen resource with models, contests, galleries, and forums.

child@play

it's already in use, as stated here: http://forums.planetside.co.uk/index.php?topic=1013.0

those are the blank spots when you change view in preview window i think
perfection is not when there's nothing more to add, it's reached when nothing more can be left out


Tangled-Universe

Thank you for your responses so far.
What I meant was depth-based occlusion culling as stated in the link.
I hope it will be improved in the next version / soon.

By the way, strange I couldn't find the thread, because I did perform a search before starting this topic. Whatever :)

Oshyan

Improvements to the rendering engine are being worked on but as you are aware it's very difficult to do proper depth-based occlusion culling in a system that relies so heavily on rendertime displacement. You can rest assured that everything possible is being done to improve render times will maintaining quality and consistency. If something works in a certain way it's probably because it's extremely difficult to make it work better, even if it seems unintuitive or counterproductive. Such is the way of complex rendering systems. ;D

- Oshyan

Cyber-Angel

My understanding of the type of Displacement used by TG2 and PR Renderman for that matter (Micro-Triangle Displacement) is that you have two ways of rendering it one is the method employed here and have the displacement rendered at render-time and the other which I don't think has been used yet is to pre-calculate the displacement before transferring to the drawing algorithm for rendering but it is only called by the renderer when required, which form my understanding decreases the  render time by a significant margin (In theory at least).

Regards to you.

Cyber-Angel   

Oshyan

The calculation time ought to be the same since the algorithms are the same. The pre-calculation method would require a huuuge amount of memory though. I imagine it might have some advantages, but the memory overhead probably isn't worth it.

- Oshyan

Tangled-Universe

Thanks for the suggestion CA and the reply and explanation Oshyan.
So there are 2 ways of rendering the terrain.
1) render-time displacements
2) pre-calculating displacements (which needs a lot of memory)
Both of them won't differ much in rendertime, which I can imagine.

Don't understand me wrong. I'm a patient person and don't bother waiting ages for a render to finish, but it feels a little bit useless that (in my case) 75% of the rendertime is due to rendering pixels which aren't visible at the end.

What I meant to say is that, either which of the 2 methods you use, why does the renderer 'choose' to render things first BEHIND objects/hills or the background instead of rendering first what faces the camera? So, building up the image from front till the back. Or am I now talking about 100% depth-based occlusion? :)

Cyber-Angel

#8
Hi Tangled-Universe,

Just to Clarify what I meant just encase there was any confusion over what I meant. I read some where (Don't recall where, and for the record it was not on these forums) that there are two ways of rendering Micro-Triangle Displacement and one of these is to pre-calculate the displacement before it is called be the renderer, this dose not mean that this option is used by TG2 or is possible as when your designing the displacement system you can go one of two routes, the other route which is the one used has Oshyan said which is the one used by TG2 is to use Render-time displacement.

I tend to read a lot of whats out there and try and then try and think of ways they might be used in real life software products. I like to think outside the box has it where the idea of using pre-calculated displacement came to me today while watching some thing on youtube on the workings of the Android SDK (Unrelated subject) as it happens.

As with all things it is wise to cheek all data that is received, as I cannot recall the source and have only done basic follow up research to cheek it for accuracy at this time and will have to stay at that level for the foreseeable future.     

Regards to you.

Cyber-Angel