Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

no one

rendering idea..

This topic is 5544 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This is my first post at this sight Anyways, Im making a game engine right now, the engine when done will be about 75-80% outdoor, but I need to support for large indoors ares as well. Im using the octrees structure for terrains and I would like to use them for the buildings and such as well, which is no problem, but I dont want to have to implement a bsp renderer as well. My questions is: along with the octrees, im going to use the nvidia occlusion extension, has anybody tried that and if so, how did it work? Thanks alot

Share this post


Link to post
Share on other sites
Advertisement
I haven''t tried it but I just want to mention something.

OpenGL 1.5 will have an ARB occlusion query extension.
Check it out.
http://oss.sgi.com/projects/ogl-sample/registry/ARB/occlusion_query.txt


Basically the same thing with an ARB packaging. Just a heads-up.

Share this post


Link to post
Share on other sites
it worked as expected, so: dont even think about it being an alternative to "common" methods of occlusion culling. i think nv even says so in the specs and try to come up with methods how to make it worthwhile.

result was: doing the tests for the bounding boxes (or even just two crossed lines and everything i could think of) took more time than just rendering the object, so no matter what, it usually was slower than not doing occlusion at all. so unless your objects are REALLY complex its not worth it.

a few of their ideas include testing while doing the normal rendering and only test the visible parts every now in a while. but youd still have to test occluded parts every frame to make sure they still are occluded.

maybe some day somebody will come up with hardware support for frustum tests and different bounding volumes, that would at least allow for letting the hardware do view frustum culling and occlusion either by "inbound" volumes or faster z tests by using the bounding volume. it would have to be something where you can just throw data at the card and say "do it". whenever you have to say "and? whats the result?" the card has to stop doing something useful to send data to you. imagine your boss interupting your work every few minutes and asking you stuff he could just figure out himself. you would soon be annoyed and not get any work done and its not too different here (in general and with that extension).

Share this post


Link to post
Share on other sites
You should indeed only query very complex geometry (decided according to the vertex count).

However, you should probably use the ''HP'' version, instead of the NV one. -As I see it, the HP ''should'' be a lot faster (it doesn''t return fragments).

I haven''t done a full performance test yet, though.




-----------------------------
AM

Share this post


Link to post
Share on other sites
Actually, the HP one should actually be slower, as it introduces bubbles in the pipeline, where the NV extension was created specifically to prevent this ( it still does, but most likely not as bad ).

You have to remember that you''re unique, just like everybody else.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!