Occlusion culling
i have also work for an lod in irrlicht
the main idea is
int lenght_ = 500;
while()
if (camera->getpos() > objet->getpos()+ lenght)// dont work likle this , you may have getpos().X so multiply condition by 2 or 3 like:
camera->getpos().X > objet->getpos().X+ lenght || camera->getpos().Z > objet->getpos().Z+ lenght
//Secondly, you must have positive values or do that :
#include "math.h"
if ( abs(camera->getpos() > objet->getpos()+ lenght))//
//third, a lod exist for irrlicht ; with boxes but not very hight performances ?
http://khayyam.developpez.com/articles/3d/irrlicht/lod/
//you may have binary mesh for dynamic rendering
//i think that LOD change with distance is better than LOD change by time , if there is any time required , but it is very "rare"
Lod:
for (each objects)//for (int i = 1; i< maxnodes;i++)
nodehight->setvisble(true);
nodelow->setvisble(false);
else
nodehight->setvisble(False);
nodelow->setvisble(true);
//declare (pseudo code) irrscenenode nodehight[100]= 0;
nodehight[1] -> addanimatedmesh // same for nodelow
this kind of lod work for me.I know that the code is node in state-of-art.but it work (it is enought for me).next, i have ideas of a decimate mesh engine each 100 meters.For terrain and others complexes géométries :
the idea :
int distance = 100;
int olddistance = camera->getposition
while()
if (camera > olddistance+100)
{ olddistance = camera->getpos //2 (X and Z)
for (each vertex in mesh)// HOW to do that ? help ! (vertex3d , any specialist of that ?)
{ (if vertex.posX > distance)
remove vertex;
}
//construct new mesh in super low
for (int i = 1;i< max vertex ;i+=4)//lod
construct new mesh
}
//advantage
we know absolute position of player
a unique mesh that contain complexes model like moutain or usine etc...
//possibility of multiple resolutions of texture (new super low model = assign a super low texture (decal and positions of texture can or must be know, imporving performance rendering
//i don't like megatexture of id teck5 RAGE , i beleive that hardware can be improve in rendering like an another way, like texcoord.
sorry for bad english (iam french)
the main idea is
int lenght_ = 500;
while()
if (camera->getpos() > objet->getpos()+ lenght)// dont work likle this , you may have getpos().X so multiply condition by 2 or 3 like:
camera->getpos().X > objet->getpos().X+ lenght || camera->getpos().Z > objet->getpos().Z+ lenght
//Secondly, you must have positive values or do that :
#include "math.h"
if ( abs(camera->getpos() > objet->getpos()+ lenght))//
//third, a lod exist for irrlicht ; with boxes but not very hight performances ?
http://khayyam.developpez.com/articles/3d/irrlicht/lod/
//you may have binary mesh for dynamic rendering
//i think that LOD change with distance is better than LOD change by time , if there is any time required , but it is very "rare"
Lod:
for (each objects)//for (int i = 1; i< maxnodes;i++)
nodehight->setvisble(true);
nodelow->setvisble(false);
else
nodehight->setvisble(False);
nodelow->setvisble(true);
//declare (pseudo code) irrscenenode nodehight[100]= 0;
nodehight[1] -> addanimatedmesh // same for nodelow
this kind of lod work for me.I know that the code is node in state-of-art.but it work (it is enought for me).next, i have ideas of a decimate mesh engine each 100 meters.For terrain and others complexes géométries :
the idea :
int distance = 100;
int olddistance = camera->getposition
while()
if (camera > olddistance+100)
{ olddistance = camera->getpos //2 (X and Z)
for (each vertex in mesh)// HOW to do that ? help ! (vertex3d , any specialist of that ?)
{ (if vertex.posX > distance)
remove vertex;
}
//construct new mesh in super low
for (int i = 1;i< max vertex ;i+=4)//lod
construct new mesh
}
//advantage
we know absolute position of player
a unique mesh that contain complexes model like moutain or usine etc...
//possibility of multiple resolutions of texture (new super low model = assign a super low texture (decal and positions of texture can or must be know, imporving performance rendering
//i don't like megatexture of id teck5 RAGE , i beleive that hardware can be improve in rendering like an another way, like texcoord.
sorry for bad english (iam french)
Hello
Re: Occlusion culling
Bumping this old thread, does anyone have the occlusion culling source?
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Re: Occlusion culling
Occlusion culling is part of the engine already, and we have an example for this as well.
Re: Occlusion culling
Well, not in the 1.7.3 version, but it is in the nightly builds, from what I understood.
Re: Occlusion culling
occlusion culling queries are just bad in irrlicht dont use them, rewrite according to OGL (only 5 function calls, consult NVIDIA on efficient occlusion culling so you dont stall CPU etc.)
We had 1000 nodes and it was eating 25% of our frame time because of the SOccQuery struct and poor design (linear search, TWICE because of CNullDriver and derived method!!! - then you have 3 different methods to run occlusion query,update and return the result ---- LOL)
P.S. Søren get here and explain
We had 1000 nodes and it was eating 25% of our frame time because of the SOccQuery struct and poor design (linear search, TWICE because of CNullDriver and derived method!!! - then you have 3 different methods to run occlusion query,update and return the result ---- LOL)
P.S. Søren get here and explain
Re: Occlusion culling
Honestly I don't see why I should re-create the wheel right now.
Why rewrite something instead of improving the one in irrlicht in the first place?
Why rewrite something instead of improving the one in irrlicht in the first place?
Re: Occlusion culling
consult nvidia on efficient ... i stoped reading there
how ever he is right about occlusion Querry in irrlicht they are not concieved to allow culling based on them but as a simple querry to know how much of your object is visible if you intend to use them as a culling methode alots of modification would be required naturaly if you undertake this kind of task some of us would be ready to help you
how ever he is right about occlusion Querry in irrlicht they are not concieved to allow culling based on them but as a simple querry to know how much of your object is visible if you intend to use them as a culling methode alots of modification would be required naturaly if you undertake this kind of task some of us would be ready to help you
Re: Occlusion culling
last time I checked nvidia had better FLOPS/Watt than AMD or Intelconsult nvidia on efficient ... i stoped reading there
Re: Occlusion culling
they beat AMD in overall gflops per package but thier gpu are some powerhungry monster beast.
and what i mean by i stoped reading there is that if you devlop something based on nvidia's version of efficient it will nrun like a crap everywhere else
and what i mean by i stoped reading there is that if you devlop something based on nvidia's version of efficient it will nrun like a crap everywhere else
Re: Occlusion culling
Actually the latest AMD 7000 Series is far more capable with GP Compute than the Nvidia counterparts. In particular the amd cards are far better suited for working on large datasets due their higher memory bandwidth and they are actually more power efficient.
Have a look at these links: http://www.tomshardware.com/reviews/rad ... 32-14.html
http://www.tomshardware.com/reviews/rad ... 04-14.html
Have a look at these links: http://www.tomshardware.com/reviews/rad ... 32-14.html
http://www.tomshardware.com/reviews/rad ... 04-14.html
Re: Occlusion culling
still rendering is better
Most probs the NVIDIA OpenCL implementation is inferior to CUDA (I agree... nvidia's fault)
Most probs the NVIDIA OpenCL implementation is inferior to CUDA (I agree... nvidia's fault)