SVN2248: octtree broken

sio2 · Post by **sio2** » Tue Mar 03, 2009 3:52 pm

The octtree scene node in SVN2248 renders all primitives without regard to the octtree culling.

I was looking at implementing the idea I mentioned in a thread a few months ago regarding making the octtree more efficient wrt hw. I grabbed the latest SVN to see if anyone had already got there before me, built the dll and samples and was pleasantly surprised to see the frame rate of "02 Quake3Map".

"Job already done" thought I, and even more so after looking in the code and seeing the static buffer hint.

Looking deeper, though, I saw a problem. The scene node "does the octtree stuff" and works out what's visible and then just goes and renders all the meshbuffers anyway. Since those buffers are in hw (via the static buffer hint) it renders fast, but the cpu is being wasted in the unused octtree visibility calc. A standard mesh scene node with the static buffer hint is around 10% faster (based on the q3 level used by the sample).

The issue actually dates back to Rev.2147 where OCTTREE_USE_HARDWARE and other octtree modifications was added.

bitplane · Post by **bitplane** » Tue Mar 03, 2009 4:33 pm

I think Tommi is still working on the octtree stuff, he posted a message to the dev mailing list a while back regarding some problems with it. I can't say what he has planned though, I guess you're considering making the vertices static and just updating the index list?

BlindSide · Post by **BlindSide** » Tue Mar 03, 2009 8:04 pm

It may be related to this: http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=32581

I think some broken utility functions for planes/frustum are screwing things up...

sio2 · Post by **sio2** » Wed Mar 04, 2009 11:24 am

BlindSide wrote:It may be related to this: http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=32581

I think some broken utility functions for planes/frustum are screwing things up...

No, that's a separate issue - unless the node has been hacked to always draw everything because of plane/frustum issue.

Anyway, now that I know someone is already working on improving the octtree I'm going to move on to implementing my own quake3 pvs node.

christianclavet · Post by **christianclavet** » Mon Apr 13, 2009 12:13 am

Hi, This could be irrelevant. But I had some problems lately with specific meshes converted as OCCTREES. Collision was not working well. (Using occtrees with the collision response animator)

Could it be related in any way?

sio2 · Post by **sio2** » Sun Oct 04, 2009 6:30 pm

Still broken in the official 1.6 release? I had a look at example 02 Quake3 Map and had a quick look at the 1.6 source and it looks like the octtree scene node just renders all the meshbuffers.

Can anyone else verify?

sio2 · Post by **sio2** » Thu Dec 31, 2009 12:17 pm

I've just had a peek at the latest SVN trunk and the issue still seems to be there. So octrees built from video::EVT_2TCOORDS ("lightmap") meshes - compute octree visbility and then just go and render the whole tree anyway if OCTREE_USE_HARDWARE is defined in octree.h - which it is.

I think it was CuteAlien that mentioned very recently that a 1.7 release is due. Is anyone looking at this - to verify and then fix, if required - so it doesn't slip into yet another release?

sio2 · Post by **sio2** » Thu Dec 31, 2009 12:32 pm

Added a report to the tracker
http://sourceforge.net/tracker/?group_id=74339

hybrid · Post by **hybrid** » Thu Dec 31, 2009 1:35 pm

Yes, the 1.7 release will be published in January. We're fixing some of the known issues before release, but this one is not yet on our TODO list. If you could come up with a patch it's no problem to get it into the release, still.

sio2 · Post by **sio2** » Fri Jan 01, 2010 12:26 pm

I think Burning needs a prod to get this fixed - he was the one who bust it IIRC.

I could be wrong but I was of the impression that the octree was an Irrlicht staple for lightmapped levels and should be a priority fix.

hybrid · Post by **hybrid** » Fri Jan 01, 2010 9:58 pm

Well, our current top TODOs are all things which are not working at all, so having a bad render performance is only second row. But since we have a tracker ticket now, we might get up to this point. This release or another.

JustinBowles · Post by **JustinBowles** » Wed Jan 06, 2010 1:45 pm

sioe2 wrote:I've just had a peek at the latest SVN trunk and there's https://dudehung.com/my-jes-extender-review-and-results the Jes Extender review issue which still seems to be there. So octrees built from video::EVT_2TCOORDS ("lightmap") meshes - compute octree visbility and then just go and render the whole tree anyway if OCTREE_USE_HARDWARE is defined in octree.h - which it is.

I think it was CuteAlien that mentioned very recently that a 1.7 release is due. Is anyone looking at this - to verify and then fix, if required - so it doesn't slip into yet another release?

So when can we expect the January release? Soon I hope!

hybrid · Post by **hybrid** » Wed Jan 06, 2010 2:03 pm

Well, January is not too far away, and it's not too long

burningreggae · Post by **burningreggae** » Sat Jan 16, 2010 11:57 am

Please just don't define
OCTREE_USE_HARDWARE
that's all...
it should be set to undefined ( or off ) at default.
and i'm quite sure it was set to off some time ago..

This only makes sense if the entire mesh is cached by hardware, therefore it was just a define for NOT disturbing the standard programming path.

BUT i couldn't work for irrlicht last year and the code changed so much, that i can't merge my existing code ( from may 2009 )

So, i just change the define to OFF and commit it.

Is this ok for everbody?
Greetings!
Burning

CuteAlien · Post by **CuteAlien** » Sat Jan 16, 2010 12:44 pm

I also didn't find time yet to work on this, so I only did some simple tests (with all define-settings) where I did compare the number of rendered polygons for a level of mine after loading with the number of polygons I had in an older Irrlicht version. And regardless of settings the new Irrlicht did clip less polygons. But well, I haven't written a good test-case and I also didn't see anything obvious, so can't tell more besides that so far :-(

Another thing is that we branched 1.7 already, so if that define (which is a flag by now) should be changed for that version you should rather put it in there.

And I guess we all have the same problem when merging local modifications back to Irrlicht. Not sure how you do the merging right now. My method so far is that I'm using mercurial for local Irrlicht versions and whenever I change anything in it I create a patch for that change (easy to do with mercurial). So once I merge back I have usually a bunch of short patch-files which I can try to merge one-by-one. Not all patches will still work, but most do and it's usually also easier merging the others. Also when I update Irrlicht for my local project I just remove it completely, get a new Irrlicht and then add all the patches back in (once again making a new patch for the new version after applying each one). Still takes a day or two, but I found no better way so far.