OgreTok - Comments / Questions / Suggestions / Help / etc.

[staringmonkey]

Tokamak Stuff

Just committed collision tables, collision callbacks, breakage callbacks, and some bug fixes. Damn has it been a productive day. I've done so much I'm not even sure what to work on next.

The Continuing Conversation of DaZMaN and staringmonkey

That sounds like a great name for a comedy duo

Hell yeah it does.

I think your exactly right about the Tokamak issues. However, and I won't question that fact that I don't have the whole picture, it seems to me that the thing holding Tokamak back had nothing to do with it's featureset. Granted it's not Havok, but for smaller developers I think it would have been very popular had it been more user-friendly. They didn't need to rewrite the source code, they just needed to clean up their documentation, provide some technical support, and provide examples that compile. Nobody is going to be taking down Havok as the primary physics middleware in the forseeable future, it's featureset is just too robust. But there is room for compotetion, provided it looks good enough to attract interest. I was extremely speculative about what Tokamak was capable of when I first used it, due to it's bizzare code design and interface, but via OgreTok I've proven (at least to myself) that it's a force to be reckoned with when properly used.

I'm not sure "fun" is the word I'd use to describe my BSP aspirations, but I'll take your word for it until I prove it different.

but I've never tweaked.

Good for you, stay clean! Oh wait, did I misquote that.

Pool "with a twist", sounds cool. Hey, if you've got an artist working, then your halfway there. I've been making games for... oh dear... something like five years now, and I've finished !1! (and finished is a relative term in that case), because only once have I ever found an artist who would actually complete a project. My programming efforts now are entirely for self-enlightenment purposes. I'd love to finish something for a change, but I'm pretty well consigned to an art-less doom. What worse (at the risk of starting a twenty page rant) I'm not even really a programmer. I'm a designer who codes. I only learned how to program because I could never find a programmer to complete a project. (Although now that I can code I find it an absolutely invaluable mental exercise.) Now that I'm a passable programmer (though by no means expert) I can never find an artist. It's a mobius strip of game development problems, I swear.

That screenshot is hilarious. I can't wait to see some more, when it gets a bit further. If you need any help with anything, just ask.

Speak Soon,
staringmonkey

[KayNine]

staringmonkey, the "auto-ragdoll" was what I was going to use your OgreTok for. I've been playing around with the rag-doll demo's on Tokamak for a while now, getting them to stand, etc. I figured it would be cool to be about to build a rag-doll joint system from an Ogre skeleton definition. I agree with you - the joint limit, etc would be the tricky bit (and they are not part of the skeleton def). Unfortunately I'm trying to get this Poser Exporter happening first (and it's slow progress), so you will probably get around to auto-ragdoll first!

[staringmonkey]

Hehe, well it's nice to hear someone else has had the same idea. Although, I'll be honest, at this point both auto-ragdolls and bsp/octree collision have been put (at least for the moment) on my "unplanned" feature list.

The reasons are fairly simple. Automatically generating ragdolls would be great for prototyping, but since joint limits, mass, and such are not an inherent part of the Ogre skeletal defenitions, for any practical use those parameters are going to have to be generated during the content creation process (ie modelling). If the implementation is going to require specific content creation (and most likely a custom file format), then I would rather leave it to the individual developers to create those as they need them. I could, naturally, include a loosely structured RagDoll class, but their really doesn't seem to be any need, as it's a fairly simple structure to develop as needed (basically just a map of DynamicObjects and a map of Joints). Another reason not to do this is that class would really be peripheral to the rest of OgreTok and I'd rather keep it a centralized abstraction of Tokamak, rather than have a bunch of extraneous features cluttering things up. Especially since it's already a bit cluttered from my forcing OOP onto Tokamak's somewhat loose programming style.

As for BSP/Octree collision, my reasons for not including this as a feature are several. Firstly, using Tokamak's TriMesh callback is yielding some extremely strange errors. Secondly, Ogre's BSP and Octree support is provided through plugins, rather than as a part of the core engine, and I'd rather not add any features that require the usage of a plugin. Once again, these are really implementation/usage specific features. And thirdly/lastly, specifically supporting BSP and Octree collision to a certain extents precludes the usage of other terrain collision systems, which I don't want to do. Another consideration for why I won't do this is because I was mistaken about how the TriMesh callback worked. It doesn't cull the existing mesh, but rather requires the user to create a mesh each frame, for each object, containing only those triangles which may potentially collide. This, I suppose, is a good way to support a variety of collision options, but would make it difficult for me to support Ogre's BSP implementation.

