Irrlicht Engine

Anyone know if there is an improved version of COctreeSceneNode compatible with 1.7.3?

I´ve activated hardware buufers and there is a problem with clean-up on LighMapMeshes.

Thought I saw someone had posted an improved version of their website but can't remember where that was.

Thanks.

You might check Project Chrono. http://projectchrono.org/
I believe they use Irrlicht 1.7.3, but have since branched it.

Thanks for the link, interesting project.

They are using 1.8.2. though...

Someone had a new Octree class that handled the triangle hit list in a much more efficient manner, thought it was on one of the irrlicht admin's website, but can't remember which...

Found the link here: http://www.michaelzeilfelder.de/irrlicht.htm#Models

What's useful is that it also creates the triangle selector list.

Ah you meant mine, I forgot about that :-) I removed it in my game because I found out using a combination of a static mesh (with meshbuffers kept on graphic-card) + a 2d-grid solution for collision-polygon lookup was slightly faster for my case (but this stuff is very dependent on the scene, there's no general rule what will be faster).
Problem with octree in my case was that I had many situations in which the whole map was visible. So while it would optimize rendering and collision in some situations, for the worst-case octrees had to be worse because of that. And the worst case is what I care about most in my game (better to have a smoother frame-rate than one with high fps on average but irregular slow-downs in between).
For collisions octree and grid had been nearly similar - maybe a quadtree would have been even better, but I haven't coded one of those yet for Irrlicht.

Yes. I guess there is no easy solution.

Have you seen this idea, its really neat, a "cloth" mesh falling into a vase where the code detects the vase edge and deforms the cloth in real-time, running on the GPU.

http://gamma.cs.unc.edu/CSTREAMS/

Looks nice (and complicated...) :-)

yes, these things are ..painfully complicated!

take a look at their 30MB video, there is a model of a woman in a spanish-style dress, as the woman moves, the dress flys around her, it looks absolutely real, gravity and momentum of the material looks perfect.

One life is too short for doing that sort of maths!

The cool stuff in http://www.michaelzeilfelder.de/irrlicht.htm#Models..
Shouldn't these things then find their way into standard releases of Irrlicht?
I mean if a thing works, why not include it in the following releases?

@Vectrotek: I suppose you don't mean my ugly models but the patches below them ;-)
And yeah - most of those patches have been put into Irrlicht over the years. For those which I didn't put in there was usually some reason (a lot are solutions which had been workarounds good enough for a game, but not good enough for the engine where I have to think about stuff like long-term maintenance).
I do keep a list of the patches which I didn't manage to add yet, but I have too many more interesting todo's on my list (for example last weeks I worked again on ttf's where the code I use still has a lot of open problems before I consider it engine ready).

I get you..

@ Robmar: What's wrong with the Octree node in Irrlicht 1.8.3 and why are you concerned with Irrlicht 1.7.3 ?
That's actually why I asked if cool things make it to later standard releases.
Would, guessing that you have customized your Irrlicht so heavily through trunk, pileline and svn that it would be a major effort to get back to something
standard like Irrlicht 1.8.3 be totally wrong?
Or.. Is it because that specific that specific "fixed" Octree node could be used for something like the "collision" on that cloth?
(just asking because I've reached a point where these things start to matter) Robmar? Cute Alien?

Exactly, it would take me weeks to update 1.8.3 with my additions/changes, and that's if I didn't have any complications with the newer release.

The COctree node in 1.8.3 has additional external functions and variables that don't exist in 1.7.3, and the 1.7.3 version in it is buggy when enabling hardware buffers, memory loss etc.

Memory usage and speed in creating triangle lists was another thing I was interested in improving as you note, which I understood CuteAlien had improved in his verison.

Thinking about removing the time overhead to load octree sorted triangle lists, as larger meshes tend to have many meshes, couldn't we just scan the mesh buffers for a hit, checking the boundary box for each submesh?

I'm finding that with large models, if I load the triangle selector, it uses twice the amount of memory as taken by the mesh itself!
I'm wondering why, as the overhead to sort the triangles into 8 groups shouldn't be more than a few %