JV-ODE vs TokaMak

Blitz3D Forums/Blitz3D Userlibs/JV-ODE vs TokaMak

Boiled Sweets(Posted 2005) [#1]
I was just wondering which is the better physics library.

By better I guess I mean...

1. Easiest to use
2. Cheapest
3. Fastest
4. Most stable

I would appreciate your thoughts...


stayne(Posted 2005) [#2]
what kind of game/app are you going to be using it for?


KuRiX(Posted 2005) [#3]
Tokamak is a very stable library, but i think is not as fast and powered as latest ode wrappers...

And we have the source code of full ode...

So my Vote goes for ODE!


Vorderman(Posted 2005) [#4]
I vote for Tokamak because it does cars better than ODE.


stayne(Posted 2005) [#5]
@Vorderman: i'd love to see an example of that. could you point us to one?


Paolo(Posted 2005) [#6]
I have been using Toka for quite a long time, not much ODE.
The only thing I miss from ODE is the "suspension-joint" feature,
apart from that I think they are basically the same,
you will have to learn some more commands for both of them
but they work similar so I think you better do some test
and see which one you feel more comfortable with.

I vote for Toka, but only because I have been working
more time with it.

Paolo.


KuRiX(Posted 2005) [#7]
Well, i have managed to make better cars with ode than toka, so perhaps is just a matter of preferences...


IPete2(Posted 2005) [#8]
As both are relatively cheap why not get both and decide yourselves, learning the foibles of each system on the way?

IPete2.


Vorderman(Posted 2005) [#9]
Vorderman: i'd love to see an example of that. could you point us to one?


Well, I don't want to blow my own trumpet but the vehicle handling I have achieved for SRX is far better than anything I managed using ODE, suspension joint or not. Did you play the demo that was released a few months ago?

There are some bits of the ODE car that work better - the suspension joint means the car body rolls around very nicely, the cars in SRX don't really do that, but the friction model in ODE means you always seem to end up with a car that either grips all the time, slides all the time, or has that grip->slide happening very suddenly.

The ODE car demo that comes with the current ODE library shows this perfectly - try to do a powerslide - it's impossible.

The cars in SRX (ie. Tokamak)can drift and slide much more progrssively and you can effectively hold an infinite drift with full opposite lock (given enough track and enough driving talent) - I've yet to see an ODE car game that lets you do that.

Also, trying to get an ODE car up to the speeds I've managed with tokamak just causes loads of problems - you may notice that most of the ODE car demos only let you go fairly slowly.

There are some superb ODE-powered racing games (Clubman GT for example) but I really like being able to drift the car and I haven't seen it in ODE yet.

Anyway, I'm sure ODE is great for many things, personally at the moment I prefer Tokamak for doing cars. If you're doing something else entirely ODE might well be much better.


Finjogi(Posted 2005) [#10]
About Ode & car speed, there is simple way to stabilaze ODE tires and testing with 3impact game library car speeds 200-300km/h are managed.


Vorderman(Posted 2005) [#11]
there is simple way to stabilaze ODE tires


Can you explain more?


Damien Sturdy(Posted 2005) [#12]

I vote for Tokamak because it does cars better than ODE.


Vorderman's the only one who's managed that I think. :P I love SRX :)

I managed to give the cars in the "Clubman GT" the ability to drift but i did that through blitz hacks rather than ODE- this also took me almost 3 years to perfect since i never ever got it right.

I'd love to know how you acheived it in Toka since the only think i found toka useful for was rubble in a recent MP tech demo of mine.

I was rather surprised when i saw your SRX game used toka, since i never knew Toka could do it :)


Also, trying to get an ODE car up to the speeds I've managed with tokamak just causes loads of problems - you may notice that most of the ODE car demos only let you go fairly slowly.



Ode's joints get shot after a certain speed. To fix it you have to call the physics update 3 times per loop, which is why Clubman GT requires so much CPU time. If this werent the case, Clubman GT would probrably run on a 400mhz system.



If there's an easier way to fix ODE tyres, i'd love to see that too!


VIP3R(Posted 2005) [#13]
I don't normally take part in these threads, but I need to clarify some things here as this thread is titled JV-ODE vs TokaMak, and not ODE vs TokaMak.


I vote for Tokamak because it does cars better than ODE.


JV-ODE/ODE is also capable of doing cars very well, it all depends on how well they're set up. Have you seen how many car projects are using ODE lately? (including advanced car simulation, not just games)


the friction model in ODE means you always seem to end up with a car that either grips all the time, slides all the time, or has that grip->slide happening very suddenly.


That ONLY applies to ODE when compiled with a fixed friction contact mode, for example precompiled ODE DLL's and the older ODE Blitz wrappers. It doesn't apply to JV-ODE which uses custom contact modes (for all surface parameters, not friction alone). It also doesn't apply when ODE is part of a C/C++ project, because the programmer has the option of customising their own contact modes directly.

Also, the JV-ODE car demo is a quick and simple car set up, it doesn't even remotely represent a completely tuned simulation of a car.

The cherry on the top... ODE is faster than TokaMak, much faster ;)


stayne(Posted 2005) [#14]
my current project utilizes JV-ODE/ODE. the only issue i haven't worked out is the rear wheels flexing during high speed turning.

here's a week old video. i've made lots of improvements since i made it and will post an updated link soon over on the latest JV-ODE thread. i'm now using 3dsmax as lofting/splines is THE way to go for tracks/roads. there's no better way imho.

http://www.strafed.net/stuff/dr1ve-2005-12-11-3-divx.avi


Vorderman(Posted 2005) [#15]
Also, the JV-ODE car demo is a quick and simple car set up, it doesn't even remotely represent a completely tuned simulation of a car


That ONLY applies to ODE when compiled with a fixed friction contact mode


I looked into the other friction modes when I wrote the original ODE wrapper ages ago, and I could never get it to work right despite spending about 3 years trying (using it 'properly' with C & OpenGL as well as via the Blitz wrapper) - in theory it seemed you could set 2 different values for friction along the x and z planes, which means you could have a different lateral friction to that which propells the vehicle, which sounds good. Like I said though I never was able to achieve a decent result. Also the rear-wheel steering problem always caused problems at any reasonable speeds.

I'd love to see an ODE demo with the high-speed rotational stability solved, the unwanted rear-wheel steer sorted and the friction allowing for controlled power-sliding - if this was managed and ODE is so much faster than Tokamak as you say then obviously I'd prefer to use ODE (although I'd say that having to call the physics 3 times to alleviate the stability problem negates the speed advantage - speed vs accuracy perhaps?)

Until I see otherwise I think that Tokamak produces cars that are more fun to drive than ODE cars, unless you are willing to delve in Pacejka and some really complex maths, which unfortunately is way beyond me.


Vorderman(Posted 2005) [#16]
lofting/splines is THE way to go for tracks/roads. there's no better way imho


Have you seen some of the 3d meshes that make up the Gran Turismo tracks? They really are works of art - seen from above the track is very obviously just a thin strip with very little to the sides (high poly density in the centre drops rapidly to huge polys in the outer areas) but in the game it appears (mostly) as an infinite and convincing world. I still prefer 2d pixel graphics to 3d but I can see a certain beauty in 3d meshes such as these, constructed with such attention to what's visible and how best to utilise a relatively small amount of polygons.


VIP3R(Posted 2005) [#17]
I'm not sure whether there's an actual cure to the rear wheel problem, if you turned a real car wheel to a very high speed it would probably break away from the joint at some point too. They also need balancing to prevent from wobbling (causing heavy vibration) at high speed, right?

Maybe ODE is reflecting reality and certain conditions hinder the problem or amplify it? Some tests I've done have shown huge differences in the problem, depending on something as simple as how much mass is applied to the wheel itself. Correcting the wheel mass alone results in a far higher stable speed. The wobbles will still occur but at a much higher rotation speed than before.

Altering the step rate can also help, but as you say it becomes a speed vs accuracy scenario then. But, as ODE is much faster you could probably call ODE up to 4x per loop and still achieve the same frame speeds as 1x TokaMak per loop.

For all we know Boiled Sweets might not be thinking of a car sim anyway :P


KuRiX(Posted 2005) [#18]
Yes there is... I see you are having lot of troubles to get high speed cars working on ODE.

Do you want me to make a jv-ode version of my racing engine?

It should be easy, and it is running a very high speed without rear wheels problem.

The trick is to tune cfm and erp and masses and gravity and suspensionerp and suspensioncfm well.

Hehe.
Cheers, KuRi.


Shifty Geezer(Posted 2005) [#19]
I'm sure everyone would love to see a good car simulation for JV-ODE! It'll settle the idea that it can/cannot be done. The JV-ODE car demo is extremely simple and not set up for tinkering for people to try and get different car handling.

Vorderman : In trying to get two different directional friction values, were you using sufficiently outrageously high values for mu as needed? Low values for mu, averaged between wheel and road, would cause little variation between the two directions. On a road surface of mu=0, 100% friction for a fast spinning wheel might be something like mu=10,000, and you'd be looking at mu=1,000 for half the friction. The friction values for ODE aren;t straightforward, but I've never tried anisotropic frictions so can only guess this might be a problem, if it isn't fundamentally broken in the engine.


Vorderman(Posted 2005) [#20]
Do you want me to make a jv-ode version of my racing engine?

Absolutely - if ODE is faster than Tokamak then in future I'd rather use ODE, especially given the superb bouncy suspension that it has.

The trick is to tune cfm and erp and masses and gravity and suspensionerp and suspensioncfm well.

I tried all this stuff, but there are so many potential combinations that I must surely have missed many variations that would work.

If you can get a car drifting and opposite-locking in ODE I'd be well impressed.

In trying to get two different directional friction values, were you using sufficiently outrageously high values for mu as needed?


I don't recall using any daft values, so probably they were too low....it was years ago though so I can't really remember.

All this makes me want to get a copy of the current ODE wrapper and experiment again, but I must plough on with SRX and get it finished.


OJay(Posted 2005) [#21]
what really annoyes me about tokamak is its bad bad behavior regarding to spheres on staticmeshes (=terrain). you really can't stop the spheres on slipping endlessly over the terrain, which makes it impossible to make a good offroad racing game...this is a huge issue in tokamak and took me over to ode!

also the problem with tokamak is, that you have to put ALL your staticmeshes into ONE mesh before handing it over to tokamak. how silly is that? and you can't have such polycounts as you can with ode. tokamak starts to get really slow beginning of around 32.000 polies, with ode i can make a whole terrain of 500.000 polies (splitted into several meshes) and still can't see any slowdowns...

sure, i could have done something wrong...but i couldn't find any solutions for this, even after 6 months of intense searching and trying...


Shifty Geezer(Posted 2005) [#22]
what really annoyes me about tokamak is its bad bad behavior regarding to spheres on staticmeshes (=terrain). you really can't stop the spheres on slipping endlessly over the terrain, which makes it impossible to make a good offroad racing game...this is a huge issue in tokamak and took me over to ode!
Yes, now you mention it I remember the ever-rolling spheres. That was one of my reasons for looking at ODE. Autodisable was a feature that leapt out at me the moment I tried ODE. And things like subspaces show where ODE can have much greater speed even if the physics solving were no faster (which it is).


Vorderman(Posted 2005) [#23]
Can't say I've noticed this rolling sphere problem - the cars in SRX roll to the bottom of hills and then stop.


Shifty Geezer(Posted 2005) [#24]
On a flat ground, a ball will roll forever. This is true of ODE too but could be fixed by applying a counter force. I didn't find anyway to do that with Tok.

BTW : Has Tokamak changed at all since a year ago when I was using it?


Vorderman(Posted 2005) [#25]
Does using the TOKRB_SetAngularDamping command not cause a moving sphere to slow down? Or using the TOKRB_SetLinearDamping command? That's how I get the cars in SRX to behave, and they have spheres for wheels.


KuRiX(Posted 2005) [#26]
Well, here it is a very fast made car engine. It is a small version of my full engine. It is not as good as the full version but i think it is funny to see that ode can handle cars too.

Source code is included.

It is using my own wrapper. Changing to jv-ode should be easy but i don't have too much time now. There is only one gear, but it is funny anyway.

www.lcuriel.arrakis.es/carengine.rar

Cheers, KuRi.


Shifty Geezer(Posted 2005) [#27]
Does using the TOKRB_SetAngularDamping command not cause a moving sphere to slow down? Or using the TOKRB_SetLinearDamping command? That's how I get the cars in SRX to behave, and they have spheres for wheels.
As I remember, no. Spheres were bugged and needed a collision or something to bring them to a stop. Dunno if the libs been updated since then.


Vorderman(Posted 2005) [#28]
I can sort of see this sphere rolling problem - I just tried driving the car slowly forward in SRX and although it gently rolls along and comes to a gradual halt, it's not perfect - there is still slight creep if the car sits still - it will very very slowly slide to one side, which I assume is because of this sphere problem you mention. I have reduced it by making a variable friction and damping system that increases certain values as the vehicle slows, allowing it to stop, but the creep is still present if you leave it long enough - no idea how to get rid of that, short of resetting the car's position if it isn't moving.

Still, SRX isn't about sitting still in one place, so I don't really care in this context, but it is still not too good though that a rigid body can't sit stationary on another...


Damien Sturdy(Posted 2005) [#29]
With the toka spheres, Personally i just damp roll speed of the spheres before physics update *IF* they have collided. This seems to halt the issue for me in the maship demo.


[edit]
Damp it using blitz code not SetAngularDamping commands.


Damien Sturdy(Posted 2005) [#30]
Kurix, Thats a fun demo but you seem to be having the same realism issues that i get when running physics twice- i dont think you are, I'll imagine your engine itself is better. It certainly seems to be fast enough. I've just got mine to run fast by running two physics updates, the firt of which did a step size of 2X the second of which was a x1. this removed the rear wheel sliding that still occured. Pretty cool.


KuRiX(Posted 2005) [#31]
I am running physics twice too. My full engine is better, because to generate this i have cut lot of parts to make it small...

The source code is included, so you can play changing the main parameters of speed, acceleration, slip, etc... that are giving incorrect results...

Hey Cygnus, what realism issues are you talking about? I know that there is no absolute real physics, but they are easier to get than fake physics.

We all know that a real car running at 200km/h and full turning will be crashed... and game cars do not ;)


Damien Sturdy(Posted 2005) [#32]
haha, I wasn't talking about the absolute real physics, just the car sliding stuff. By the looks of it you just havent got the skid code in the demo. It's still an excelent bit of work :D


Vorderman(Posted 2005) [#33]
Well, I've been playing with ODE all day and I can't achieve a suitable SRX feel - I encounter a few specific problems, listed below. I have also been through most of the ODE mailing list (2 or 3 years worth) and these same problems crop up time after time after time, with no one able to offer reliable solutions.

1. the car flips very easily - even if the car has a large mass it flips over as a result of the slightest impact.

2. the friction is very all-or-nothing - the front grips, then it slips, making the car slide outwards out of control. Even when I get it drifting it's unrecoverable - opposite lock does nothing.

3. ODE seems to self-destruct with no warning, even with very slight changes to certain physics params, and it can happen midway through a simulation that seems perfectly stable, apparently from the slightest impact - wheels get caught up on inclines of a few degrees, either causing the car to stop instantly, or the simulation to explode.

4. there seems to be no way to directly adjust the inertia/momentum of a body, both angular and linear.

I still maintain that Tokamak is better - the car layout I have in Tokamak is very similar to that in the ODE test, yet the Tokamak sim has never exhibited any of the above problems - it is predictable and consistent, something that ODE doesn't seem to manage very well - running the same sim over and over produces widly varying results from just slight changes in velocity or position - take a jump at X velocity and you land OK, take it at X+1 and the car is flipped end over end. Try it again at X+1 but turned a few degrees to the left and simulation explodes.


Damien Sturdy(Posted 2005) [#34]
Ahh, a nice read!

1) False using the correct ratios and perhaps a heavy helper object just under the wheels, though this is a cheat.
2) True, Took alot of work in blitz-side code and its still not perfect.
3)Seems true in new ODE's Not true in your old wrapper :D
4)umm... youre right.

I do beleive toka can do good cars, but its more work to do so. For all the effort i put into getting the old ODE wrapper working though, probrably would have been a good option.


KuRiX(Posted 2005) [#35]
Vorderman, have you test my car engine? Just some posts above.

1) do not happen
2) There is speed, there is turning, and there is slip
3) self destruct?
4) yep.

Cheers!


Vorderman(Posted 2005) [#36]
I do beleive toka can do good cars, but its more work to do so.


No, I can't agree with that - the physics setup in SRX is actually very simple - I have some maths going on to tweak the inertia and apply damping in certain conditions, responding to the controls etc.., but it's really a very basic box + spheres layout, and it just works - achieving the correct front to rear balance for powersliding took time, as did getting the correct power to weight etc.. so it's nicely balanced, but really there is nothing really complex going on, certainly nothing to rival Pacejka.

Reading the ODE mailing lists, the only way to do proper car physics seems to be to drop the box+spheres setup and use a box with rays for the suspension, then use maths for the ground contacts - Racer for example gets some great results, way beyond Tokamak, but it's complex stuff and certainly not quick and easy.

perhaps a heavy helper object just under the wheels, though this is a cheat

Yes, that was one of the first things I tried, still can't achieve that nice soft landing effect though - the carwheel joints distort very easily in impacts causing the car to spear to one side upon landing, something that doesn't affect SRX at all as far as I'm aware.

3)Seems true in new ODE's Not true in your old wrapper :D

Heh, cool! Can't image why they'd be that different though, unless newer ODE versions are less stable.


KuRiX(Posted 2005) [#37]
The trick to get stable cars with ode is using geomtransform so you can push down the center of mass of the object. Quick and easy, but gives unrealistic stability at some cases, so a good tunning is necesary again...


Vorderman(Posted 2005) [#38]
Vorderman, have you test my car engine? Just some posts above.


I did test it - it seemed fairly slow to me, with no real powersliding or drifting, but the car was very stable and didn't flip over all the time, which is good. Reading your posts it seems that your full engine has a different drifting system - would you be able to make a demo of your full system for us to see?

3) self destruct?

I mean when the simulation goes crazy and breaks - typically all the bodies start flying madly in circles and then everything disappears or the program locks up. It seems to always happen following an impact of some sort, in many cases not even a severe impact.

The trick to get stable cars with ode is using geomtransform so you can push down the center of mass of the object

I did try this, but by offsettting the mass rather than using a geomtransform - I just spotted on the ODE mailing list that the mass offset doesn't work correctly, so possibly it had no effect in my program - I'll try the geomtransform instead.


Picklesworth(Posted 2005) [#39]
I think that both engines have their own immense flaws, and thus, just like anything else, are good for some things and bad for others.

One of Tokamak's advantages over ODE is the Convex hull.

One of ODE's advantages over Tokamak is capped cylinders.


For a project that I'm working out, I'll probably use whichever one does the best sliding friction.


Paolo(Posted 2005) [#40]
Mr. Picklesworth
There's a way to fake a capped cylinder in Toka,
just use 4 (or more) boxes RB per entity having
all the boxes at the same x,y,z but rotate each one
an extra angle on the Y axis,
for example:
first RB with angle y=0
second angle y=22.5
third angle y=45
fourth angle y=67.5

do you get me? :)

Paolo.


VIP3R(Posted 2005) [#41]
@Vorderman...


wheels get caught up on inclines of a few degrees, either causing the car to stop instantly, or the simulation to explode.



Tokamak sim has never exhibited any of the above problems - it is predictable and consistent, something that ODE doesn't seem to manage very well - running the same sim over and over produces widly varying results from just slight changes in velocity or position - take a jump at X velocity and you land OK, take it at X+1 and the car is flipped end over end. Try it again at X+1 but turned a few degrees to the left and simulation explodes.


Can you recreate an example of either/both of the above situations in JV-ODE?

I've never seen exploding simulations being caused by either of the above situations. The common reasons for exploding simulations are poor setup and/or forcing ODE to do something instead of letting it do its job.


Damien Sturdy(Posted 2005) [#42]
I'll have a look later. i get this intermittently in what was to become EngineV2 when using Trimesh. the car would bounce backwards on the edge of a triangle.


Vorderman(Posted 2005) [#43]
Can you recreate an example of either/both of the above situations in JV-ODE


I can - I have been working with the cardemo.bb program that comes with the wrapper, modifying it a bit to try to get the car racing over one of my SRX stunt racetracks, and I've broken the simulation lots of times - undoubtedly some were down to a poor choice of numbers setting up masses etc.., but quite often the simulation would let me complete a lap or so, then explode at an unexpected moment.

I'll see if I can find an example setup that crashes often but randomly to send to you.

The main gameplay problem seems to be trying to make the car not flip end over end after landing from a jump, but I haven't tried your tip of using the geomtransform yet - I'll try that tonight and let you know how I get on.


VIP3R(Posted 2005) [#44]
Ok, thanks I appreciate it :)

I can run my project and do lap after lap without any problems at all (on a large track with 8 cars). Have you checked for memory leaks?

The Geom Transform trick is a very good solution to the flip problem, it also affects how the car slides etc. If you're not sure how to do this in JV-ODE, let me know and I'll help you.


Vorderman(Posted 2005) [#45]
The Geom Transform trick is a very good solution to the flip problem, it also affects how the car slides etc. If you're not sure how to do this in JV-ODE, let me know and I'll help you.


Cheers, it'll be interesting to see if it affects the grip->slide->grip problem that the wheels seem to have, almost as if they are skipping off the surface of the mesh every few milliseconds.

I currently have it using the massoffset function, so it should be easy to swap over to use the geomtransform instead.


Boiled Sweets(Posted 2005) [#46]
WOW! What did I start? Erm but back to the thread guys...

Please just post either "Tokamak" or "JV-ODE" please...


Ricky Smith(Posted 2005) [#47]
PaceMaker uses ODE in the shape of the jv-ode wrapper - I tried for many months to use Tokamak - there were far too many issues.
The ODE engine,for my purposes at least , is a better overall design - the space partitioning is excellent - It's extremely flexible,highly configurable and unbelievably stable and easy to work with. I really put this lib through its paces and it has always done what I want it to do.
Maybe for a different type of simulation Tokamak may be suitable but from my experience at working with both - ODE wins hands down.
The extra work and commands that has been put into the jv-ode wrapper makes it an even better proposition - vip3r has done a tremendous job with this.


Damien Sturdy(Posted 2005) [#48]
I agree with Smiff personally. bar the few problems which are more likely caused by human error than anything, JV-ODE is creme de la creme. :)


big10p(Posted 2005) [#49]
I have yet to use a physics lib but from what I've heard and seen, JV-ODE would be my first port of call.


Mark Judd(Posted 2005) [#50]
Would go for ODE.
Although both systems have plus points, i find ODE better for vehicles every time.

Used Tokamak for my previous project and struggled with the grip.

Voderman (OT) :
Love SCR and was working on a version, but not as good as yours so moved to this :-

http://www.blitzbasic.com/Community/posts.php?topic=54075

Slower pace, emphasis on technical handling rather than speed.
ODE seems to work OK with car landing after jumps.

cheers

Mark


Vorderman(Posted 2005) [#51]
Cool demo Mark - you seem to have the car working nicely - how does it cope with large jumps and more speed? Can the car drift around corners?


stayne(Posted 2005) [#52]
Vorderman... in my project I can drift/hold all day long. It's just a matter of getting the gravity, friction, mass and all that just right. Like VIP3R said to me once, you have to find the sweet spot. I'm not sure if it's a question of how long it takes... I think it's a matter of luck :)


Vorderman(Posted 2005) [#53]
I don't know....no matter what I do the ODE car just doesn't work right at speed, even using the geomtransform doesn't help it.

It feels like the car body has no interia - it will flick left or right instantly no matter how heavy it is or how high the friction values are.

I just can't be doing with this - I can get a car working 10x better in Tokamak, 10x faster, 10x more fun and with no simulation crashes at all, so it feels pointless to spend hours messing around with ODE hoping to stumble upon these magical values that work....

I spent 2 years or so with the orignal ODE wrapper and in all that time I never achieved a nicely drifting car that wouldn't flip at any opportunity - something just feels wrong in ODE, bodies respond really badly to high speeds or impacts, momentum seems to mean nothing - increasing a body's inertia in Tokamak makes it respond with a feeling of increased weight, and this is critical to the way the SRX cars respond when jumping, sliding and drifting - you can't do this in ODE, which seems like a major omission.

Anyway, this could go on forever - I'm not carrying on with ODE for the time being, I'm going back to Tokamak to (hopefully) complete SRX.


Vorderman(Posted 2005) [#54]
in my project I can drift/hold all day long. It's just a matter of getting the gravity, friction, mass and all that just right


I'd really like to see it, but until I do I'm afraid I have to remain sceptical that ODE can achieve a decent powersliding car by just guessing the correct values.

Please prove me wrong though - do you have a demo or video?


stayne(Posted 2005) [#55]
i've posted several videos above, but none show drifting enough to satisfy.

when i get home tonight i'll sit down with a six pack of beer and fraps... hopefully something will come out of it :D


Vorderman(Posted 2005) [#56]
Cool, looking forward to seeing whatever comes from your beer'n'fraps session :)


Panno(Posted 2005) [#57]
ode or toka ???

what is better for a "ball rolling on mountains" game ?


i have a idea for a cool game imho
but i need some infos
thx

a demo anyone ?? vip3r ???? ;)


stayne(Posted 2005) [#58]
Vorderman... you win... for now. Check your email, lol.


VIP3R(Posted 2005) [#59]

what is better for a "ball rolling on mountains" game ?


ODE can do this very well and it's simple to set up. If you need any specific info, feel free to contact me or post in the JV-ODE thread (poor Boiled Sweets thread is going off topic again) ;)


Mark Judd(Posted 2005) [#60]
Vorderman: Sorry never replied to you earlier.

re:Drifting - the ODE model is very snappy as you've found, although i've been messing with the friction values for the contact joint (second direction) with some success, i'll e-mail you to discuss so as not to hijack Boiled Sweets any further!).

cheers,

Mark


Shifty Geezer(Posted 2005) [#61]
ode or toka ???

what is better for a "ball rolling on mountains" game ?
I would say ODE, because Tok has troubles with stopping spheres, plus the fine-parameters of ODE will allow for better fine-tuning, and the easy joint system of ODE allows painless addition of seesaws and rotating barriers etc.


Panno(Posted 2005) [#62]
thx :)


Finjogi(Posted 2005) [#63]
Vorderman: Can you explain more?

(ODE tires...)
Sorry for late reply.. simply setting rear tires to default orientation in "simulation" loop fixes error accumulation. Front tires could be set too but usually steering sets them anyway.

Link to 3impact thread: Link


Hambone(Posted 2005) [#64]
A lot of the debate between Tokamak and ODE seems to come down to vehicle simulation.

For the math inclined and those who love all things "simulated" I strongly recommend a visit to this site.

http://home.planet.nl/~monstrous/tutcar.html

Printing it off helps ....

Allan


ZJP(Posted 2006) [#65]
Hi,
I use the both, but Tokamak with EasyTok (http://www.blitz3dfr.com/phpfrench/content.php?content.47)
is a very good "pak" for newbies like me.
Awesome job : Examples and docs

JP


Filax(Posted 2006) [#66]
:)

Happy to see happy EasyTOK user :)


yinch(Posted 2006) [#67]
I have used both Tokamak and JV-ODE and personally prefer JV-ODE for a number of reasons:
1. linked to the ODE library which is independently developed
2. faster simulation
3. VIP3R does a great job of updating JV-ODE
4. Cheapness

yinch'06

p.s. hmmm my sig file is horribly out of date


Sweenie(Posted 2006) [#68]
Tokamak is totally free as well so I don't quite get why ODE would be cheaper than Tokamak.


Battle Tanks(Posted 2006) [#69]
The support is very good with JV-ODE. VIP3R must be online 24/7.

for that reason alone JV-ODE is the one to go for. well worth £10 of anyones money. he has not taken longer than one hour to respond and work till 4 in the morning

The question is JV-ODE + VIP3R better than EasyTOK and who ever suports it!