Some triangles are not drawn when using a scaled Octree node

You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
Post Reply
izhbq412
Posts: 11
Joined: Fri Sep 28, 2007 9:31 am

Some triangles are not drawn when using a scaled Octree node

Post by izhbq412 »

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.
Image
Any ideas what can cause this?

I'm using ver. 1.3.1.
Last edited by izhbq412 on Tue Nov 20, 2007 3:40 pm, edited 2 times in total.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

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
Posts: 11
Joined: Fri Sep 28, 2007 9:31 am

Post by izhbq412 »

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
Posts: 1638
Joined: Mon Apr 30, 2007 3:24 am
Location: Montreal, CANADA
Contact:

Post by christianclavet »

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
Posts: 162
Joined: Wed Sep 05, 2007 11:02 am
Location: inside

Post by shogun »

It's OCTREE, not OCCTREE.
izhbq412
Posts: 11
Joined: Fri Sep 28, 2007 9:31 am

Post by izhbq412 »

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
Posts: 11
Joined: Fri Sep 28, 2007 9:31 am

Post by izhbq412 »

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
Posts: 11
Joined: Fri Sep 28, 2007 9:31 am

Post by izhbq412 »

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
Admin
Posts: 3590
Joined: Mon Oct 09, 2006 9:36 am
Location: Scotland - gonnae no slag aff mah Engleesh
Contact:

Post by rogerborg »

Should be fixed in SVN 1723. Verification (or reports of other problems!) would be welcome.
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Post Reply