I hope those things don't dissapoint anybody. I just commited the last of the base features to the CVS. So for the core of it, OgreTok is stable and usable. There are still features that I haven't added yet (sensors, motors, etc.), but I'm still weighing the usefulness of these features. I certainly won't be using them in my projects. If anyone specifically needs a feature that I haven't added yet, let me know which and why and I'll see about putting it in, but for the moment, I'll just be adding things as I decide they are needed.

Ok, I'm done, I had my rant ,
staringmonkey

[DaZMaN]

If people want Trimesh support, they should enjoy at least *some* of the stuff we have. It's only fair I, for one, am not disappointed mate

I have come to the conclusion that Trimesh is the Spawn of Satan(tm), and you should avoid spending too many hours with it in a given time. Amusingly, the ODE mailing list is currently on fire with questions about Trimesh collision. I think Ogre has started an epidemic

Some of them are quite funny too, such as "Hi, I'm trying to get some boxez colliding with Trimesh, and can't figure it out. Can you help plz?". Sure, I charge £250GBP a day, writing, debugging and testing your Trimesh code for you will take 5 days I accept PayPal payments Ah, in a perfect world...

With the artist thing - yes, I have a *3D* artist, and alhtough he's great with the modeller and it's texture features, he doesn't actually draw textures So, I do actually lack a 2D/Texture artist. I have a friend who can draw really well, but he's a bit unreliable and needs some tutoring from me in terms of texture rules, tips etc. and general graphics stuff. I'm working on him, but it's taking time! "Grrrrr..."

Thanks for the offer of help sm - and I may well take you up on that I'm real busy with business stuff at the mo, and when I do games I get distracted for far too long... It's very easy to be doing games code when I should be earning money! I seem quite a bit more code being required for the pool project, so if you'd really like to help, maybe I could send you my design doc etc.? I need to clean it up and update it a bit though first...

Oh, my mate sent over his latest pool table Check it out below. There's still work to do on it, most of it in the texture department. We're both quite happy with the cushion curves, and as you can see it's a pub / 'coin slot' pool table - the collision area inside the table will be correct, so when the balls are pocketed, they'll find their way to the sloped ball return mechanism on the side of the table Apologies for the cheesy background, he just grabbed a digi-photo and then matched the camera perspective in 3D, before rendering.

[staringmonkey]

If people want Trimesh support, they should enjoy at least *some* of the stuff we have. It's only fair I, for one, am not disappointed mate

Good to hear, I also just added a pass-through for the TriMesh collision callback. Now that I know how it works and have thus eliminated internal BSP/Octree testing, I decided a passthrough was the best option. I was originally against it, because it exposes some of the Tokamak types to the user, but I guess, it's better than nothing. For a smaller project, like yours for example, it would be perfectly feasible to use a low/mid-poly version of the table for collision, you wouldn't need the callbacks anyway (in fact, it takes a grand total of one function call ). I may actually do an Octree implementation as an example, rather than an integrated part of OgreTok, just to show that it can be done.

I have come to the conclusion that Trimesh is the Spawn of Satan(tm), and you should avoid spending too many hours with it in a given time. Amusingly, the ODE mailing list is currently on fire with questions about Trimesh collision. I think Ogre has started an epidemic

Hehe, somehow that doesn't surprise me in the slightest.

With the artist thing - yes, I have a *3D* artist, and alhtough he's great with the modeller and it's texture features, he doesn't actually draw textures So, I do actually lack a 2D/Texture artist. I have a friend who can draw really well, but he's a bit unreliable and needs some tutoring from me in terms of texture rules, tips etc. and general graphics stuff. I'm working on him, but it's taking time! "Grrrrr..."

I hear you, I have several friends who are all excellent artists, too bad it so naturally follows that they are all bums as well.

Thanks for the offer of help sm - and I may well take you up on that I'm real busy with business stuff at the mo, and when I do games I get distracted for far too long... It's very easy to be doing games code when I should be earning money! I seem quite a bit more code being required for the pool project, so if you'd really like to help, maybe I could send you my design doc etc.? I need to clean it up and update it a bit though first...

