Cull occluded objects or not?
Blitz3D Forums/Blitz3D Programming/Cull occluded objects or not?
| ||
I've been messing around with some code to cull occluded objects on a blitz terrain. Whilst the code works very well I am not convinced that I am actually getting any benefits. The processing required to work out if an object is really occluded seems to negate the need to such a system. It can actually be faster just to chuck all the polys at the GFX card and use some LOD. In my tests of 10,000 objects it's faster just to throw everything at the GFX card and be done with it. Does this sound familiar? |
| ||
It's how the modern HW works... it's so fast that trying to be "smart" (like in the old days) about what to draw just usually slows down rendering (and fps) :) |
| ||
Sounds familiar to me, I have just about finished rebuilding my terrain engine and I played with allsorts of idea`s but in the end I just use a basic system to control how/when many objects are drawn and chuck it all at the card. Frame rate is fine and its simple. |
| ||
Unless you can cull big batches of objects with a couple of lines of code then throwing everything at the graphics card is the way to go. |
| ||
Proper *pre-calculated* occlusion will always make for big speed gains, even on tomorrows hardware. |
| ||
But how do you go about pre-calculation? where do you put all that data? and how would you structure it? |
| ||
Proper *pre-calculated* occlusion will always make for big speed gains, even on tomorrows hardware. Even then, if you're throwing small batches at the card, you're effectively stalling the pipeline. I imagine throwing entire Quake1 levels at the card is faster these days than trying to use the precomputed vis information. |
| ||
EpicBoy - that might be true somewhere, but not in Blitz. Try it: take a Quake BSP and load it into Blitz as both a BSP and a standard mesh, OR take a map made in Quill, and test it with and without Quills portal occlusion. The point of occlusion is that you throw less of the map at card/render-pipeline generally, regardless of whether its all one mesh or lots of small batches. I really think you are mistaken here. Flynn - there are many ways, but the simplest one right now is to build your levels in Quill and use its built in portal engine. Works very well. If you want to roll your own, I recommend trying to setup a world editor that lets you define your portals (there are many ways to do this). And, you then store your occlusion data either in the b3d (blitz ignores chunks it doesn't recognise) or in a seperate file. Good luck! |
| ||
I'm happy with the portal stuff for "indoors", it's the "outdoors" that I've for the problems with. |
| ||
I found that it was the law of diminishing returns. I was 'Hiding' and 'Showing' lots of entities depending on visibility, but after the number of entities rose over 80 (yes I did need them all) it made almost no difference. |
| ||
John - Maybe you aren't grouping them properly. Also, which version of BB3D are you using? Flynn - do you mean terrains, or just open walled areas? |
| ||
I'm using a view cull and have removed all the rear facing polygons from my static meshes. If I threw the whole level at the graphics card It would choke even a fast card. Finding a smart occlusion technique would be optimal. The more fps room you have to move around the better especially If you want that optimization so you can include a lot of special effects. :) |
| ||
I mean terrains. |
| ||
@ Masterbeaker - Just curious but is there known problems in certain versions of BB3D which may apply to what John is doing? |
| ||
Older versions of Blitz3D had slower Hide/ShowEntity commands. Flynn - seen from ground level or the sky? |
| ||
@Masterbeaker - From ground level |
| ||
@MasterBeaker: I'm using 1.86. By grouping, do you mean welding all my meshes together? - Not possible since many have to be clicked on independantly. |
| ||
"Not possible since many have to be clicked on independantly." Sure it's possible. You have the visible ones which are welded, and then you have invisible seperate ones, or use pivots to represent the collision radiuses. |
| ||
Oh, _that_ kind of grouping... them that are visible and that aren't. Yeah, I already do that, according to entities within a 'sector'. Hang on sswift I just re-read you post... do you mean 'have all entities doubled up; half visible and welded, and held invisible and unwelded?' (Brain-lock!) |