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

[staringmonkey]

Hello everyone,

I just did the initial commit for my Ogre+Tokamak library to the ogreaddons CVS. It's in the folder ogretokamak. For anyone who didn't see my other posts, it's my way of integrating Ogre with the Tokamak physics engines. It's by no means a complete solution (far from it), but does contain the functionality to make a small, physics-oriented, game. For those seeking a physics engine for your FPS/Racer you should be looking at this thread. So please, no questions along the lines of, "How do I make my ten thousand poly tri-mesh car collide with my heightmap?"

Those points of order out of the way, this thread is for any comments or questions of any variety. Feature requests welcome. Suggestions for improvement greatly appreciated. A large part of the reason for this release was that I'm fishing for comments. I'm looking to make this as fast/efficient/robust as I can. If you do have a question, please don't start other threads (not that I'm expecting a lot of them), just post here, I'll check this thread regularly. However, please read all the documentation in the ogretokamak folder before asking a question. (INSTALL, README, etc.)

I'm by no means an expert programmer, but I've learned a great deal from Ogre and I've had fun working on this project thus far. It was made with a specific game idea in mind, but I plan on keeping it as broad-based as possible. Hope someone enjoys it.

Thanks,
staringmonkey

[KayNine]

Hi staringmonkey

I've been playing with the Tokamak library for a while now - mainly in the ragdoll (the Dude demos) area. The final goal is to incorporate the rag-doll physics into the Poser model importer I'm playing with. So looking forward to playing with your addon.

[cTh]

Hi
I must admit that this really looks awesom, I like the design and simplicity
to use, and I will sure use it