Well, I've got my own project going at the moment, as far as the actual coding goes (I just finished up most of OgreTok, I HAVE to see it in action ), but I'm certainly very open to perhaps some sort of idea-share / peer-review. Such as what we have now, in fact. Actually, I'm rather enjoying this thread. I consistently look forward to seeing what you've written each day. It would be nice to work together on a unified project, too bad we chose opposite physics systems. You've reminded that I really need to get to work on my design document. This is the first time I've worked so hard on a project I hadn't more thoroughly fleshed out. It's still pretty much a concept at this point.

Oh, my mate sent over his latest pool table Check it out below. There's still work to do on it, most of it in the texture department. We're both quite happy with the cushion curves, and as you can see it's a pub / 'coin slot' pool table - the collision area inside the table will be correct, so when the balls are pocketed, they'll find their way to the sloped ball return mechanism on the side of the table Apologies for the cheesy background, he just grabbed a digi-photo and then matched the camera perspective in 3D, before rendering.

Hey! That's looking very nice! Your right, it still needs some texture work, but the model itself is very well done. I love the idea of having correct physics for the inside of the tables. Would be interesting to have a cut-away view on occasion to actually show that working, for a nice visual touch. I'm curious how your approaching the physics of the table itself? That looks like quite a high-poly model (speaking which, do you know how many it is?). Are you going to create a simplified mesh for collision? I would think for instance, you could eliminate the external shell of the table without anyone noticing.

