Page 2 of 2

Posted: Sat Jun 05, 2010 11:03 am
by jeromegz
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)

Re: Occlusion culling

Posted: Tue Oct 30, 2012 3:24 am
by Neirdan
Bumping this old thread, does anyone have the occlusion culling source?

Re: Occlusion culling

Posted: Tue Oct 30, 2012 9:00 am
by hybrid
Occlusion culling is part of the engine already, and we have an example for this as well.

Re: Occlusion culling

Posted: Wed Oct 31, 2012 4:54 pm
by Neirdan
Well, not in the 1.7.3 version, but it is in the nightly builds, from what I understood.

Re: Occlusion culling

Posted: Wed Oct 31, 2012 8:12 pm
by devsh
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

Re: Occlusion culling

Posted: Sun Nov 04, 2012 5:36 am
by Neirdan
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?

Re: Occlusion culling

Posted: Sun Nov 04, 2012 6:40 am
by Granyte
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

Re: Occlusion culling

Posted: Wed Nov 07, 2012 7:22 pm
by devsh
consult nvidia on efficient ... i stoped reading there
last time I checked nvidia had better FLOPS/Watt than AMD or Intel

Re: Occlusion culling

Posted: Fri Nov 09, 2012 1:49 pm
by Granyte
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

Re: Occlusion culling

Posted: Fri Nov 09, 2012 2:18 pm
by ACE247
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

Re: Occlusion culling

Posted: Sat Nov 10, 2012 5:44 pm
by devsh
still rendering is better

Most probs the NVIDIA OpenCL implementation is inferior to CUDA (I agree... nvidia's fault)