Culling Default = ...

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
agamemnus
Posts: 283
Joined: Sun Jan 31, 2010 6:06 pm

Culling Default = ...

Post by agamemnus »

As discussed in this thread, the default culling is EAC_BOX.

1)
Wouldn't it make more sense to use EAC_FRUSTUM_BOX?


2)
For me, I need EAC_FRUSTUM_BOX at all times. I would hate to have to either recompile Irrlicht to set the default to EAC_FRUSTUM_BOX every time that I updated my Irrlicht version, but alternatively I don't want to have to set the culling method for each node manually.

So, regardless of whether EAC_FRUSTUM_BOX is set as the default, how about giving us a default culling method that new nodes will be set to; perhaps make it a variable on the scene manager?
Last edited by agamemnus on Tue Mar 01, 2011 7:51 am, edited 1 time in total.
Radikalizm
Posts: 1215
Joined: Tue Jan 09, 2007 7:03 pm
Location: Leuven, Belgium

Post by Radikalizm »

The calculation used to do a culling check against the actual frustum is more expensive than using its bounding box, so in simple scenes it would create an overhead instead of an improvement (remember that irrlicht is meant to run smoothly on older and less powerful hardware too)

Do you really have that many nodes that you can't set their culling mode? If so, why don't you use .irr files? (they store per-node culling data I believe)
agamemnus
Posts: 283
Joined: Sun Jan 31, 2010 6:06 pm

Post by agamemnus »

Radikalizm wrote:The calculation used to do a culling check against the actual frustum is more expensive than using its bounding box, so in simple scenes it would create an overhead instead of an improvement (remember that irrlicht is meant to run smoothly on older and less powerful hardware too)
I see... but are there really that many (or any) cases where the bounding box check makes any sense? Also: how much more expensive is a frustum check comparably? I don't think it's really that expensive, especially compared to allowing more nodes to be rendered. My hardware is 7 years old and the only difference I noticed is that my fps went from a low of 20 to a low of 55.

Do you really have that many nodes that you can't set their culling mode?
It's not a matter of being able or unable to set the culling mode, but a question of work. I don't want to add code to modify the culling mode every time I add a new node.

If so, why don't you use .irr files? (they store per-node culling data I believe)
I don't really understand this... Irr files are some sort of saved representation of scenes, right? First of all, my scenes aren't static and secondly, it is not a question of the actual program time it takes to set this stuff or being able to save it or whatever... it is about the code. What's the point of resetting the culling node to X when I know I want the culling node to be X every time? What if I miss a spot? It's just tiring to add extra code when I could... not be adding it. :)
Gorbstein
Posts: 37
Joined: Wed Nov 25, 2009 8:44 pm
Location: Scotland

Post by Gorbstein »

I had this problem too. I felt a smgr->setDefaultCullingMode(..) would be useful, so it could be set after irrlicht initialisation and forgotten about.

I had a few areas where I wished I had things like this. In the end I found it easier to hide all irrlicht stuff inside a wrapper (ie: GraphicsEngine) with generic functions like createNode which initialise various default values every time you create a new node or set various texture settings every time you load a new texture, etc.

I never want my game side code to know about driver, device or smgr workings anyway and would rather have it speaking to something more generic than irrlicht.

D
Post Reply