performance issue - many nodes

[muckelzwerg]

Hi

I got a problem with the FPS on my irrlicht program.
The combination
"scene_manager->draw_all()"
with many "IAnimatedMeshSceneNodes" seems to kill my framerate.

- Is there a way arround "draw_all()" ?
Should I build a mesh selector to choose which meshes to update
via scenemanger ?

- Culling etc. ? My FPS decrease does not stop when the animated nodes
ar outside the camreas view.
Even setting camera far_value to 1.0 does not change anything.
So I guess culling is working but the decrease in FPS is not a grafical
issue, right ?

- How do I use a "animationless" mesh ?
If I replace the animated Nodes with TestSceneNodes,
the FPS are fine, so I think the Problem is the processing of the Animations.
Theres "addMeshSceneNode" in scene_manager, but I know only of
"scene_manager->get_mesh()" which returns a animated mesh.
Casting to a static mesh didn't work so far.

- some other error I made, in handling animated meshes ?
Using animated md2 files for Bulltes is not the way you would
normaly do it.
But even when I insert just about 10 animated nodes with no frameloop
and simple sphere as body FPS drops from 130 to 120-110.
Adding more nodes incereases the framelloss per node from 1 up to 3 frames.
Using sydney I lose about 5 FPS each time I add a animated sydney node to the scene.
Are the reasonable values, or do I have some errors in handling the nodes ?

thx

-- -- muckelzwerg

[omaremad]

hmm this is difficult

the way i would do it
is turn any thing that doesnt need animation into
octtreescenenode since that will cull them if they arent on screen

for the animated meshes

i would draw a 3d line

from the node 2 the camera

Code: Select all

 core::vector3df start = targetNodeint->getAbsolutePosition();
core::vector3df end = camera->getAbsolutePosition();
		
core::line3d<f32> line(start, end);	 
float dist=line.getLength();

then see if there are obstacles hiding the scenenode if so make it invisible
since u cant see it any way

Code: Select all

 if (smgr->getSceneCollisionManager()->getCollisionPoint(
		line, q3node->getTriangleSelector ( ), end, triangle))
		
		{ targetNodeint->setVisible(false);};

[muckelzwerg]

Linepicking wont help me, since it will hide large objects if
only a part of them is blocked.
But atm I am pretty confused aboute the culling already done by irrlicht.
I could not find a reference which nodes get culled under which circumstances.
Can anybody tell me where I get information on that.

As far as I know
OctTreeSceneNodes get culled if they're are outside the FOV.
What about frustum culling ? Is it somewhere in irrlicht and I just
have to turn it on, or do I have to implement it myself ?
Wouldnt be that hard to do, but since there is a near and far value
for the camera I thought it is already there.

So basically I am in search for information on irrlichts culling.
Whats in there an what is not ?

thanks again

-- -- muckelzwerg

[Electron]

Irrlicht has basic frustum culling, but its really lousy. It only uses the aabb of the frustum. And it has no occlusion culling. Its a significant amount of work to set up and use (because of needing to place the portals) but if you need something for better cuylling, you could check out my portal system http://www.irrlichtnx.mmdevel.de/phpBB2 ... .php?t=142

[muckelzwerg]

Thanks, thats helpfull.
I think, my main problem is, that I do not completely understand
what irrlicht does about culling etc.

The OctTreeSceneNode is the only node, that gets culled
by the cameras aabbox ?
So I will have to handle every other node myself, using
"intersectsWithBox()", if i wanted to have them culled
similliar ?

What happens when a node is turned invisible ?
First it will not be displayed, but it also is not used for irrlichts colission
detection.
What else does setting a node to invisible do ?
Is there any more difference between using your own list, without those nodes
you want to cull, via "drawNodeList()", or just setting them invisible and
use "draw_all()" ?


-- -- muckelzwerg

[Electron]

Thanks, thats helpfull.
I think, my main problem is, that I do not completely understand
what irrlicht does about culling etc.

The OctTreeSceneNode is the only node, that gets culled
by the cameras aabbox ?
So I will have to handle every other node myself, using
"intersectsWithBox()", if i wanted to have them culled
similliar ?

no. Look i n the source. The aabb of every node is checked against the aabb of the frustum. This is very poor culling, but its better than absolutely nothing. The octree scene node is the only node that can have part of itself culled while the rest is stil rendered. This (if i remember correctly) actaully uses a more accurate frustum cull, checking aabb's of octree sections agains the actual frustum planes

[muckelzwerg]

Ok, not that I do not believe you, but then I got problems understanding
something :
I just did a simple test with the Hello World demo.
I added about 10 animated scenenodes of sydney, that drops the
fps drastically.
Adding 10 OctTreeNodes results in the same fps decrease.
But then I turn around so I cant see the nodes (or move sideways
far enough) and in case of the OctTreeNodes the fps get back to their starting value.
However when I use the animated mesh scenenodes the fps stay down.
What does that tell me ?

-- -- muckelzwerg

[Electron]

hmm. that's interesting. How close behind you were the nodes? Because the aabb culling is very inexact. The octree does more exact culling on parts of itself. So yes, the octree does better culling. But some basic culling is being done on other ndoes, or it should be.
this is the culling function used on all nodes

Code: Select all

//! returns if node is culled
bool CSceneManager::isCulled(ISceneNode* node)
{
	if (!node->getAutomaticCulling())
		return false;

	ICameraSceneNode* cam = getActiveCamera();
	if (!cam)
		return false;

    core::aabbox3d<f32> tbox = node->getBoundingBox();
	node->getAbsoluteTransformation().transformBox(tbox);
	return !(tbox.intersectsWithBox(cam->getViewFrustrum()->boundingBox));

	// This is a slower but more exact version:
	// SViewFrustrum f = *cam->getViewFrustrum();
	// core::matrix4 invTrans;
	// AbsoluteTransformation.getInverse(invTrans);
	// f.transform(invTrans);
	// culled = !(f.boundingBox.intersectsWithBox(Mesh->getBoundingBox()));
}

it is called from here

Code: Select all

void CSceneManager::registerNodeForRendering(ISceneNode* node, E_SCENE_NODE_RENDER_PASS time)
{
	if (isCulled(node))
		return;
       //rest of function

[muckelzwerg]

I was far enough away from the nodes.
In fact I can keep moving away s long as i like.
I decreased the FarValue of the camera and it pretty goodssems to cull the OctTreeNodes when I cant see them anymore.
But the AnimatedmeshSceneNodes allways use up my FPS.

Its not the problem to implement culling algorithms optimized
for your own apllication, but as long as I do not really know
what happens in irrlicht behind my back its not easy to manage.


-- -- muckelzwerg

[Electron]

Well I must admit ur results surprise me, but culling in Irrlicht (IMHO) sucks anyway, so its not a bad idea to implement ur own.

Code: Select all

but as long as I do not really know
what happens in irrlicht behind my back its not easy to manage

Well depends on how much effort you want to put in, but that's one reason Irrlicht's open source. You can look in and see waht's going on

[muckelzwerg]

Aye, I second that.

My problem at the moment is, the question "what performance is irrlicht capable of ?".
If I cant display 10 animated Meshes simultaneosly (so no need to think about
culling at this point) without killing my fps, I simply cant use irrlicht.


-- -- muckelzwerg

[Electron]

I feel your pain
IMHO, irrlicht has very, very poor performance in dense or large scenes. Lightfeather, still in development, includes several culling techniques (portal, pvs, and hardware occlusion query), but it is not finished yet.