Ironically, I look at your picture and think how cool it would be to use OgreTok with that model (especially since I likely wouldn't need to worry about tri-culling), such is life. If you get a chance you should check out the OgreTok TriMesh demo (#9) once it makes it to the public CVS. I think you'll find it quite impressive. (Does it sound like I'm trying to sell you... I sure hope not. )

staringmonkey

[Slicky]

I'm getting frustrated with ODE and the "bendy wheels" problem that a lot of people have had. It could still be me but I've tweaked the hell out of it.

This is almost driving me to try Tokamak I wonder if anyone here has messed with Tokamak and vehicles to see if the same problem exists.

[staringmonkey]

Well, to be honest I've never even tried to create a vehicle. It wasn't one of things I had in mind while making OgreTok, although it's undoubtedly one of the most common usages. I'm not entirely sure I understand the mechanics of it. The Tokamak car demo uses sensors which struck me as odd, because it seems reasonble that it could be done with only joints and bodies. If somebody is willing to describe for me precisely how they are constructing their car, I will be more than willing to attempt to replicate it and see how it works out.

staringmonkey

[Slicky]

I think I'm going to give it a shot. The sensor approach may even be better since I think wheels have problems because of high spin speed but I'm not sure. I was just reading the Tokamak boards and noticed that they use sensors instead of rigid bodies for that so I am encouraged to try (downloaded the dll and headers).

I tried to access cvs but got errors. Maybe me or cvs busy.

I'd like to try the wrappers maybe to see if they make it easier to use with OGRE. Do you have any functions in there for mesh objects as static geom?

[staringmonkey]

I think I'm going to give it a shot. The sensor approach may even be better since I think wheels have problems because of high spin speed but I'm not sure. I was just reading the Tokamak boards and noticed that they use sensors instead of rigid bodies for that so I am encouraged to try (downloaded the dll and headers).

I'll probably go ahead and add Sensor support to OgreTok as my next effort. It shouldn't take me but a day or two.

I tried to access cvs but got errors. Maybe me or cvs busy.

Yeah, it's down for maitenance.

I'd like to try the wrappers maybe to see if they make it easier to use with OGRE. Do you have any functions in there for mesh objects as static geom?

Yes and no. Yes it's easier to use, but Tokamak is set up to support only a single TriMesh object. I've considered writing a shared buffer routine to support more, but I'm not sure how well that will work (it would involve writing my own memory managment, and I dread that). So if you have a level and you want to load that as a static TriMesh, yes you can, but you can't have several discrete TriMeshes loaded at once. Tokamak is setup to rely more on complex objects made up of multiple connected primitives, rather than TriMeshes. The OgreTok demos should give you a better idea of what I'm talking about if you want to see.

Oh and just so people don't get mislead, OgreTok is really a bit more than a wrapper. It has quite a bit of it's own functionality at this point.

staringmonkey

[Slicky]

Hmm single trimesh may pose some challenges. Not sure I can work around that. What do people do who want level geometry with both ground and structures? I guess primitive substitution maybe but that can get messy.

[monster]

Can't you just merge all your "world" TriMeshes into one big one, containing all the ground and all the structures?

[staringmonkey]

It's either merge them all together (the easy way) or write up a little system which merges them in on program start. I could add the latter as an OgreTok feature, but it seems redundant. Detailed TriMesh collision detection in Tokamak needs to be done through callbacks anyway (since it does absolutely 0 internal culling, see previous posts for more), so there really isn't anyway out of performing some form of on-the-fly merger, if you wanna use Tokamak. And I agree, it's a fairly substantial drawback, but not one that is impossible to overcome.

staringmonkey

[Slicky]

Yep merging must be possible. For a few minutes i thought not a good idea but we are talking about collision not rendering so it might be workable.

[cTh]

I think that a Octree would be a perfect solution for the 'one triMesh' problem, ie. sending to Tokamak only the visible octant every frame (if it's not the same).
This, of course, will require a special octree scene manager that should be thightly coupled with OgreTok for example, and that's what I plan to do, but not so fast....
Namelly, I'm now working on a dotSceneEditor, ie. an GUI application wich load .scene files exported from MAX, it will allow some basic tweaking of geometry (ie rotation, movement, insert of meshes/billboards/cameras/lights...), but that's not the main goal, the main thing will be a custom Octree compiler, ogreFSRad based lightmap generator, and a simple physics testbed using OgreTok I hope , so sooner or later I will get to octree and ogreTok coupling...for now the project is in a stage of loading/displaying/moving cameras through a .scene file, at a 'viewer' stage...more to come

BTW, there has been word of a 'custom' format requirement for generating ragdoll systems on the fly
The dotScene (.scene) format is very open and maintained by the community, physics parameters should fit very well for meshes in it, and I can even export them (phys params) from MAX, if someone have some idea, please speak !!!
This format is a defacto good oportunity to make something a 'format' instead all of us using/making their own 'custom formats'

As last, I tryied again the new CVS version and all work well, like the breaking geometry demo very much, but I still can't figure out (bear in mind, did not have a look at the sources) why the big lags occur ???
I know my machine is a piece of shit, but ODE and Tokamak demos work really well, and I have tryied so many physics demos on it, all works perfect, even cloth simulation , so I really do not see how a OgreTok demo should perform so bad ???

[staringmonkey]

Ok, before I start the replies I would like to take this moment to say "EUREKA!" The bathwater has risen and Diogenes is out of his jar. I had a attack of ideas late last night for how to implement multiple-TriMesh support with on-the-fly merging AND actually use it for a speed increase, rather than a speed decrease! My head is swimming with ideas, but unfortunantly I have classes most of the day, so it will be evening when I get to work on it. I'm still working it all out, but it should provide multi-TriMesh support, with fast culling for any type of scene (BSP/Octree/QuadTree/etc.). I've got some issues to work out with regards to memory management, but on the whole the idea is very promising. I'll let everyone know how it progresses.

Namelly, I'm now working on a dotSceneEditor, ie. an GUI application wich load .scene files exported from MAX, it will allow some basic tweaking of geometry (ie rotation, movement, insert of meshes/billboards/cameras/lights...), but that's not the main goal, the main thing will be a custom Octree compiler, ogreFSRad based lightmap generator, and a simple physics testbed using OgreTok I hope , so sooner or later I will get to octree and ogreTok coupling...for now the project is in a stage of loading/displaying/moving cameras through a .scene file, at a 'viewer' stage...more to come

Well, if this new method of collision detection that I'm planning works, you won't even need to write a custom Octree implementation. The only big negative at the moment is it's going to have a rather large memory footprint. I'm still trying to come up wtih ways to reduce this.

BTW, there has been word of a 'custom' format requirement for generating ragdoll systems on the fly
The dotScene (.scene) format is very open and maintained by the community, physics parameters should fit very well for meshes in it, and I can even export them (phys params) from MAX, if someone have some idea, please speak !!!
This format is a defacto good oportunity to make something a 'format' instead all of us using/making their own 'custom formats'

Hmmm... when I looked at the thread regarding the DotScene format it seemed that for the most part people were trying to avoid anything that wasn't totally generic. And I largely agree with that approach, physics won't be in all games, so perhaps they shouldn't be in the format. But, that said, it would be an excellent place to stick them, so perhaps the approach to take is to extend the format and have DotOgreTokScene or something along those lines. We'll have to see about that.

As last, I tryied again the new CVS version and all work well, like the breaking geometry demo very much, but I still can't figure out (bear in mind, did not have a look at the sources) why the big lags occur ???
I know my machine is a piece of shit, but ODE and Tokamak demos work really well, and I have tryied so many physics demos on it, all works perfect, even cloth simulation , so I really do not see how a OgreTok demo should perform so bad ???

Hmmm... well, I'm not entirely sure why this is happening. I do get slowdown on my machine, but not on the order you seem to be experiancing. There are two process intensive components to OgreTok. The first is Tokamak, in which process usage starts out high, and increases with the number of objects, but should use significantly less after the first few seconds when all the objects go idle. The second is the Ogre side of it. OgreTok uses a fair number of scenenodes (up to 3 per object if debugging bodies are enabled, which they are in the demo), but I've seen other Ogre apps that use more than my demos, so I can't imagine that's it. Hmm... I'll think about it and see what I come up with.

staringmonkey

[Slicky]

Just a quick 2 cents. The dotscene format is the closest thing to a standard i've seen here outside of the OGRE api. It would be great if everyone would focus on that as a standard. From what I have read it is fairly generic so not forcing people in any direction.

The mention of octree to feed collision geom is interesting. I think for comparison I will first do a Tokamak with just one big mesh for collision and see how that shapes up.

[cTh]

Well, if this new method of collision detection that I'm planning works, you won't even need to write a custom Octree implementation. The only big negative at the moment is it's going to have a rather large memory footprint. I'm still trying to come up wtih ways to reduce this.

Glad u come up with something, that sounded to me like a rather bad limitation
...but anyway that's only the collision part and I'll need the Octree for scene management/partitioning too

Hmmm... when I looked at the thread regarding the DotScene format it seemed that for the most part people were trying to avoid anything that wasn't totally generic. And I largely agree with that approach, physics won't be in all games, so perhaps they shouldn't be in the format. But, that said, it would be an excellent place to stick them, so perhaps the approach to take is to extend the format and have DotOgreTokScene or something along those lines. We'll have to see about that.

I really do not see a point in not including phys data in mesh nodes or in some new defined nodes inside the .scene format, it's XML, nodes have attributes, if some reader/loader is not interested it will not parse them, and anyway what's the whole .scene format about if it could not be extended ???
Anyway, we could eve make a new section like <physics/>, like there is <terrain/> and <octree/>, to define and bind phys properties to scene entities, based on name or ID...

[staringmonkey]

Well, in the realm of "ack", this has been a pretty crappy week for OgreTok. My grand plan to implement real-time TriMesh culling on a broad scale fell through the floor for a reason I'm not wholly understanding. Apparently my culling algorithm was about 1000 times slower than just checking against every triangle... not sure how that works. But, that really doesn't matter because over on the Tokamak forums a couple of fellow Tokamak users discovered that using terrain meshes with Tokamak causes a relatively vast number of memory leaks. So unless I want all OgreTok applications spewing out a 200kb log file of leaks, that part of it is relatively useless.

However, (amazingly) that's not the sum of it. Included in this mess is that now that I have gotten this far, Tokamak no longer fits my needs. I had recognized certain problems with it in the beginning, but I had thought that I would be able to solve those problems as I went along. Unfortunantly, I've solved none-of-them. I can't cut back the lag by making objects sleep faster, because the function to make objects sleep faster, as far as I can tell, does nothing. I can't implement TriMesh collision (no matter how clever) because Tokamak's internal TriMesh handling is bugged, and it's callback collision is too slow to be usable without building an Octree into OgreTok, something I'm certainly not prepared to do. Even worse, I'm still having to use 300 steps per second for my test simulations in order to keep my objects from mushing into one another.

So for the moment, I don't know what is going to happen with it. It's a severe disappointment to have come this far and now find that the solutions I'm seeking are impossible to implement in any reasonable way. This, compounded with a bout of insomnia, are not doing wonders for my creative mood, so I'm just gonna step back from it for a couple days. So anyway, I'm not saying it's dead, for those of you who want to use it, it's just comatose at the moment. I'm going to sit on it for a while, maybe play around some of the other great projects that are in the works, until I decide what to do with it. I wish my options were a bit better. About all I can do is A) finish it, leaving out the inherently broken elements, and hope the users are smarter than me, B) switch to ODE and perhaps create OgreODE, which means going through the tweakers hell I was avoiding by using Tokamak, or C) scrap it and my project, which is disheartening on the whole. So ick.