One thing that's bothering, haven't had time yet to debug, some demo sets (keys 1,2,3,4,5,6) make a big overhead to the system and everithing hangs for veru very long (a few mins , I think demo 2 and 4...

Anyway, good work !!!

[staringmonkey]

Hey,

@KayNine

Well let me know what you think.

@cTh

Wow, you mean somebody actually looked at it? I was beginning to think it got lost in some black CVS void. But seriously, thanks. As for your problem that makes me go "hmmmmmmm" out loud. On demo 4 I can understand it, but it shouldn't be "a few mins", on my system it usually lags for up to 30 seconds on demo 4. It's because the boxes take a while to settle to an idle state within Tokamak. I can imagine that it's the same reason for test 2, as that's the second most intensive test. Could you tell me what the specs on your machine are? And also your framerates in a few of the demos (1 and 4 are the best benchmarks, during and after the initial slowdown) if that's not too much trouble?

I'll be adding complex static objects (with breakable geometry) to the package real soon, and replacing the "stacks of blocks" with breakable geometry should have a substantial impact on the framerate. However, under certain circumstances you will, of course, want stacks of boxes, so I'll do my best to find a solution to this lag issue.

(Edit: Another quick note, I'm going to try and remember to add another test simulation that will be like 25 stacks of ten blocks, instead of one stack of 100+. I think you'll see that this lags a lot less due to the vastly decreased amount of initial dynamics. I'll try and get it in the next commit and we'll see. )

Thanks,
staringmonkey

[Vectrex]

any precompiled binaries? DAMN I'm lazy

[staringmonkey]

Nope, it's a bit too much a "work in progress" for precompiled binaries (and likely always will be, for that matter). Besides I don't have the time/webspace/initaitive/etc. to maintain precompiled binaries. However, I think you'll find that the included compilation instructions are exceedingly easy to follow.

As an aside, I'm in the process of restructing the damn thing (again). My problem with implementing complex objects turned out to be much more central to my pattern of inheritence than I thought, so I'm basically restructuring from the ground up. On the flip-side, all the code is already there, I just have to organize it differently, and when I'm done it's gonna be vastly more flexible. (And the actual interface will remain almost, if not exactly, identical.)

staringmonkey

[Slicky]

Thanks for the Tokamak wrapper. I haven't checked it out yet. I have invested a bunch of time into ODE with some rewards and some frustratrations. I have a sneaking feeling that ODE is more feature rich but not certain about that.

It would be interesting to hear once a few people who have tried both compare them.

[cTh]

My system specs :
PIII 650MHz, 256Mb RAM
GeForceII
WinXP

I know it's a piece of s..t , but I suppose demos should work on it

[staringmonkey]

Hey,

@Slicky

Welcome. Yeah, I'm pretty much counting everyone's prior investment in ODE as the reason why more people haven't been interested in this, but yes, your right, ODE is more feature rich. Tokamak, for example, supports fewer joint types, only a single tri-mesh object, less tweakability, and doesn't support plane collision. But, it is incredibly simple to setup and stabalize, so it's really just a trade-off. As I say in the OgreTok readme, if your working on a FPS or a Racer you should probably be using ODE at this point, but Tokamak will work wonders for simple physics-oriented games. (e.g. bowling).

@cTh

Hmmm... well, that is substantially lower specs than mine, so I'm sure that accounts for the lag your experiancing. (I have a AMD 1800+, 640 RAM, GF4 Ti4200, XP) I have to admit it's going to be quite a challenge to write physics-oriented games that work on older machines, as 90% of what it's pushing is the CPU. I may downgrade the demos (or convert them to breakable blocks) with the next commit, and we'll see if that fixes it.

I finished my restructing, now I just have implement breakable bodies later today.

staringmonkey

[staringmonkey]

Hey,

For anyone who cares in the slightest, I've just commited a new version of the source which includes complex dynamic objects (complex static objects were commited yesterday). Also a few small fps boosters (not enough to be noticeable) and some more internal restructuring. Also, two new test simulations have been added to the demo. The first (#7) demostrates a complex static object (there is a complex dynamic object as well, but it's commented out because it moves really strange, due to my lack of a complex inertia tensor computation function) and the second (#8) is twenty-five stacks of five blocks each and a heavy bullet. The latter is mostly for framerate benching.

I'm still not getting the kind of framerates that Tokamak gets in it's simple Glut demos, but given that Ogre is having to process a hell of a lot of scene-nodes, I can't really complain.

Terrain tri-mesh support may be next, I'm undecided at this point.

Cheers,
staringmonkey

[DaZMaN]

Nice one staringmonkey, good work mate I'm afraid I'm in the same situation as the slickmeister - I've spent so much time micro-tweaking the damn ODE code, I'm not sure I could stomach the switch *back* to Tokamak at the moment

Kudos for cracking along with this, the more of this kind of support we 'add-on' (not add) to Ogre, the more options we will all have for building our creations

[staringmonkey]

Yeah, I hear your DaZMaN. I knew that would be the case after the "ODE and Crate Stacking" thread had almost 70 posts. But that's ok too, for my project Tokamak should work fine, and I'm really just enjoying the challenge of tightly integrating another library with Ogre. Ogre is such an incredibly written piece of software I'm learning tons just by mimicking Sinbad's coding style (in fact after I caught myself doing this I started using the british spelling of initalise just to laugh at myself. ) . Ultimately I'd just like Ogre to have a total physics solution with a drag-and-drop level of integration (drag and drop the dll file, that is).

And, ignoring that, what I've seen would suggest that a tightly tweaked, custom ODE implementation is always going to be faster than Tokamak. I don't know that's 100% true, but it's what I've seen thus far. Although, I'm happy to say, that in the time I've been optimizing I have significantly narrowed the gap.

Anyway, I'm ranting, good coding to you,
staringmonkey

[DaZMaN]

Heh, ramble away I'm very guilty of that myself, so I understand completely

Had a chuckle at the 'initialise' thing I hadn't really thought about it - to be honest I'm so used to using the american spelling for certain words like colo(u)r and initiali[s|z]e, I totally forget I'm doing it! Maybe you'll start calling people 'mate' too, I've seen it happen

And I hope to return to the mighty "ODE and Crate Stacking" topic when I have good things to report - I haven't re-read the topic from the top, but I should think it reads like an adventure novel

When I have a bit more time, I'll set up your Tokamak stuff and recreate my simulation - could be interesting to compare the two libs side-by-side with the same sim...

[staringmonkey]

Hehe, actually I already use both 'mate' and 'cheers' and a few other british affects on occasion. Although that comes from watching a hell of a lot of british television more than anything else.

When I have a bit more time, I'll set up your Tokamak stuff and recreate my simulation - could be interesting to compare the two libs side-by-side with the same sim...

That would definantly be fascinating. I'd be thrilled to see some side-by-side framerate comparisons. Right now all my test simulations have a little bit of extraneous overhead because they are generating automatically sizing/scaling debug objects. Very useful, but they do add an entire level of scene-nodes to the mix (since they get their own).

Ummm.... Cheers Mate ,
staringmonkey

[DaZMaN]

*chuckle*

I was just reading the Overlay Editor thread, and spotted you using mate in there Then, as if by magic, the email arrived for your reply here!

"Nice one matey" (you'll need that one too )

PS - I should stop spamming your OgreTok thread now...

[staringmonkey]

Ah, hell, spam away, it's not like it's getting a lot of use other than as my little dev diary. Speaking of which, I just finished totally revamping the surfaces system. Tokamak calls surface properties materials and that was just way too confusing given Ogre's naming conventions, so I (as per usual) wrapped them up into a little class called Surface and abstracted out the material functionality in Tokamak with some internal function calls. Hope to get that commited sometime tonight.

Next... tri-mesh collision... unless I decide to do something else, like collision tables/callbacks.

staringmonkey

[Slicky]

I am involved with ode and trying to get a 4 wheeled vehicle to handle anywhere decently. Unless it is me these physics engines require a lot of tweaking. I guess since they are fairly realistic you have to think about relative mass and even density (lighter tires and less dense). fwiw in Ode I am getting wheels that don't stay locked on the axis. I wonder if tokomak has similar hurdles.

[cTh]

Back to OgreTok
Hi man !!!
I updated your lib from CVS and it seems that there are some files missing,
I suppose you have added some new files (OgreTokDynamicComplex.h, *element.h...)
done a CVS commit but forgot to add the new files first

I'm waiting to test
Cheers mate, cTh (hahahaha...

[staringmonkey]

Hey,

@Slicky

Yes, you face similar obstacles in Tokamak, there are just fewer variables to deal with.

@cTh

Woops! Your right. Still getting used to this whole CVS thing. Take note that the version I just uploaded has some additional changes; Surfaces and Tri-Mesh support. The Surfaces should work fine and I was ready to commit them anyway, but the Tri-Mesh support isn't even close to working so I just commented out the place where it is used in Demo #8. Lemme know what you think.

staringmonkey

PS: Hopefully I will get Tri-Mesh support working later today, but that depends how many unforseen obstacles I encounter.

[staringmonkey]

Woohoo! I'm exceedingly happy to say that TriMesh support turned out to be very easy to add. Tokamak only supports a single TriMesh object, but I've gone ahead and implemented the same map system for TriMeshes that I use for other objects. This way if it ever becomes possible to have multiple TriMeshes, or if someone would like to port this framework to ODE, or if I got really ambitious and wanted to write in a form of shared vertex/index buffering, any of those three things would be possible.

Enjoy,
staringmonkey

This Coding Session's Musical Accompaniment Courtesy of Interpol
-- "He always took the time to speak with me, I liked him for that."

[DaZMaN]

Yay Nice going matey, I'm sure Trimesh support will make more than a few people happy! You're rocking at the moment, keep it up

I'm enjoying reading about your progress, I'm stuck doing websites etc. for a bit now, so you're providing my Ogre/Physics fix

[staringmonkey]

Hehe, nice to know someone is getting something out of it. The rate of at which I see Ogre progressing is providing the fuel for me to keep on this. I just squashed a few more bugs and did another commit. The TriMesh demo is pretty damn nifty to watch, and it gets really good framerates once the objects have stabalized (read: auto-deactivated). It's certainly not entirely out of the question that this could be used for large exterior sections, provided it was handled right.

[FYI: The terrain test simulation (#9) crashes if you try and load it twice, because it's trying to create an entity twice. It's a test simulation specific problem, not a part of OgreTok, and can be safely ignored.]

I'm also toying with the idea of trying to do BSP collision with it. Tokamak provides a callback for triangle sorting (or so I gather, it's totally undocumented so I'm still in the dark on a few things) so it seems feasible that I could implement some form of dynamic BSP collision. But for the moment I'm gonna try and get collision tables/callbacks implemented. I haven't decided if I'm gonna include Tokamak sensors or not. I don't really care for them, but I suppose they are useful in some cases.

I had a laugh earlier when I implemented Tokamak's logging callback (which I hadn't really planned on, but thought it might help with TriMesh debugging) only to discover... that it doesn't log anything. Wasn't outputting a blasted thing when I had it turned on. Oh well.

I'm also still tossing around the idea of some sort of automatic ragdoll generation... I have a few theories on how this might work, but I always get stuck when I get to figuring joint limits and such. I suppose it's a little to implementation specific to be a reasonable feature anyway, but it would have been awesome to be able to pass in an Ogre skeleton and get back a ragdoll, complete with primitive "bones" and limited joints. Would have been an awesome prototyping feature. As it is, it wouldn't be hard to create ragdolls anyway, but auto-ragdolls, well, that's a feature to write home about.

Anyway, rambling again (because I'm in a talkative mood. ),
Ta-ta,
staringmonkey

[DaZMaN]

Ho, had a chuckle at the logging thing Poor old Tokamak - there is a fine beast under there I think, but you need to be persistent and dig for it (and obviously write your own logger!) - I bet this is putting a lot of people off at the moment, and I think the dev's are focusing on version 2.0, to be honest.

I like your idea for the BSP collision, sounds very interesting. So are we talking - asking Tokamak to check collision against it's geometry, for the triangles currently in a BSP scene? Sweet

I really want to check out your code, but these damn web pages won't let me go However, I just had word from my 3D modelling friend, who's working on a pool table and the stuff that goes with it - at least progress is being made

[staringmonkey]

Hey again,

Let's just rename this the staringmonkey and DaZMaN thread.

Yeah, I'm sure your right about the Tokamak team. But still, even if version 2.0 is going to be a total rewrite, they should say so. Questions even vaguely related to the development status of it get completely ignored. I don't mind that's it's somewhat inactive, but if they want any kind of userbase at all, they need to provide some level of support. (I mean really, OgreTok's Doxygen docs are better than Tokamak's documentation ) I posted a thread on their forums a few days back with some very simple questions which would have taken a few seconds at most to answer, and it got ignored. Now naturally, I'm still using it, so the cons haven't outweighed the pros thus far. Like you said, "there is a fine beast under there I think, but you need to be persistent and dig for it". Ain't that the truth.

On the issue of BSP, your essentially right. Tokamak has no support for plane collision, so I can't do BSP collision the same way that OgreRefApp does using ODE. However, it does provide a single TriMesh interface and a TriMesh collision callback, which looks as though it could be using for sorting/culling the triangles that need to be checked against. I'm not sure of the mechanics of it at this point. It seems doable, but there are several things I don't know nearly enough about. I used BSP once, but I don't remember the format in the slightest, so I don't know how easy it's going to be to get simple TriMesh geometry. In addition, I don't know precisely how I would go about culling triangles, even if I got the geometry into place. I'm gonna have to study up on BSP if I wanna try it.

It's also possible that Tokamak does some form of pre-culling to those triangles, I haven't looked into that yet. If that's the case it may be possible to get reasonable framerates without any callback sorting at all. Obviously there is still a finite number of triangles that could be computed in a frame, but that would be a minor speed consideration in comparison to the number of active objects. If the triangles are pre-culled (by a simple bounding box test against the vertices) then you could likely have a very large mesh and still get reasonable framerates provided you didn't have large quantities and/or stacks of objects.

I was gonna ask you what your game project was. Now I know; pool. That's neat, I was thinking of doing either pool or bowling as a test game after I finish OgreTok (bowling was more likely anyway). I've got a larger game project in mind, but bowling would be exceedingly simple at this point. The majority of game could be set up with a couple dozen OgreTok function calls. I'll be excited to see how your game comes along.

Speak Soon,
staringmonkey

[DaZMaN]

Hiya,

That sounds like a great name for a comedy duo

It's a shame about the Tokamak forums, and I know what you mean. I tried to get a couple of answers there, eventually someone did answer, but the devs didn't even bother. Good questions they were too I thought! I think they expected too much from 1.0 - I wonder if they got many takers before they released it on the free license? It's my guess that they decided it wasn't doing the trick, and released it free to attract attention for the impending v2.0 Of course, I'm only speculating there...

Well, I'd say you're going to have fun with the BSP stuff You obviously have a good grasp of the Trimesh stuff, so I think it'll be an interesting adventure! I understand the basics of culling, but I'd need a good while to get into that and BSP too - again I understand the main theory of BSP, but I've never tweaked.

Yes, my current project is a pool game ("with a twist") At the moment it's just a testbed, but I'm hoping to progress it over the next 6 months. My friend is creating some scorching stuff with the modeller too, so I can't wait to see his high-detail table I posted a screenie in another thread (real simple geometry ), but that was a shot of my nVidia drivers doing real spooky things...not the best of examples! I hope to have something more solid maybe next month. I'll let you know!

EDIT: Check this thread about half-way down for the weird effects I would have been impressed, but the video drivers created the beams all by themselves!

Bowling sounds cool, and definitely another good sim setup for testing a physics engine! I imagine it would take a fair amount of our well-loved "physics tweaking" to get it just right...[/url]