Some triangles are not drawn when using a scaled Octree node

izhbq412 · Post by **izhbq412** » Mon Nov 19, 2007 10:19 am

I have a static mesh from which I'm creating an OctTree scene node. However some (or all) of the triangles disappear when the camera is looking at the mesh from certain angles. Debugging through the code I found out that irrlicht thinks that some of the bounding boxes inside the tree (or even the whole tree) are outside the view frustum (usually below the bottom of the frustum or occasionally to the left of the frustum). Here's a picture of the mesh with the triangles missing - you can clearly see the bounding boxes but the meshes themselves are not draw. When drawing the mesh as a MeshSceneNode it works fine. OctTrees from the examples show correctly as well.

Any ideas what can cause this?

I'm using ver. 1.3.1.

hybrid · Post by **hybrid** » Mon Nov 19, 2007 10:50 am

There had been some bugs in plane relation calculations. These might cause problems with viewfrustum comparisons. You might want to drop in Irrlicht 1.4b as a replacement to see if this fixes your problems.

izhbq412 · Post by **izhbq412** » Mon Nov 19, 2007 10:56 am

Further examination revealed that the problem is caused by the fact that a transformation is being applied to the scene node, namely that it's being scaled. The octtree however uses the unscaled bounding box of the mesh and decides that it's outside the frustum. I believe this is a bug in the engine?

I'd appreciate ideas how to work around this problem. For now passing the scaling as a parameter to the SViewFrustrum overload of calculatePolys and getPolys of the OctTree class comes to mind. This requires scaling the bounding boxes every time these methods are called.

BTW I believe "For beginners" is no longer an appropriate place for this thread...

christianclavet · Post by **christianclavet** » Mon Nov 19, 2007 1:05 pm

Hi,

It's not a good idea to scale a mesh inside IRRlicht. You'd better scale it in your modeler. I never had problem with OCCTREE, If i've not done any manipulation on it before converting it.

I've always have problem with OCCTREE's if I used a vertex lightmap over the mesh. So there could be a transform problem over OCCTREE. Have you done vertex Lightmap over it?

An idea, to test if the transform affect the OCCTREE, is to not scale or do transformation on your mesh, convert it to an occtree and scale it after it has been converted to OCCTREE.

If the mesh is not scaled, then you could post a subject in the BUG thread and send in your mesh that we see what could be the problem.

shogun · Post by **shogun** » Mon Nov 19, 2007 1:37 pm

It's OCTREE, not OCCTREE.

izhbq412 · Post by **izhbq412** » Mon Nov 19, 2007 2:04 pm

The scaling has to be dynamic and there is no modeler - this is actual field data that has been triangulated. I'm not scaling the model itself, just applying a transformation. If no transformation is applied the octree performs as expected.

@hybrid: If you are referring to the classifyPointRelation bug - it's already been fixed in 1.3.1. I can't easily test with 1.4b because I'm not using one of the supported compilers so some compiler issues have to be resolved, other than any API-breaking changes that have also been introduced.

PS: It turns out I was wrong about the transformed-vs-untransformed bounding box calculations (the absolute transformation of the scene node is taken into account). However scaling the model still triggers the issue somehow.

izhbq412 · Post by **izhbq412** » Tue Nov 20, 2007 1:35 pm

Upgrading to 1.4b didn't fix the problem.

HERE'S HOW TO REPLICATE THE BUG:
1. Open up example 02. Quake3Map and change

Code: Select all

if (node)
		node->setPosition(core::vector3df(-1300,-144,-1249));

to

Code: Select all

	if (node)
	{
		node->setPosition(core::vector3df(-1300,-144,-1249));
		node->setScale( core::vector3df( 1, 5, 1 ) );
	}

2. Build and walk around the level.

izhbq412 · Post by **izhbq412** » Thu Nov 22, 2007 10:45 am

I did a little experimenting and found out a few things:

- if the bounding box of the view frustum is used instead of the frustum, the problem appears in somewhat less situations.
- if when transforming the frustum to the absolute transformation of the node the transformed planes are normalized and the bounding box of the frustum is used, is is a lot more difficult to reproduce the problem - it only seems to appear when looking nearly straight up or nearly straight down (for scaling factors like (1,5,1) or (1,10,1)).
- simply doubling the bounding box of the frustum (MinEgde/2, MaxEdge*2) reduces the problem but doesn't eliminate it (so it doesn't look like a problem with a border-line case).

rogerborg · Post by **rogerborg** » Wed Nov 12, 2008 12:32 pm

Should be fixed in SVN 1723. Verification (or reports of other problems!) would be welcome.