Any ideas, solutions, or beacons of white light from the proverbial heavens... I'll be relieving some tension in Battlefield 1942.

Sincenerly,
staringmonkey

[DaZMaN]

Hello mate,

That's a shame, as you were doing so well Damn that Tokamak. It's starting to sound like a slightly dicey beast underneath. Oh if everything free was the quality of Ogre...

Well, I think there's only one thing for it - you should develop OgreODE You know you're just itching to write some pool physics, and you know I'm itching to split the (theoretical) profits from the game

Apologies for the unusually small post, but web pages are assaulting me...

[KayNine]

Bad news staringmonkey. So I guess you don't wanna hear my "I can't compile the demo" stuff.

I've been using VC6 for a couple of months with Ogre, and got a handle on all the STL stuff. However, VC6 started locking up on compiling (very frustrating) - probably caused by a virus that hit me - so I dashed out and loaded a 60day trail of VisualStudio.net (VC7 2003) I had lying around. It compiles Ogre 13.0 nicely. And compiles OgreTok, but I get lots of STL type errors when compiling the Demo. Am I correct in assuming you are using VC6? Has anyone got this the compile on VC7 (2003)? I'll boot from my other system and see if I have more luck on VC6.

[staringmonkey]

Hey again everyone,

I may have found a decent solution to the memory leak bug (by using the TriMesh callback, but precalculating all the output), and since I have come this far with OgreTok I see no reason not to finish it to the greatest extent possible. So my plan at the moment is to fix up the TriMesh support as best I can, finish up any other little items on my todo list and then just see how Tokamak progresses.

@KayNine (nice name by the way )

Your right, I'm compiling on VC 6.0. I'd like to upgrade to .NET sometime soon, but the opportunity hasn't presented itself thus far. It's strange that you would be getting STL errors for the demo and not the library though, that doesn't make much sense. 99% of the STL usage is in the library...

staringmonkey

[Bren]

I'm able to build the Tokamak demo using .NET. You have to be very careful to do a complete Clean when moving projects from VC6 to .NET. Lots of little build files can be lying around that will still expect stlport, and then screw up in linking.

staringmonkey: Keep at it, man. Great work!

If you'd like, I'd be happy to mail you Tokamak .NET project files.

BTW: It's a little thing, in demo #9 -- which the overlay actually labels #8 -- if you run it, and then press 9 again to reset it, you'll get an Exception:

Code: Select all

-----------------------------------
Details:
-----------------------------------
Error #: 6
Function: SceneManager::createEntity
Description: An entity with the name terrain already exists. 
File: \Project\ogrenew\OgreMain\src\OgreSceneManager.cpp
Line: 298

[staringmonkey]

@Bren

Hey, thanks for the support man. I'll fix the overlay, the exception error is something I know about, it's totally unrelated to OgreTok itself, it just has to do with the way I have the test simulations organized. I wanted to keep all the code for each sim in it's own function (as though it could be pulled out and dropped right into "main()") and since that demo creates an entity by hand (rather than auto-generating like the other demos) it gets an exception if you try to load it twice. For the moment you can just ignore it, it's not a problem with OgreTok, I might reorganize the demo app at some point to eliminate that, but I want to make sure I can actually get TriMesh support working reliably without any internal leaks before I do that.

Thanks again ,
staringmonkey

[Guest]

KayNine here - can't log in.

I recompiled under VC6, and it compiles and runs fine. Now I need to have a good look through it. Not sure what the VC7 problem is, but I'll try to rebuild everything cleanly again.

[cTh]

I'm also compiling on VC++.Net 2003, and really have no problems, everythinh works just fine...

StaringMonkey :
Come on man, I got the feeling that u're about to give up of the nice work u're doing, don't do this, it's maybe better to leave it for a while and then come back with some fresh new idea/approach, it will came sooner or later, believe me

About the Octree stuff, there are some good tutorials on FlipCode about that, and it's really not that hard to do, there are also examples in the OgreAddOns CVS, the dotscenemanager is pretty much clean and easy to understand, DIE also have a custom octree implementation, and it's even cleaner and crystaly clear to understand...it should not be too hard to implement it in OgreTok for internal geom cuuling, or even make OgreTok a scene manager, that, in fact, sound really cool, because I think that colDet should really be thightly integrated with the scene organization to get the most optimal results out of it...

About the lags in the demo
I waited, as u said that it lag on your system too for a few sec...but it in fact never stabilize, it just freeze forever, it is doing something but every frame Tokamak eat twice the time of the last (ie. 1-2-4-8-16...)...really strange, in demo #2 and #4...

just my 2 cents, hope it helps