JV-ODE Physics Thread 2

Blitz3D Forums/Blitz3D Userlibs/JV-ODE Physics Thread 2

VIP3R(Posted 2005) [#1]
The JV-ODE user library contains almost all of the ODE functions wrapped inside a DLL.

The library can be used in any programming language that supports DLL's, including Blitz3D and BlitzPlus. The functions have been adapted to use euler angles (the same coordinate system as Blitz3D), however functions for accessing quaternion angles are also included. The download contains all of the necessary files to get you started, including some simple demos showing various ODE objects and TriMesh collisions.

To view more information and screenshots click here.

Options are now available to purchase the wrapper using either PayPal or Share*it.

The restricted demo version is now available for download here.

Have Fun :)

Previous JV-ODE Threads: 1
JV-ODE Player Factory Forum

Useful Links: ODE.org Website - ODE User Guide (PDF) - ODE User Guide (HTML) - ODE Archives


Barton(Posted 2005) [#2]
>>Personally I would build both methods then test them fully to see if there are any issues with each one. Let us know how you get on with it :)

I have tested both methods much and both works equally well. I Using the JV-ODE on a couple of objects in my Game.

@all:
Which method would the others prefer ? :)

A) with new ODE_INIT/CLOSE (restart ode)...
B) only destroy bodys and geoms without closing the ODE...

...before reload the Level.

the question Which solution is last better,healthier and sure ?
I must make up a Method now. Then there is back none more. :)


Beaker(Posted 2005) [#3]
Viper - probably worth putting a link to the old thread up there ^^^ as I've locked the old one now.


VIP3R(Posted 2005) [#4]
Cheers Beaker, I've added the link - it completely slipped my mind ;)

@Barton: What kind of game are you working on? If you don't mind me asking ;)


Barton(Posted 2005) [#5]
I have installed both methods which one can choose over INI file now (ODE_RESET=0 or 1). If there should be problems, one can change it over. :))


@VIPR: i working on a very big 3D-Action Shooter. :)

thanks to her great ODE-Wrapper the game makes a much better impression. :))
I tested all physics Engines, but JV-ODE is the best of all. Who does not use JV-ODE, much misses... :)

In addition, thank-beautifully at developers of the other Wrapper.(Freeware ODE,Tokamak Lib). I respect each hard work. These also surely will have her fan's.

For good such things I am always ready to pay!

I hope for further such master Tools/Libs of you all. :)


Damien Sturdy(Posted 2005) [#6]
Hehe. Some good things going on here. Hopefully i will have a few hours soon to get Cygnus Car Engine v2 up to speed soon. Its not exactly difficult this time around :)


Caff(Posted 2005) [#7]
Just bought it... decided it was looking good now :)


Mustang(Posted 2005) [#8]
What's the status with the Trimesh stuff? I've been away for few days and just want to check that I have not missed anything important.


JaviCervera(Posted 2005) [#9]
The wrapper is still on version 1.01, with that TriMesh issues if you don't use spheres for collisions.

After 4 hard months, I finally got holydays at work! I was really in need of some rest, and form tomorrow I'll be out until sunday. So if you purchase through PayPal, you won't receive the wrapper until sunday. This does not affect ShareIt sales.

After that, I'll have to reorganize my time. University, work, and coding can be a lot of things if you don't use your time correctly!


VIP3R(Posted 2005) [#10]
Hi Mustang,

Still working on it, you haven't missed anything ;)

As soon as I have more info on the TriMesh progress, I'll post it here. Tbh, both Jedive and myself have been up to our eyeballs in work lately, but I'm done now and I think Jedive will have a bit more time available soon too.

Those who've had 'Userlib function not found' errors on the demo version, I haven't forgotten you either - I'm still working on that too :)

More soon...


EddieRay(Posted 2005) [#11]
Which version of ODE is JV-ODE built against?


VIP3R(Posted 2005) [#12]
JV-ODE is built using the latest ODE code (Version 0.5) ;)


Chaduke(Posted 2005) [#13]
Anyone know what's up with the ODE website? I haven't been able to access it for several days now. Also, is there an ODE specific forum somewhere else? Thanks.


EddieRay(Posted 2005) [#14]
Did you build the ODE library from source, or are you using one of the binary releases of 0.5?

Thanks,

Ed


Wayne(Posted 2005) [#15]
Home of ODE: http://www.ode.org/ (shows as working)

Home of JV-ODE Wrapper: http://www.devcode.co.uk/jv-ode.html (shows as working)


VIP3R(Posted 2005) [#16]
@chaduke: The ode.org website was down earlier giving 403 and 404 errors, but as Wayne says it's working ok now. There is another forum for JV-ODE at the Player Factory :)

Btw, Wayne might be able to help with the setting forces issue, he knows his stuff. Are you a member at the Player Factory forum Wayne?

@EddieRay: I've compiled a test dll using the CVS releases but the JV-ODE full/demo dll's are compiled with the binary release, not certain about that though as Jedive obtained the original ODE code.


Chaduke(Posted 2005) [#17]
We need to get some posts going over at the playerfactory forums. I just bought the wrapper a few days ago and have a ton of questions about using ODE in general as well as what's the best way to implement the different functions in Blitz.

There's bound to be tons of people that want to learn how to use this well. I'm kind of surprised the official ODE page doesn't have forums, but they have a mailing list and a wiki.

As of right now I basically know how to add primitives to my scene and add force to them. I'd love to see examples (in Blitz) of the following:

Adding resistance to slow down the rotation and velocity of objects.

Collision detection with a bumpy terrain (it may be easier to just use Blitz's collision detection for this)

Skeletal animation and ragdoll functionality.

Simulating real world objects, like what are the best settings for gravity, elasticity, mass and density to create a realistic baseball, tennis ball, basketball, human body, etc.

Simulating spin effects as an object travels thru the air, like on a ping pong or tennis ball. It appears that spin affects objects as they collide with each other or the ground but I'd also like to know how to increase or decrease this effect. I'm assuming this is similar to how slippery the terrain is in a vehicle simulation.

As I continue to read the manual and experiment with things I'll post my results to the playerfactory forums and maybe create some short tutorials, but it would be great if other people have examples like this already that they can contribute.


Wayne(Posted 2005) [#18]
Expanded Spheres Demo

Features: Autodisable, Applying forces to push and pull spheres with the mouse, Selecting bodies and creating joints between them, Applying forces to attract and repulse. Linear and angular friction.

Were really just getting started with all the great stuff you can do with ODE. Check all the demos, be sure to check the other threads as well.

The following code should work well, you may have to provide a bmp, or comment out a little.




Wayne(Posted 2005) [#19]
External forces like friction or lift need to be calculated.

Lots of effects are possible, look for more examples coming soon.

I was pleased to see Mark has tried some ODE and likes it.


Picklesworth(Posted 2005) [#20]
Does ODE do convex hulls?


VIP3R(Posted 2005) [#21]
Not at the moment Pickles. It's a difficult problem to solve in ODE, partly due to the way ODE works internally.


EddieRay(Posted 2005) [#22]
One solution to the "trimesh collision problem" might be to just use B3D collision for that type of collision. ODE is perfectly happy to work with an external collision system. This is the way I've seen ODE used with Torque... basically, Torque has several complex types of geometry (terrain, shapes, interiors, water, etc.), and there is already code to do fast collision checking between the various types of geometry. Likewise, B3D already has a collision system that can detect trimesh vs. <whatever> collision, without any added collision geometry objects. I think the B3D collision commands even allow you to detect which surface and triangle has collided, and you can do collision normal calculations, etc., with that data. I've never really used B3D collisions tho', so I may be missing some key detail that makes it unusable for this purpose...

Just a thought...

Ed


Damien Sturdy(Posted 2005) [#23]
~Eddie, true, but i can chop a couple of MS (hey, a MS is a MS) off when not using blitz collisions. Linepick is used to get that data in my current code and linepick is SLOW (just remming it out causes a visible updatetime drop..but of course, kills everything that needs it...)

I'm hoping theres a better way :P


KuRiX(Posted 2005) [#24]
You can use Blitz3D Collisions with ODE, but you would need to pass lot of information to the dll, cause ODE uses a callback to implement this, and Blitz has no callback support.

You could make a big list with every contact information (each frame) and then pass it to ODE. Anyway the wrapper should be made to wait for this...


Alienforce(Posted 2005) [#25]
Vip3r and Jedive,

Can i use JV-ODE now on barrels and crates and so on ???
Would like to use it with the game iam working on..

/Alienforce


VIP3R(Posted 2005) [#26]
Yeah, you should be fine using it for those Alienforce :)


Alienforce(Posted 2005) [#27]
Vip3r,

I got version 1.01 is it the latest ?

Have been in the US so i havent have time to check my mails.

/Alienforce


VIP3R(Posted 2005) [#28]
Yep, 1.01 is the latest version of the wrapper ;)


PsychicParrot(Posted 2005) [#29]
Ok, well ... things have gone OK so far but I wonder if anyone knows how to do something like a corrector, where there would be forces to keep the car 'upright'??

I have a car model that I want to keep almost upright, but not totally ... I don't want it to be able to roll basically, but I do want it to be able to align to the terrain (so I can't just 'fix' the rotation to an upright pos if you see what I mean...)

Any thoughts?


VIP3R(Posted 2005) [#30]
Hi PP,

Sounds like you want a similar effect to Need For Speed Hot Pursuit 2. One way to do this is to lower the center of gravity for the car using the translate mass function.

Experiment with the car demo (it contains this function). Try changing the 2nd parameter (Y-axis) on this line:
dMassTranslate(mass,0,-1,0)

The lower you set it, the harder it will be to roll the car. So you could try -10, -100 etc and see how it reacts.

There may be other ways too, but I'd try that first.


PsychicParrot(Posted 2005) [#31]
Just to update .. no luck yet .. lowering the centre of gravity seems to make it act freaky during jumps (kind of like a jelly on wheels, where the wheels are attached by wobbly jelly struts!) ...

I want to have a go at using forces to compensate for roll (so if it's leaning some on the x axis, apply a force to pull it back .. the only problem is that the forces will have to be relative to the angle AND the angular vel won't they? So that the car isn't 'stuck' in a upright pos, but gets limited in it's rotation by forces.

Urks! Lots of thinkin' to do!

Thanks, Viper!


KuRiX(Posted 2005) [#32]
Do not use translate mass. Use the geometry transform functions. They Work awesome!.

You encapsulate a box that is positioned at (0,+X,0), so the geometry is at 0,0,0, (with mass at 0,0,0) but with the encapsulation is collides with the geometry at 0,+x,0.

It is the best way!


EddieRay(Posted 2005) [#33]
@Cygnus: Hmmmm... I'm not sure why it should be slower to pass the collision contacts from B3D to ODE as opposed to having the wrapper do it in the same manner. IIRC, the collision in ODE works very much like B3D - you call the collision code and get a list of "contacts"... then you have to feed these all into the "sim" each time step, and delete them after the physics calculations are done. Using B3D collision, the process would be very much the same... you collect the collisions from B3D, feed them all into the "sim" before stepping, do the actual step, then delete all the "contacts".

Of course, one reason it might be slower is if the B3D collision code is slower... but from what I've seen, once you start using a trimesh or two, the ODE collision code seems very slow (to me at least).

Anyway... just some more thoughts on the issue...


KuRiX(Posted 2005) [#34]
The main difference is that ODE Collisions do not make a response. Instead, the contact joints make the response. In B3D, the collisions make the response automatic, and you can't change that. So there will be a big difference between both methods...


Alienforce(Posted 2005) [#35]
How do i use JV-ODE on my meshes ?? is it trimesh ??
I am thinking of things like statues etc... i cant get it to work.. has any one a short exemple ?!?! for crates and barrels for my own meshes i use dcreatebox and dcreateccylinder but what about objects likes statues,humans ???

/Alienforce


Alienforce(Posted 2005) [#36]
Any news on the Trimesh Problem.... please ????

/Alienforce


Alienforce(Posted 2005) [#37]
Jedive ?? Vip3r ?? :(

/Alienforce


Wayne(Posted 2005) [#38]
I wish wrapper source was distributed to paying customers, so we could customize and/or contribute changes back to the authors.

Statue = static trimesh and I would expect spheres to interact with it under the current wrapper. I'll try some different examples and see.

Post some code if you can.


Alienforce(Posted 2005) [#39]
My biggest problem right now is cylinders and boxes falling thrue my trimesh landscape.. have tryed to use spheres wrapped crates and barrels... but it just dont dont it for me... crates shall not roll away :)

/Alienforce


VIP3R(Posted 2005) [#40]
Hi fellas... sorry for the delay, I've had to go to Wales over the last few days to attend a family funeral :(

Jedive should've been around though, maybe he's busy with his university stuff again?

No news on the TriMesh this end yet I'm afraid, I still haven't heard from Jedive about this issue despite several requests :/

The problem isn't in the wrapper btw, it's in the original C++ ODE code, that's why it has been so difficult to nail. Just look on the ODE message boards and you'll see a great number of people are working on this TriMesh problem. Fixing it may involve rewriting part of the ODE library, which is a very difficult task - I'm sure you'ld agree.

Alienforce what you're doing with the sphere wrapped crates etc is the correct way to go in most cases I feel. If your crates are rolling you haven't set the joints correctly (or are using the wrong type of joint). You need to make sure you lock the joints, then the crate will stay put.

Something I've found whilst looking into the TriMesh problem is the loss of speed in the physics simulation when they're used. ALWAYS avoid use of TriMeshes where possible, they are a LOT slower than the primitives because of the amount of collision contacts it has to deal with during each time step.

As soon as I get some more info together on the TriMesh problem, I'll post it here right away...

Cheers


Alienforce(Posted 2005) [#41]
Really sorry to hear about funeral..

Thanks for your reply...

I keep on working with my sphereizedcrates ;)

/Alienforce


VIP3R(Posted 2005) [#42]
Thanks Alienforce ;)

I may make a demo soon showing something like that, I'll do some tests here and see what works best.


Alienforce(Posted 2005) [#43]
Any news ?

/Alienforce


VIP3R(Posted 2005) [#44]
On what, the TriMesh issue?

Any luck yet with the sphere wrapped crates?


PsychicParrot(Posted 2005) [#45]
Mainly targeted at Kurix for suggesting it ... ;) ... Using geometry transforms? I read through the ode manual and got all kinds of stuff I couldn't understand! Any chance of a little sample or something??

dGeomID dCreateGeomTransform (dSpaceID space)
dGeomTransformSetGeom (dGeomID g, dGeomID obj)
dGeomTransformGetGeom (dGeomID g)
dGeomTransformSetCleanup (dGeomID g, int mode)
dGeomTransformSetInfo (dGeomID g, int mode)

... what does it all mean?! :D


Damien Sturdy(Posted 2005) [#46]
I hope the trimesh issue does get fixed, the main reason i bought it relies on them you see, And development seems slow at the mo.... Lets keep it up guys!!!!


KuRiX(Posted 2005) [#47]
Hey PhychicParrot. Sorry for the Delay. I was not in home. Here is my code for a body of the car that raises the geometry, keeping the mass down:

Jugadores\body[1]=ODE_dBodyCreate()
ODE_dBodySetBoxMass(Jugadores\body[1],tamanochassisx,tamanochassisy/2.0,tamanochassisz,Masa1)
Jugadores\geom[1]=ODE_dCreateGeomTransform(space)
ODE_dGeomTransformSetCleanup(Jugadores\geom[1],1)
temp = ODE_dCreateBox(0,tamanochassisx,tamanochassisy/2.0,tamanochassisz)
ODE_dGeomSetPosition temp,0,AlturaModelo#,0
ODE_dGeomTransformSetGeom(Jugadores\geom[1],temp)
ODE_dGeomTransformSetInfo(Jugadores\geom[1],1)
ODE_dGeomSetBody Jugadores\geom[1],Jugadores\body[1]

Good Luck!

Now here goes the explanation. You make a geometrytransform object (think about it like only a new type of geometry). Then inside this geom you will insert a normal box geom, but with a special position (in my case "AlturaModelo#" in y coordinate). And then, you assign the body to the geomtransform geometry. So the object is really on 0,0,0 but the collision box is in (0,AlturaModelo,0).

So the result is "ALMOST" like translating the mass down. I say almost because the body is really on 0,0,0 so perhaps you will have some differences with joints positions, like suspension in the car. Anyway, it is a worthy way of doing it!


KuRiX(Posted 2005) [#48]
And for the trimesh problems. I am using my own version of the wrapper and i don't have any problems (i am almost finished my racing-rpg game). For what i've seen it is easy to wrap the trimesh functions, so i think jevide and vip3r have done it right.

So check your gravity values, quickstepsize, quickstep iterations, total mass, etc to be sure there is no too much interpenetration.

If you have too much speed for some body, the collision in ode doesn't work like in B3D. The object can pass through if there is no step in collision.

Cheers!


Alienforce(Posted 2005) [#49]
KuRiX.

Do you have some working trimesh code to share so i can see what iam doing wrong with JV-ODE ??

/Alienforce


KuRiX(Posted 2005) [#50]
Well the code i use to make the trimesh working is the same that Vip3r made to work with the original arkon's wrapper. So i think the problem is with the jv-ode wrapper, not your b3d code...


Alienforce(Posted 2005) [#51]
Jedive & Vip3r,

Just want to know if you are still working on the wrapper..
I absolute dont mean any harm or to be puschy....

/Alienforce


KuRiX(Posted 2005) [#52]
Alien, if you can wait, wait while i try to finish my editor. I think it will help u a lot...


VIP3R(Posted 2005) [#53]
It's ok Alienforce :)

Yep I'm still working on the wrapper, I haven't done much on it lately due to recent events.

I'm discussing the future of the wrapper with Jedive at the moment, I hope to have some more news very soon. I haven't fixed the TriMesh problem yet, so don't get too excited ;)

Looking forward to seeing your editor too KuRiX ;)


Alienforce(Posted 2005) [#54]
Thanks Vip3r,

Kurix waiting like a kid on christmas. :)

/Alienforce


Alienforce(Posted 2005) [#55]
VIP3R:

Take example "JV-ODE - Spheres Demo" try to make boxes (my crate problem :) ) instead of spheres and make them not rollaway .. i am doing somting really wrong because my boxes just rolling away! Arghhhhh.. :) .. if you could help me because i think i am going nuts....

Spherewrapped boxes - Correct, for trimesh use.
Tried to read about the joints you tipsed me about but no luck...

Sorry to bother you with this, but iam in the middle of a game and would like to use the ode. for my barrels and crates :)

Best,

/Alienforce


VIP3R(Posted 2005) [#56]
No problem Alienforce, I'll see what I can do :)

I've actually already got a sphere-wrapped cube (crate) sitting/rolling (without sliding) along on top of a TriMesh terrain. It isn't perfect yet though, sometimes when the cube comes to a standstill it kind of wobbles a bit. I need to experiment and optimise it a little more before I provide a demo. As soon as I have something which works well, I'll post it on this thread for everyone. The exact same method can be used for cylinders too.


PsychicParrot(Posted 2005) [#57]
Thanks, Kurix - really appreciate it :) .. I'll have a play and see if I can figure it out later, as on first read I got scrambled!!

Cheers


VIP3R(Posted 2005) [#58]
Update on the sphere-wrapping tests...

I've got it working very well now :)

This might be a worthwhile solution to the TriMesh>Cubes/Cylinder collision issues, it's that good. Early tests suggest it's fast too, although the system I'm working on is flexible so the user can decide how complex the collisions are :)

Should have a demo real soon...


Wayne(Posted 2005) [#59]
post that bad boy
8)


VIP3R(Posted 2005) [#60]
Ok, here is the sphere wrapped cube demo I've been working on. It's a modified version of the TriMesh Car Demo, but instead of random spheres you have cubes rolling on the TriMesh.

You can customise the complexity of the wrapping by using the 3 different wrap types (simple/complex/full). Try changing the wrap type in this line of code:
SphereWrapCube(ode\body,10,8,8,8,0,1)
Parameters (Body,Mass,ScaleX,ScaleY,ScaleZ,WrapType,Alpha)
Wrap Types (0=Simple 1=Complex 2=Full)

You can also customise the data (at the bottom of the code) to control whether each individual sphere is added or not. It's a trade off between speed and accuracy, so experiment to see what works best for you.

Sphere Wrapped Cubes Demo


It should be easy enough to add to your existing code, all you need to do is call the SphereWrapCube() function when you create your cube. It isn't optimised for rectangles though, so you may need to adjust the sphere offsets for those.

Let me know if you need more info :)

[EDIT] I've slightly modified and reposted the above code. Also note that you must wrap the cube with zero rotation, you can rotate it normally after wrapping.


Alienforce(Posted 2005) [#61]
It works great!!! thanks VIP3R!!!!

/Alienforce


VIP3R(Posted 2005) [#62]
You're welcome :)


Mustang(Posted 2005) [#63]
Hey, cool VIP3R! Too bad that I'm not home during the coming weekend, so I will be able to test this next monday earliest... duh!


VIP3R(Posted 2005) [#64]
>>> IMPORTANT ANNOUNCEMENT <<<

As a few folks have recently noticed, progress on the JV-ODE wrapper has been a little on the slow side lately. Unfortunately, due to an increased workload at university and other time-consuming commitments, Jedive has been unable to spend much time working on the wrapper since the last update. As Jedive and myself were working as a team, this has made it very difficult to advance the wrapper.

So, as I hinted in an earlier post... over the last few days we've discussed the future of the wrapper at length. Jedive has decided that it would be a lot more beneficial for all users of JV-ODE if he discontinues work on the wrapper, as he currently has little or no time to spend working on it. He's very keen to see the wrapper continue to make progress on its new journey.

I'm sure you will join me in wishing him the best of luck with his university work/career and thank him for the great work he has put into the wrapper so far :)

What about the future of JV-ODE?

Well, I'm pleased to say that I'll be continuing work on the wrapper. I've been working constantly in the background recently - not only to address the few problems that the wrapper currently has, but also to get things back on course for eventual completion.

There are now three new demos dealing with 'sphere wrapping' of cubes, cylinders and capped cylinders. This enables these primitives to collide with the TriMesh and provides a decent work-around while the TriMesh problem is investigated further. Only the cube version has been publicly released so far, but the other two are now mostly complete and work really well.

The most exciting news is that I'll be working on the wrapper alongside another one of the many talented people here on the Blitz forums. He's well known and respected by many here, and will bring a lot of expertise to the table, which will help to give the wrapper a new lease of life and speed up development. I won't say who it is just yet as it isn't quite set in stone, but I trust you'll be as thrilled as I am to have him on board.

If anyone has any questions or suggestions, please feel free to post them here.

Thanks to all for your support of the JV-ODE wrapper :)

More news to come very soon...


Alienforce(Posted 2005) [#65]
Good work Jedive and dont study to much :)

And thanks Vip3r continue the work with the wrapper.

/Alienforce


Mustang(Posted 2005) [#66]
Good news, sort of - I can really understand that studying and such can take so (too) much time... good luck to you Jedive, and hopefully the JV#-ODE [insert the missing letter] will get 100% finished with the help of new blood. Thumbs up!


VIP3R(Posted 2005) [#67]
Cool :)

I've had a few folks asking about the sphere wrapping demos, so here they all are...

Sphere Wrapped Cubes Demo
The code for this demo is posted up there ^^^ [7 posts up] ;)

The cylinder and capped cylinder demos are below using a similar method to the cube version. As with the cube version the complexity can be customised and all sphere wrapping must be performed with zero rotation. After the wrapping function is called you can rotate the cylinder normally.
Note: the cylinder length must be at least twice the radius for these algorithms to work correctly.

Sphere Wrapped Cylinders Demo


Sphere Wrapped Capped Cylinders Demo


I'm looking for some cool demos to bundle with the next update, so if you manage to create something that'll knock peoples socks off - let me know! :)

The ones I've really liked so far would be Wayne's excellent pull/push/select/force/friction demos and PsychicParrots great Angular Velocities demo, it would be great if we could make those demos official and include them with the library.

Btw, the sphere wrapped demos are still work in progress, so they may have changed a little when they make it into the next update.


JaviCervera(Posted 2005) [#68]
Hi guys.

As you may have noticed, I used to be a very active member of this community, but this situation has changed dramatically in the last months.

If everything goes well, I will graduate in History this year. If it does not go that well, I will graduate next year, but I'm doing all my best to finish it as soon as I can, because I am in desperate need of some time for myself. It's not only the University, is that I also work on the afternoon / evening 5 days each week, so I am under great pressure when the exams are near.

I think I'll continue until july or so in this situation. After that, some sunny days will come to feel happier, and to think about my projects. Have some ideas that I would like to develop in the near future, and I definitely love this so much to stop doing it!

Best wishes to Viper and his new teammate.


Opcode(Posted 2005) [#69]
Hi guys,

glad to hear that work on the wrapper will continue.

If anyone has any questions or suggestions, please feel free to post them here.


I have a suggestion/request..i would like to see a simple(slimmed down) demo using the wrapper with a player character...(doesn't need to be anything complex, perhaps even a cube as a player character) showing physics with a few .b3d meshes.

I have not succeeded in getting this 'type' of demo working properly. What i would like to see would be something simple (for a similar style game such as max payne..i.e not a car game) where the player character can knock a few crates/objects around etc.

As said, doesn't need to be anything complex.:)

best,
Lee.


Caff(Posted 2005) [#70]
All the best Jedive, good luck and hope you get where you want to go in life!

At the same time, thanks to VIP3R and mystery partner for continuing development on this.

Is Kurix helping you? I noticed a screenshot in the gallery that seems to suggest he's working on a visual ODE editor, which is a GREAT idea. One of the biggest problems I find with ODE is gaining an understanding the effect of the variables and tweaking the positions of mass and so on. Visually it would be much more tactile and hence easier to create realistic physical response.

[edit] whoops - totally missed the Kurix ODE editor thread :) [/edit]


KuRiX(Posted 2005) [#71]
I am not in the JV-ODE project, i am working on my own. Anyway Vip3R has helped all us with his posts and his works (Thanks Viper!).

The Editor is almost finished, but do not uses the jv-ode wrapper. I have made my own wrapper based on the original Arkon's concept, easier to the novice user.

Cheers, KuRi.


VIP3R(Posted 2005) [#72]
Thanks fellas :)

@Opcode: Have you tried PsychicParrots demo, it sounds almost exactly like what you are looking for :)

Here it is...



If this isn't quite what you needed, let me know and I'll try to help you out ;)


Opcode(Posted 2005) [#73]
Thanks VIP3R, i have just looked at PsychicParrots demo...though i get some strange results when running it.

The controls (forwards/backwards) freeze unless i press one of the movement keys as soon as the cube is on the ground.

If this isn't quite what you needed, let me know and I'll try to help you out ;)


To be honest, its not really what i'm looking for, if you could help out with a simple demo, that would be great :)

Cheers,
Lee.

Blitz-Backdrop
IndeED Free IDE


VIP3R(Posted 2005) [#74]

The controls (forwards/backwards) freeze unless i press one of the movement keys as soon as the cube is on the ground.


Ah, that's because PP left the auto-disable for the sphere switched on ;)

To fix that, comment out the following line of the AddObject() function or change the '1' to a '0'...
dBodySetAutoDisableFlag(ode\body,1)

I'll try my best to help you Lee, I need some specific details of exactly what you need first though. How does PP's demo differ from what you're after?... things like that will really help, or if you have any existing code that will help too. Feel free to email me the details (address in profile)


Opcode(Posted 2005) [#75]
Thanks VIP3R, just sent you an e-mail a couple of minutes ago.

Cheers,
Lee.

Blitz-Backdrop
IndeED Free IDE


VIP3R(Posted 2005) [#76]
Cheers Lee, I've just received it. Let me take a look and I'll get back to you as soon as I can ;)


Damien Sturdy(Posted 2005) [#77]
Sah...weeeeet :D


Ricky Smith(Posted 2005) [#78]
Anyone successfully used an AMotor joint to constrain a ball joint ?
Is there a list anywhere of what joint parameters are valid for each joint type. The documentation lists all the parameters but does not mention which ones are valid for which joint type. An invalid joint parameter seems to be just ignored.
Where is the best place to post questions - the forum on the Player Factory seems a bit dead.
Thanks in advance.


VIP3R(Posted 2005) [#79]
Hi Smiff,

Here is probably the best place to ask, like you say the Player Factory threads seem a bit quiet (well that's an understatement) ;)

I don't think there's a list detailing the parameters based on each joint type, but I'll see if I can find more info for you. I do know that any unused parameters are just ignored like you pointed out. Also, any parameters you don't specify a value for will use the default parameters.

One thing you could try is using the following function to return each default parameter...
dJointGetAMotorParam(joint,param)
...this may provide you with an idea of which parameters are applicable.

If I find any more info, I'll let you know ;)


Ricky Smith(Posted 2005) [#80]
Many Thanks - Good idea - I'll give it a try - Nice work on the wrapper by the way .


Wayne(Posted 2005) [#81]
I notice Kurix has ODE trimesh and primitives working just fine.


VIP3R(Posted 2005) [#82]
TRIMESH PROBLEM FINALLY IDENTIFIED!

No wonder I couldn't fix it, I was looking in the wrong place. I was convinced it was related to the collision routines, but it's actually to do with the TriMesh creation itself, doh!

I can see where the problem lies now, so hopefully I should have a fix real soon.

I'm really sorry this has taken so long :(

PS. I feel like an idiot, somebody please shoot me :)


Mustang(Posted 2005) [#83]

PS. I feel like an idiot, somebody please shoot me :)



Okay, now where did I left my M41A pulse rifle... seriously, good job! Thanks for fixing it - I'm sure you will get loads of "thank you"s very soon. :)


Alienforce(Posted 2005) [#84]
COOL!!! VIP3R!!!!!!!!!!!!

When can we have the new files!!! Sooooooon please!!!!!

:)

/Alienforce


VIP3R(Posted 2005) [#85]
Once I've rebuilt the TriMesh construction code and tested it, within days all being well :)

The test code is currently working with spheres, cubes and capped cylinders on a simple quad. (Normal cylinders don't work, but they don't work in ODE itself either)

The fact that the spheres worked flawlessy is what threw me off, they shouldn't have been working either. But the collisions are less complex for those so that's probably why.


Wayne(Posted 2005) [#86]
Great news bro!

I got some great stuff to build.


Shifty Geezer(Posted 2005) [#87]
So is this problem with ODE then? If not, what about all those on the ODE forum saying they can't get it to work? I thought this was an official bug of ODE and not the wrapper!?

Anyway, very good news it's fixed.


Alienforce(Posted 2005) [#88]
VIP3R- Is there any plans for a ODE editor ? :)

/Alienforce


VIP3R(Posted 2005) [#89]
It doesn't look like a problem in the wrapper itself, but it's difficult to say for sure as I haven't managed to find a fix for the problem yet. Now that I can see where things are going wrong I'm confident I'll be able to sort it out though.

I can create a TriMesh that is one quad high and of any width, which works perfectly. The problem occurs immediately when you define the second line of quads, and gets worse for each line of quads added.

Imagine you have 9 quads in a mesh laid out as below:

12345678
9

The TriMesh works fine if you only define quads 1-8, but as soon as you define the first triangle of quad 9, the collision geometry of the TriMesh deforms. What you end up with is quads 2-8 still working correctly, but the top half of quad 1 and the bottom half of quad 9 fail. It's almost like instead of having quads 1 and 9, you have one quad halfway between the two.

The above scenario only affects cubes and capped cylinders, spheres are still able to work for some strange reason. It's very odd!

@Alienforce: I'm not sure yet tbh, the thing I don't like about editors is they produce code which you could find difficult to integrate into a project. I thought an editor would be an ideal little project for you fellas, weren't you working on one Wayne? Anyway, I need to get these issues fixed beforehand, maybe I'll think about it more when I've done those.

I'll keep you all updated of any developments :)


VIP3R(Posted 2005) [#90]
Ok, another news snippet...

The TriMesh vertice and indice data is definitely misaligned on each new line of quads, once I've got an algorithm worked out to re-align them it should be a simple job to correct it.

More soon ;)


Damien Sturdy(Posted 2005) [#91]
woOOOOOOT!


Shifty Geezer(Posted 2005) [#92]
For an editor, ideally you could just output a script of objects that a parser can load into Blitz and apply JV-ODE functions to build the scene. I thought the ODEEd could do this (custom output modes) but as the program's uselessly bugged I never really got to look at it!


Wayne(Posted 2005) [#93]
VIP3R,
What are max contacts set at ?


JaviCervera(Posted 2005) [#94]
128 by default, but you can change it with dContactSetMaxContacts(max).


VIP3R(Posted 2005) [#95]
Yep, what Jedive said.

Cheers Jedive, good to see you :)

Oh well, back to the TriMesh debugging...


Wayne(Posted 2005) [#96]
Vip3r said, "It doesn't look like a problem in the wrapper itself, but it's difficult to say for sure as I haven't managed to find a fix for the problem yet. Now that I can see where things are going wrong I'm confident I'll be able to sort it out though.

I can create a TriMesh that is one quad high and of any width, which works perfectly. The problem occurs immediately when you define the second line of quads, and gets worse for each line of quads added.

Imagine you have 9 quads in a mesh laid out as below:"

12345678
9

Does that mean you could make the mesh like a snake and continuous and it would work ?
12345678
gfedcba9
hijklmno


VIP3R(Posted 2005) [#97]
I'm glad to see you've got your thinking cap on Wayne ;)

No, it wouldn't work like that either I'm afraid.

If you have the following sequence of quads...

12345678
_______9

_ = no quad

Quads 1 to 7 would work correctly, but the top half of quad 8 and the bottom of quad 9 would fail (except with spheres).

Any quad you define on the second row, will affect the quad directly above it in the first row, regardless of the order they're in.

Good suggestion though, keep 'em coming :)


Wayne(Posted 2005) [#98]
What about this ?

10.5.1. Category and Collide Bitfields
Each geom has a ``category'' and ``collide'' bitfield that can be used to assist the space algorithms in determining which geoms should interact and which should not. Use of this feature is optional - by default geoms are considered to be capable of colliding with any other geom.

Each bit position in the bitfield represents a different category of object. The actual meaning of these categories (if any) is user defined. The category bitfield indicates which categories a geom is a member of. The collide bitfield indicates which categories the geom will collide with during collision detection.

A pair of geoms will be considered by dSpaceCollide and dSpaceCollide2 for passing to the callback only if one of them has a collide bit set that corresponds to a category bit in the other. The exact test is as follows:

// test if geom o1 and geom o2 can collide
cat1 = dGeomGetCategoryBits (o1);
cat2 = dGeomGetCategoryBits (o2);
col1 = dGeomGetCollideBits (o1);
col2 = dGeomGetCollideBits (o2);
if ((cat1 & col2) || (cat2 & col1)) {
// call the callback with o1 and o2
}
else {
// do nothing, o1 and o2 do not collide
}

Note that only dSpaceCollide and dSpaceCollide2 use these bitfields, they are ignored by dCollide.

Typically a geom will belong only to a single category, so only one bit will be set in the category bitfield. The bitfields are guaranteed to be at least 32 bits wide, so the user is able to specify an arbitrary pattern of interactions for up to 32 objects. If there are more than 32 objects then some of them will obviously have to have the same category.

Sometimes the category field will contain multiple bits set, e.g. if the geom is a space them you may want to set the category to the union of all the geom categories that are contained.


VIP3R(Posted 2005) [#99]
Thanks for the suggestion Wayne :)

I'm not sure it will be necessary because...

I *might* have just cracked it!!!

I've just had spheres, cubes and cylinders colliding correctly with a mesh using a new concept of defining the TriMesh.

I'm pretty sure this is for real, so begin to get excited :)

More tests are needed, I'm going to try and apply the new method to the Trimesh car demo and see if I can get it to work with that. If that works then it's party time.

PS. Woot!


Wayne(Posted 2005) [#100]
Woohoo ! thats the best news I've heard all day! I'm getting my party stuff ready now.. The good side to all this is you always learn more when you make mistakes.

8)

I'm trying out different physics editors and coming up with some concepts for a new one.

I like your clean coding style by the way, and really appreciate how close the wrapper stays true to ODE documentation.

Thanks for the effort.


VIP3R(Posted 2005) [#101]
Cheers mate, I find untidy code is too confusing :)

The odd thing is, the wrapper doesn't seem to be at fault, something else is causing this problem. Maybe the compiler? It wouldn't surprise me, I really hate C++.

I've also wrapped the full TriMesh build function that was giving MAV's before. It doesn't seem to give any benefits to the simple function though.

The full dGeomTriMeshDataBuild() function in the docs is obsolete now, I'm not sure when it was dropped but it looks like they've forgot to update them.

The new ones are dGeomTriMeshDataBuildSingle() and dGeomTriMeshDataBuildSingle1(). I've only wrapped the first one for now.

Anyway, I'd better get back to the grindstone...


Shifty Geezer(Posted 2005) [#102]
Are there any demos with varying friction and restitution per object?

As I understand it, responses need to be created per collision, determning which objects have collided and creating the approproate response, unlike Tokamak where the engine has inbuilt friction and restitution. Collisions create joints, and one has to manual create responses, right? Wayne's old Sphere's Demo applies forces based on joints, but changing restitution doesn't create a bounce response.

Looking at the demos with JV-ODE I've been able to make the objects bouncy say, but haven't found how to create different materials like 'Ice' and 'Rubber' to apply to individual ojects.

Are there any such demos?

IS there anywhere describing JV-ODE's unique functions too, like dContactSetBounce()? Where can I read what this does and how to use it? It's not in the ODE .pdf.


Damien Sturdy(Posted 2005) [#103]
C'mon matie :D I cant wait for the trimesh to be fixed... Its causing hell :)


VIP3R(Posted 2005) [#104]

Are there any demos with varying friction and restitution per object?


Not yet, but if you tell me exactly what you need I'll try to put one together for you.


As I understand it, responses need to be created per collision, determning which objects have collided and creating the approproate response, unlike Tokamak where the engine has inbuilt friction and restitution. Collisions create joints, and one has to manual create responses, right?


ODE determines which geoms have collided during each time step, a contact joint is then applied to create the appropriate response. This is done automatically within the wrapper so you don't need to create a manual response. The process takes into account all contact settings like friction on each individual geom that has collided.


Looking at the demos with JV-ODE I've been able to make the objects bouncy say, but haven't found how to create different materials like 'Ice' and 'Rubber' to apply to individual ojects.


It sounds like you're setting the global (or world) contact settings. JV-ODE allows you to set these contacts for each individual geom. For example, if you have 20 spheres, you can set 1 sphere to be bouncy and the other 19 to not bounce if you wish. You can set these using the Geom Contact Functions - see the ode.decls file for the list of functions.


IS there anywhere describing JV-ODE's unique functions too, like dContactSetBounce()? Where can I read what this does and how to use it? It's not in the ODE .pdf.


Those functions allow you to manually set the default contact joint surface parameters used in the internal wrapper collision routines I mentioned above. They are described in section 7.3.7 of the PDF manual. For example, dContactSetBounce() would be used to set the default dContactBounce parameter of the contact joints.

@Cygnus: I'm doing my very best :) I would advise you sphere wrap stuff instead as the original ODE TriMesh doesn't handle cube and ccylinder collisions very well at all. They're also very slow in comparision. What do you need them working for, is it the car bodies when they overturn etc? If so, you'll find sphere wrapping the car body is the fastest solution. Let me know if you need any help with this :)


Wayne(Posted 2005) [#105]
VIP3R,

I found this article that may solve the trimesh collision problem.

http://www.delta3d.org/forum/print.php?id=741&forum=14


Wayne(Posted 2005) [#106]
Shifty Geezer,
As soon as the trimesh is resolved I'll knock up a snowboard demo and have it react against the textures it goes over.

I'm thinking Snow, Ice, water, grass , dirt, pavement.

8)


VIP3R(Posted 2005) [#107]
Cheers for the article Wayne, I've read it and from what I understand they couldn't get collisions on a TriMesh at all because the TriMesh was being created at a completely different location in the world space. It was due to the mesh vertices information being misinterpreted by the ODE build process. I don't think that's applicable here because our TriMesh is located correctly, hence the spheres colliding properly. But I'll look into it anyway, thanks ;)

Did you try the TriMesh test demo I sent you btw?

It showed cubes, ccylinders and spheres all colliding correctly with the multiple TriMesh strips. The TriMesh used in that demo was made up of 4 vertices for every 2 triangles, whereas the terrain.b3d mesh included with JV-ODE has 6 vertices for every 2 triangles. If you change the CreateTriMesh function for the one included in the TriMesh car demo, you'll see the deformation of the collision areas which oddly don't affect the spheres.


Wayne(Posted 2005) [#108]
I just realized I've only got version 1.0 here at work, maybe if you get a few min you can send me out version 1.01. I look forward to checking it out.

So your saying this new test does 4 vertices for every 2 triangles to form a quad. Each new quad is arranged like a checker board to form the mesh ?


VIP3R(Posted 2005) [#109]
No problem, I'll send it for you shortly.

[edit] Ok, sent - check your inbox ;)

Yep, the test doesn't load a mesh, I've created one manually using 4 verts and 2 tris for each quad, then each quad is assembled like a checker board. This was to test if different mesh formats were affecting the TriMesh build process.

Give the test a whirl and let me know your thoughts on it :)


Wayne(Posted 2005) [#110]
Would your routine be happy with 31 x 31 verts connected with triangles to form 32x32 quads. One would make multiple meshes like that for ode to form the landscape mesh. They would fit nicely into bounding boxes. Blitz3d meshes would be the same except each quad would have it's own four verts instead of sharing ( makes uv tile mapping easier ).

On a different note it drives me crazy that the other ODE wrapper appears to handle trimesh.

I know Mark has looked at ODE, and possibley BMAX will incorporate ODE. I wonder if any of these other experts would share their secrets.

* maybe when they say triangle soup they mean alphabet soup


VIP3R(Posted 2005) [#111]

Would your routine be happy with 31 x 31 verts connected with triangles to form 32x32 quads.


I'm not sure, you should be able to try it out by modifying the test I sent over. Create the mesh how you described, then work out the verts and tris for each strip and add the info to the CreateTriMesh function (vcount/tcount and vertrows).

I've compared the JV-ODE TriMesh source to the KODE TriMesh source (which KuRiX kindly supplied) but they're almost identical which means the problem must lie elsewhere. The only major difference I can see is the compiler used to make the dll.


Wayne(Posted 2005) [#112]
I get dgeomcountcollisions not found


VIP3R(Posted 2005) [#113]
Did you replace the ode.decls in the Blitz3D userlib folder?


Wayne(Posted 2005) [#114]
I got the right decls in there now, off testing.


Shifty Geezer(Posted 2005) [#115]
Well, the good news is I've sussed out how this engine works in the main. I can even create different masses for objects. Things I can't figure out...

1. Per object friction/restitution. I've used dGeomSetContactBounce() at object creation but it seems to make no difference

2. Centering COG. Best I can tell COG is placed in the corner of a cube (0,0,0), not the centre (x/2, y/2, z/2). There's a matric thing to define COG position, but it has interia values as well. What do these mean?

3. How does Mu and Restitution work? From college maths Mu is a frictional coeffecient ranging from 0.0 to 1.0 representating amount of energy lost, and likewise Restitution. Restitution seems to work right, but Mu doesn't, needing a value of 10.0 to get something reasonable once I add a bit of mass.

Also how do the different contact modes work (dContactBounce, dContactSlip1), the use of the functions dSetContactMotion1/2(), and what's the difference between Mu1, Mu2 etc. Why are there two versions of each function?

Anyway, I'll attached my test program here. What I'm hoping for (a system I used with Tokamak) is a definition of materials in a material type. I can create say ice=New Material and set it's properties for density, friction and restitution, and then whenever I create an object I can apply these settings to it.




Damien Sturdy(Posted 2005) [#116]

is it the car bodies when they overturn etc



Nope, but spherewrapping would be excelent. WOuld it be as simple as adding spheres to the car body mesh at each relative corner, kind of forming a convex err.... thingy?... hull?

Thats how i'll do it i think. With the original ODE i managed to have a single sphere, ONE, to do every roof colision for every car, by repositioning it and using tformpoint to add the resultant force to the actual car body.

Pain in deh arse. hehe :)


actually i recon spherewrapping would be the way forward for me anyway. thabnks :D


KuRiX(Posted 2005) [#117]
hey Viper. While making some tests i have noticed that if the CCYLinder is on a different space than trimesh they do not collide properly, although spheres do.

Be sure to have all the geoms in the same space in your tests.


VIP3R(Posted 2005) [#118]
@Shifty Geezer: Hmm, you need to study the docs a little more me thinks ;)

1) It works ok, but you do need to use it correctly. Bounce restitution ranges from 0.0=no bounce to 1.0=max bounce. You have it set at 100 :S - look at section 7.3.7 of the docs for more info on the contact settings.

2) No, unless I'm mistaken the point of reference for the center of gravity is at the center of the geometry (0,0,0) not the corner. Check sections 9.2 and 10.7.1 of the docs for more info.

3) Yep, Mu is the coulomb friction coefficient but it ranges from 0.0=no friction to Infinity=max friction - not 0.0 to 1.0 - again check section 7.3.7 of the docs for more info.

Mu and Mu2, Slip1 and Slip2 etc represent two different contact directions if needed. Normally you only need one direction Mu, Slip1 etc. Yep, you guessed it, check section 7.3.7 of the docs for more info ;)

One more thing, you have the gravity set at -3, this is over 3 times the value of 'real' gravity. The real gravity setting would be -0.98 (rounded up).

Download the docs and have a good read, most of the answers you'll need can be found in there and it'll all make much more sense then. If you have any more questions please let me know, I'll be glad to help :)

@Cygnus: Yep, simply adding spheres where ever you need collision responses for the TriMesh on the car body would work fine. With those minis, you could probably create a large sphere in the center of the car, then one sphere on each corner.

The beauty of sphere wrapping is the level of control you have for speed vs collision resolution. Whereas standard TriMesh>cube responses can be overkill for most situations.

Also, there is another major advantage... the cars won't accidently 'snag' on the terrain, whereas cube>TriMesh collisions are prone to this problem.

Check up there ^^^ for the sphere-wrapping demos ;)


VIP3R(Posted 2005) [#119]
@KuRiX: Oh, crumbs... that could well be the problem, I'll look into it right away. Thanks very much for the suggestion, you're a diamond :)


Wayne(Posted 2005) [#120]
We using op code tri collider ?

http://q12.org/cgi-bin/wiki.pl?TriangleCollider


Wayne(Posted 2005) [#121]
VIP3R can we get dterrain in the oed dll and wrapper ?

Reply Quoting This MessageEdit Message NoahAdler Member since: 4/22/2000 From: Lexington, United States
Posted - 2/11/2005 10:30:58 PM

For heightmapped terrains, ODE also offers a collider named dTerrain which essentially builds a terrain by using rays at the given point to push an object up. I've used this collider with great success, though some people prefer to use the trimesh for various reasons. This collider is offered in the 'contrib' directory of the ODE repository, and requires some (very slight) manually patching of the source.

//www.gamedev.net/community/forums/topic.asp?topic_id=300188


Damien Sturdy(Posted 2005) [#122]
Sweet. I dont think i need to kep 48 cars running so fast, so this may work :)


Thanks,


Shifty Geezer(Posted 2005) [#123]
@VIP3R: Well, reading the docs isn't always good. For example, you tell me

"One more thing, you have the gravity set at -3, this is over 3 times the value of 'real' gravity. The real gravity setting would be -0.98 (rounded up)."

But the docs say "Set and get the world’s global gravity vector. The units are m/s/s, so Earth’s gravity vector would be (0,0,-9.81), assuming that +z is up. The default is no gravity, i.e. (0,0,0)."

I tried the manual's suggestion (0,-9,81,0) and it was too much, so just experimented to find something that looked right. Hence the manual was no help :D

Seriously though, I did read the docs, but before I had the full JV-ODE, so I haven't worked through it and need to take another look. A lot of stuff I thought it didn't have as it's not in the index (dContactBounce for example) but I see it's just buried in all the techno mumbo-jumbo and I'll work through it again.

There were some explerimental figures in my example so just ignore things like bounce=100!

For the Mass COG, I didn't understand the manual's definition exactly. I thought (cuboid) volumes start at (0,0,0) and end at (x,y,z), hence thought the COG was in the top corner. On closer inspection it suggests the COG is cetered at the centre of the body it's applied to.

Regards friction I think my maths was just too rusty to remember the limits ;)

"Normally you only need one direction Mu, Slip1 etc. Yep, you guessed it, check section 7.3.7 of the docs for more info ;)"

Thanks for the pointer. It seems Bounce includes friction responses too, as using just specifying dContactBounce for the world, Mu value still affects object sliding, so there's no need to specify Slip and Bounce contact types.

"If you have any more questions please let me know, I'll be glad to help :)"

A little experimenting and I see I can use dGeomContactSetBounce() and dGeomContactSetMu() AFTER calling dSpaceCollide(). I guess that creates the contacts and then one sets the properties for them. Presumably then to apply per object properties, one needs to sort through the contacts created from the dSpaceCollide() function. Won't this require considering both colliding surfaces' properties? And how does one differentiate between each contact?

I'm kinda talking here. I'll get back to my investigations, though if anyone has any pointers to make my life easiers, I wouldn't grumble!


VIP3R(Posted 2005) [#124]
@Wayne: Yep, we're using opcode tri collider. I'm not very comfortable with using dTerrain as it requires hacking part of the lib to get it working. I think it would be better to use the opcode tri collider (TriMesh), as hacking the lib may cause all sorts of collision problems elsewhere.

@Shifty Geezer: Apologies, it does say -9.81 in the docs. I found it was better to divide the gravity by 10 (-0.981) and multiply the mass by 10. This made the simulation more stable for me (less twitchy). You should be able to use dGeomContactSetBounce() etc at the point of creating the geom rather than after the dSpaceCollide function. The geom contact settings are averaged with the global world contact settings in the dSpaceCollide function. So both surface properties are considered within the function. ( i.e. SurfaceProperty=GeomContact+GlobalWorldContact/2 ) I would have had some demos showing this but most of my time has been used to address the TriMesh issues. I've also got plans to build some detailed collision demos too.

@KuRiX: Hmm, it looks like the TriMesh is created in the correct space, so that doesn't appear to be the problem either. I'll continue investigating though ;)


Shifty Geezer(Posted 2005) [#125]
"@Shifty Geezer: You should be able to use dGeomContactSetBounce() etc at the point of creating the geom rather than after the dSpaceCollide function."

Okay. Having tried this I've got no results. I'll just wait 'til one of the boffs (you or Wayne et al) tackles the issue and shows me where I'm going wrong ;)


VIP3R(Posted 2005) [#126]
The reason you seem to get results from adding it after the dSpaceCollide function is because you're actually changing the ramp geom bounce (as it was the last geom created in your code). Try adding dGeomContactSetBounce(obj\geom,1) immediately after creating the ramp geom in your code and you'll see what I mean.

Try experimenting with the Demo-Rope.bb included with the wrapper and insert 'dGeomContactSetBounce(ode\geom,bounce)' into the AddObject() function using different values for the bounce (0.0 to 1.0) to see it working correctly.


Shifty Geezer(Posted 2005) [#127]
At first I tried the dGeomSetContactBounce() after geom creation as you suggested and it had no effect - hence my confusion. But more experimentation has shown it works as it should EXCEPT on a plane - dCreatePlane(ODE_space,0,1,0,0).

Setting per object bounce to 1.0 has no bouncing when they land on a plane. Whereas global Bounce affect everything including plane. Which is where I couldn't fathom it as my tests were dropping objects onto a plane!

I've just found that rather than calling dCreatePlane(ODE_space,0,1,0,0) as it's used in the JV-ODE demos, I should assign it's results to a variable and I can handle it's geometry, so

ground_geom = dCreatePlane(ODE_space,0,1,0,0).
dGeomSetContactBounce(ground_geom, restituion) works.

Woohoo!


KuRiX(Posted 2005) [#128]
Ask Viper what the wrapper does when you set the bounce for 2 geoms that collide.Which one uses?


VIP3R(Posted 2005) [#129]
@Shifty Geezer: I had no idea you meant the plane, your test above drops boxes onto another box instead of the plane... hence my confusion too :)

As you've discovered you can treat the plane just like any other static geom. Anyway, glad you've got it working how you wanted now ;) Take note of the following though...

@KuRiX: Well, it *should* be using an average of both like this...
totalbounce = geom1bounce + geom2bounce / 2

BUT... there is a bug in the wrapper which I've spotted. V1.01 is doing this...
totalbounce = geom2bounce + geom2bounce / 2

Bah, nice one Jedive ;) (hehe only kidding)

It's already on my todo so expect it to be fixed in V1.02.


Wayne(Posted 2005) [#130]
you mean: totalbounce = (geom1bounce + geom2bounce) / 2


VIP3R(Posted 2005) [#131]
Yes, I was talking in english not code...lol ;)


Alienforce(Posted 2005) [#132]
How far away are vs 1.02 ?

/Alienforce


VIP3R(Posted 2005) [#133]
Well, it has all been dependent on the TriMesh progress, but I'm having severe difficulties getting that problem resolved. I can't recompile the very latest CVS ODE source in Dev-C++, so that's giving me a real headache. So much in fact that I'm currently trying to rewrite the wrapper using VC++ instead which itself is a daunting task.

I need to do a few more experiments with the VC++ compiler first, but if it looks like the TriMesh (rebuild) could take a while I'm going to release V1.02 either at the end of next week or very soon after. The new update will contain a fix for the contacts bug mentioned above and I'll try and get some new demos in there too, like a detailed collisions demo. I'm going to look at the cylinder alignment problem too (in the known issues ^^).


Alienforce(Posted 2005) [#134]
Cool, Thanks for the info.

/Alienforce


Wayne(Posted 2005) [#135]
Maybe Kurix or Mark could compile it for you ?

lol

sorry, I know it must be flustrating.


KuRiX(Posted 2005) [#136]
I can send the latest csv ode .lib compiled to Viper. Do you want it? Send an email if so Viper! It is only 1.2MB


Wayne(Posted 2005) [#137]
Hey ViP3r,
Any chance you caould try making a demo using multiple spaces? I keep getting MAV's when stuff collides and I'm using spaces.

Thanks


VIP3R(Posted 2005) [#138]
@Wayne: The only way the lastest CVS stuff will compile properly with Dev-C++ is to hack the new ode lib files to make them compatible with the compiler. Mingw simply will not compile the new code, try it yourself if you like ;) - (KuRiX uses VC++ btw not Dev-C++)

I'll try to make a multiple space demo, no promises though.

@KuRiX: Thanks mate, I'll email you later :)


KuRiX(Posted 2005) [#139]
Multiple Space has sense if the callback is properly made. For example, the docs say that a good example is to have each car in one space. Suppose one car composed of the chassis (a box) and 4 wheels (spheres) joined with hinge2.

In the callback function normally there is a rule that if two bodies are joined by a joint then no collision is made. But, the wheels are not joined directly, so collision between wheels of the same car are checked (or at least its bounding boxes)!.

Then, you can put every car in a space, and that spaces into a parent space. Then in the callback check for collision between objects of different spaces. This creates a bounding box for every space, not checking for collisions if the bounding boxes are not near enough.

Anyway, the callback will check then for collisions in the same space, so the wheels will check collisions for the same car. In my racing game i have changed the collision callback, so objects in the same space are not checked. Although usually this is not a good idea.

So, in a general idea:

You create the main space.
SPACE = dHashSpaceCreate(0)

Then you create a subspace for every car (suppose 2):
space1 = dHashSpaceCreate(SPACE)
space2 = dHashSpaceCreate(SPACE)

Then:
CreateCar(1,space1)
CreateCar(2,space2)

And in the main loop:
dSpaceCollide(SPACE,world)
dWorldQuickStep(step)
etc...

But in this case the collision callback should be like:
void nearcallback(geom o1,geom o2, data)

if (dGeomisSpace(o1) || dGeomisSpace(o2))
dSpaceCollide2(o1,o2);
if (dGeomiSSpace(o1)) dSpaceCollide(o1);
if (dGeomiSSpace(o2)) dSpaceCollide(o2);
else
{
// GENERATE CONTACT FOR o1 and o2
}

Ok?


VIP3R(Posted 2005) [#140]
Cheers for the info KuRiX, I'll have to check the wrapper source and see what it's doing (Jedive coded the multiple space stuff).

I'll be away from the computer from later today until Sunday 19th, so I'll get straight back onto it then. See you later all :)


Wayne(Posted 2005) [#141]
Thanks Kurix,
The code I used looked alot like what you posted above, but I used cubes instead of cars. I was getting a MAV when the collisions happened. I'll post the code a bit later ( it's on a different machine ).

VIP3R, I'm not a pro C programmer or I'd offer to help. I can read and write some C code. I'll leave the C code to you guys, unless you want me to look at the source.


Shifty Geezer(Posted 2005) [#142]
Hmmm, I'm finding adding masses to objects problematic the moment cylinders are involved. I can create cubes with masses that work okay, and shere with masses that work okay, but cylinders do funny things. I can either have them colliding and falling okay, but bouncing like super-bouncy rubber, or they land more realistically but don't roll off the edge so much as 'drop off', floating in mid air until all of the cylinder is over the edge fo the object defore dropping.

Trying to recreate the problem in a simpler application is tricky - it shows some of these bugs but they're very intermittent, and I don't get the same suprt-bouncy objects (which I get even with every restitution set to zero)

Has anyone else had problems with cylinders?


Rhyolite(Posted 2005) [#143]
Try making the cylinders body into a sphere, but keep the collision geom as a cylinder. Also, do not use excessively different masses between joined bodies (eg. use 0.1 and 1.0 or 1 and 10 at most).

Maybe one of those helps,
Rhy :)


Shifty Geezer(Posted 2005) [#144]
I haven't got any joined bodies (apart from contant joints, if that counts too?). I've read about the mass limitation suggestion though it doesn't seem to affect cubes/spheres. I've got different materials with different properties and objects of different sizes, and a large Gold block is going to weight a hell of a lot more than 10x a small wodden cube!! Do cylinders have a peculiar limitation?

Another unrelated point - How do you balance the settings between different platforms? On a 500 MHz K6 I used

. dWorldSetGravity(ODE_world,0,-2,0)
. dWorldSetERP(ODE_world,0.2)
. dWorldSetCFM(ODE_world,0.0000001)
. dWorldQuickStep(ODE_world,0.50)

with good results, but those same settings on my development PC (AthlonXP 2500) are insanely quick and the physics objects just pass straight through without colliding. Changing to...

. dWorldQuickStep(ODE_world,0.015)

Works okay, but how can you set the ODE update speed according to system specs? Note I'm using tweened rendering...

For k=1 To ticks
		time=time+PERIOD
		If k=ticks Then
			CaptureWorld

			For ode.ODE_object=Each ODE_object
				If ode\body
					If dBodyIsEnabled(ode\body)
						RotateEntity ode\mesh,dGeomGetPitch#(ode\geom),dGeomGetYaw#(ode\geom),dGeomGetRoll#(ode\geom)
						PositionEntity ode\mesh,dGeomGetPositionX#(ode\geom),dGeomGetPositionY#(ode\geom),dGeomGetPositionZ#(ode\geom)
					End If
				End If
			Next
		EndIf
	
	Next

Limiting the refresh rate to screen updates, I need to increase QuickStep timestep to get the same speed of objects, but that loses accuracy.


Rhyolite(Posted 2005) [#145]
The shape of a physics body only effects mass distribution, so try changing your cylinder body to a sphere which is far more stable. You still keep your geom and mesh as a cylinder, so collides and looks the same and I bet you wont even notice the different body ;)

You need to use a fixed update rate, which should be independant to your screen refresh rate (ie. similar to delta timing or render tweening).

Rhy :)


Shifty Geezer(Posted 2005) [#146]
Smart thinking Rhyolite! That fixes the trouble with Cylinders passing through my shelf. They still bounce crazily though.

On more testing, using

. dMassSetCylinder(v,obj\mat\density,X, radius,length)

where X = 0 causes the cylinders to pass through the shelf. Using X = 1 solves that. Mass obviously has some impact on collision responses. I think I really need one fo the experts to provide example 'different materials + objects' collision code before I can determine what works and what
doesn't. Just please be sure to add cylinders Wayne/VIP3R/et al!!


VIP3R(Posted 2005) [#147]
Quick Update:

Nearly finished the new update, expect it to be released over the coming weekend sometime.

Fixes in V1.02 (so far)
Geom surface contact bug fixed
Multiple space MAV issue fixed
Userlib function not found issue resolved

New demos...
CarDemo - Detailed Collisions
CarDemo - Multiple Spaces
Demo - Geom Bounce
Demo - Geom Friction
Demo - Sphere Wrapped Capped Cylinders
Demo - Sphere Wrapped Cubes
Demo - Sphere Wrapped Cylinders

More soon... :)


Shifty Geezer(Posted 2005) [#148]
Wayhay!!

How's the evil mesh bug going?


Shifty Geezer(Posted 2005) [#149]
Me again! I'm getting problems with using an external library of functions. I've got an include file with setup functions for ode objects and meshes. I declare global ODE_World, Space and so forth in this file.

In the main program I create the ode world (dWorldCreate() etc). I have an array of objects that when I create them accessing my included functions, they exist. I call my function ODE_Setup(), use 'a#=dGeomGetPositionX#(objects(0)\geom)' and get a value for the first ODE objects X position.

This is fine and dandy until I advance the simulation with dWorld(Quick)Step(). The moment I call this function, 'dGeomGetPositionX#(objects(0)\geom)' = NaN.
'Objects(0)\geom' exists, but it has no position or rotation.

This, unsurprisingly, leaves me confused!


Wayne(Posted 2005) [#150]
Outstanding VIP3R.

Post the troublesome code Shifty.

Trying to decide what physics engine to use makes me crazy.


VIP3R(Posted 2005) [#151]
The 'evil mesh' bug is a <enter expletive> :)

The only two known bugs that remain are:
* The TriMesh cube/ccylinder bug - working on recompiling JV-ODE using the latest stable CVS releases, hopefully this will cure the problem.
* The capped cylinder alignment bug - haven't found a decent way to correct this from within the wrapper yet. Although it's very easily fixed from within the Blitz code using...
RotateMesh ode\mesh,90,0,0

Both of these bugs appear to be within the ODE source code somewhere, I've seen nothing wrong in the wrapper source code itself.

I'm going to release V1.02 before tackling these two bugs as I have no idea how long it will take to nail 'em. I trust you folks are ok with that?

I'll post as soon as it's ready ;)


Shifty Geezer(Posted 2005) [#152]
EDIT : Code deleted.

All my fault! I was using code copied from the main in the library, that referenced variables x,y,z which hadn't been created/assigned a value. This result in objects of size 0,0,0!


VIP3R(Posted 2005) [#153]
JV-ODE Physics Wrapper - Version 1.02 Released

Check your inbox for details :)

Hope you like it ;)


Damien Sturdy(Posted 2005) [#154]
Whatya got new in 'ere? I cant play with it yet >.<



Gonna make Kurix's editor plug with this.... That should be fun for my newer projects :)


VIP3R(Posted 2005) [#155]
Version 1.02

Fixed geom surface contact issue
Fixed multispace MAV issue
Fixed 'Userlib function not found' issue

Added dRegisterODE() function - the DLL is now registered via the 'JV-ODE.bb' include file
Added dSetInternalSpaceCollideMode(mode) function - enable or disable internal space collisions
Added dGetInternalSpaceCollideMode%() function - get internal collide mode ( 0 = disabled 1 = enabled )
Added dGeomTriMeshDataBuildSingle() function - alternative TriMesh function without normals
Added dGeomTriMeshDataBuildSingle1() function - alternative TriMesh function with normals

Added Demo-GeomBounce - how to setup bounce per geom
Added Demo-GeomFriction - how to setup friction per geom
Added CarDemo-DetailedC - an example of detailed collisions
Added CarDemo-MultipleSpace - an example of multiple spaces
Added CarDemo-SphereWrapCCylinder - capped cylinder to TriMesh collision workaround
Added CarDemo-SphereWrapCube - cube to TriMesh collision workaround
Added CarDemo-SphereWrapCylinder - cylinder to TriMesh collision workaround


Wayne(Posted 2005) [#156]
checking it out


KuRiX(Posted 2005) [#157]
That function... dSetInternalSpaceCollideMode... i have seen it before somewhere... xDD


VIP3R(Posted 2005) [#158]
Yep, my feelings on that function are similar to yours KuRiX ;)

I don't see the need for internal sub-space collisions as well as global space collisions. I could have coded it with internal collisions switched off, but letting the user decide is definitely the best option.


KuRiX(Posted 2005) [#159]
I was only joking :D.

Yes, this is the better way.

How about the trimesh problem? nothing? I see that there are some people in the ode community having problems with ccylinder and box vs trimesh, and they are c++ coders!!! So i think that problem must be in the values of the parameters, not the wrapper.

The other day a friend sent me some .bb code with jv-ode functions to change it to kode + trimesh, and i changed the function names and i needed to change some cfm values to get it properly working...

Well, good luck!


VIP3R(Posted 2005) [#160]
Hehe, I know you were joking :)

I'm still looking at the TriMesh problem, it's possible that the parameters could be affecting the simulation. One way to tell would be to convert a working KODE TriMesh sample to JV-ODE using the same parameters etc.


VIP3R(Posted 2005) [#161]
JV-ODE TRIMESH FIXED!!!

The TriMesh problem has finally been fixed. ODE boxes and capped cylinders now collide PERFECTLY with a TriMesh!

JV-ODE V1.03 coming very soon...

Btw, WOOT!


Alienforce(Posted 2005) [#162]
JIPPI!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Great work Vip3r!!!!!!!!!!!!!!!!!!!!!!!!

/ALienforce


Caff(Posted 2005) [#163]
Excellent news! And yes, have a WOOT on me :)


PsychicParrot(Posted 2005) [#164]
WOOOOOOOT!!!!! :D


Damien Sturdy(Posted 2005) [#165]
YYYAAAAAAAA HOOOOOOOOOOOOOOOOOOOOOOOOOO! :D

Keep up the effort man!


What was the issue?


VIP3R(Posted 2005) [#166]
Cheers fellas :D

JV-ODE Physics Wrapper - Version 1.03 Released

Check your inbox for details :)

Party time!


VIP3R(Posted 2005) [#167]
@Cygnus: I'll reveal all as soon as I've finished updating everything ;)


Shifty Geezer(Posted 2005) [#168]
Fantastic!! Well done indeedy!

BTW How efficient is is TriMesh collision? How much slower is collision with a Tri mesh cube to a normal ODE cube, and how does say a more complex mesh (five sided open box) compare with a collective of primitives (5 ODE Boxes arranged to form the same box)?


Chris C(Posted 2005) [#169]
I have to say well done that was one obscure and nasty bug

cudos to VIP3R !


VIP3R(Posted 2005) [#170]
Ok, the problem wasn't in the wrapper itself. It turned out to be the compiler as I'd suspected, the optimizations performed on the library were corrupting the opcode collision system. It only affects the mingw builds, what a nightmare!

Turns out the CVS builds had nothing to do with it.

I've sweat blood to get this working ;)


If you're updating from V1.00 or V1.01 please note:

* You need to replace the 'ode.decls' file with the new 'JV-ODE.decls' file in the Blitz3D userlibs folder.

* You also need to replace the 'ode.bb' include file with the new 'JV-ODE.bb' include file, then change the includes in your source code to use "JV-ODE.bb" instead of "ode.bb".

* The CreateTriMesh() function is now contained within the 'JV-ODE.bb' include file and has a new space parameter - trimesh=CreateTriMesh(space,mesh)
You will need to remove any old CreateTriMesh() functions from your own source code.

* The new 'JV-ODE.bb' include file contains your registration code. Please keep this file confidential.




VIP3R(Posted 2005) [#171]
@Shifty Geezer: The box to TriMesh collisions should be the same speed as box to box collisions. Same goes for capped cylinders too. With 5 boxes forming an open box, the collisions will take 5x as long as a single box (for best results you should put them in their own space with internal space collide switched off).


Shifty Geezer(Posted 2005) [#172]
Thanks for the heads up. Presumably the ODE community is errupting with joyous chanting now the origin of the bug is known?


Wayne(Posted 2005) [#173]
Erupts with joyous chanting!
Time to Party !!
*Band plays in the background*
*fireworks exploding overhead*

V I P 3 R Y O U D A M A N


VIP3R(Posted 2005) [#174]
I've now managed to optimize the wrapper without any side-effects.

I'll release another update in a few days, with a new smaller dll.

I may also add some 'all-in-one' functions to the include file, things like...
CreateODEBox(space,px#,py#,pz#,rx#,ry#,rz#,sx#,sy#,sz#,mass#)
...that kind of thing. Any suggestions on this?


Caff(Posted 2005) [#175]
I like the sound of all-in-one functions! For the lazy people out there *cough* myself *cough*


Caff(Posted 2005) [#176]
Well, I'm not using trimesh stuff, but I was hoping for a bit of advice.

I've been playing with the basic cubes demo to get the hang of ODE. I noticed that the cubes come to rest very quickly.

But when I change the scale of the cube (to make it flat like a CD case) they don't seem to fully settle, ie. they twitch a bit :)

How can I change it so after hitting the pile, they come to rest? thanks


KuRiX(Posted 2005) [#177]
To avoid non stable boxes on the ground you can make soft surfaces by adjusting cfm and erp in the contact parameters. Try decreasing erp and increasing cfm.

For example:
CFM: 0.01
ERP: 0.4

There are lot of tweaking options in ode, this is only one.

Cheers, KuRi


Shifty Geezer(Posted 2005) [#178]
@ Caff : If you want all in one functions have a look at my tutorial that I posted up on this forum. Includes a .lib for defining materials and objects based on those materials, both mobile bodies and static scenery. eg.

Function create_Box(obj.ODE_object, x_pos#, y_pos#, z_pos#, width#, length#, depth#, x_rot#, y_rot#, z_rot#)


@ VIP3R : Fantastic work! And the more functions, the merrier! My program is built on simple primitives with materials so I created a structure to support that. In my case my ODE_Object type also has a mat.material field for defining what it's made of. This is then really useful for including other things like magnetism. There's several different ways to approach the structure of a simulation and I don't know what the consensus would want. It could be worth dividing different constructor designs into different libraries. Maybe have some basic object construction functions, then have a more detailed system with full material support, and so on?


VIP3R(Posted 2005) [#179]
Hmm, I've had a good think about these 'all-in-one' functions. I'd prefer not to add them to the JV-ODE.bb include file, as this file should never be modified (the 'all-in-one' functions should be user definable really).

It might be a better idea to build a separate include file or for the user to build their own 'all-in-one' functions based on a tutorial for this exact purpose. What do you reckon Shifty Geezer, would you be able to make an 'all-in-one' function tutorial? I can find you some links to real world object properties (mass, bounce, friction etc).

@Caff: If you really need some simple functions like this, I can build you a few no problem. I'm just not sure prebuilt functions like this would be a good idea, it's very easy for the user to build them based on the demo code. Also, for your flat cube problem you can change the properties of each object to suit your needs. Try changing the erp, cfm and bounce properties using the geom contact functions...
dGeomContactSetMode(ode\geom,dContactBounce)
dGeomContactSetBounce(ode\geom,0.0) ; ### 0.0 to 1.0
dGeomContactSetSoftERP(ode\geom,0.0) ; ### 0.0 to 1.0
dGeomContactSetSoftCFM(ode\geom,0.0) ; ### 0.0 to 0.1+
...add them after creating each flat cube.


Shifty Geezer(Posted 2005) [#180]
I'll certainly make available my 'research' as my library develops for my own use. To add are external forces (particularly blowers and magnets), and some simple joint stuff like compound bodies (good old chair example). How efficient the library is...well, I can't rightly say! I keep thinking in terms of rigidly structured programming which I like, but Blitz isn't that rigid, and I get lost with all the globals and the like ;)

I do agree such constructor libraries are best kept seperate from the main ODE lib as they optional extras that don't link directly to features of the ODE system.


Caff(Posted 2005) [#181]
Thanks guys I'll give it a try and see how it looks.


Shifty Geezer(Posted 2005) [#182]
MARGINALLY IMPORTANT NOTICE :

I've just found that though Cubes And Capped Cylinders work with Mesh collision, normal cylinders do not. (Run Car+CCylinder demo but replace all references to 'CCylinder' and 'CappedCylinder' with just 'Cylinder')


Shifty Geezer(Posted 2005) [#183]
Also, CCylinders are rotated 90 degrees on X axis, whereas normal Cylinders aren't.


VIP3R(Posted 2005) [#184]
Normal cylinders don't work with a TriMesh in any version of ODE, to date no-one has succeeded in getting them to work at all.

You need to use capped cylinders for the TriMesh instead.

[edit] The CCylinder 90 degrees on the X-Axis alignment is something which is designed that way in ODE, god knows why? I'll fix it if I can find a decent way of doing it but it's easiest to just rotate the mesh alignment.


Shifty Geezer(Posted 2005) [#185]
Yes, it appears true cylinders aren't fully supported in ODE, which means slight edge overlap for cylinders if using capped ones. Still, better than nothing ;)


VIP3R(Posted 2005) [#186]
You could try cube wrapping the ends of the capped cylinders which would help stop some of the penetration along the edges. Seems like overkill to me but it could be done.


Shifty Geezer(Posted 2005) [#187]
Indeed, Cylinders aren't just not fully supported, they're down right buggy! There's a chance that if they combine end on end, two cylinders will vaporise each other. As example, open the Demo-CCylinders and replace the function AddObject() with
Function AddObject()

xp=Rand(-5,5)
zp=Rand(-5,5)
ode.ODEGeom=New ODEGeom
ode\body=dBodyCreate(World)
dBodySetRotation(ode\body,0,0,0)
dBodySetPosition(ode\body,xp,30,zp)
dBodySetAutoDisableFlag(ode\body,1)
;ode\geom=dCreateCylinder(Space,2,8)		; logs
ode\geom=dCreateCylinder(Space,8,2)		; coins
dGeomSetBody(ode\geom,ode\body)
ode\mesh=CreateCylinder(12)
;ScaleMesh ode\mesh,2,4,2						; logs
ScaleMesh ode\mesh,8,1,8							; coins

End Function

If you run the program with the coins lines enabled, you get a clear view of this behaviour. Comment outs the coins and use the logs instead, and the vaporising cylinders are much less frequent. So only in end-on-end collision is it a problem, but a problem none the less.

Note : I only found this because by chance I tried the new mesh collisions with cylinders and when they didn't work, spent hours today trying to find the problems with my code. Ugh!


slenkar(Posted 2005) [#188]
How do you make cubes stack and NOT fall over, ??


VIP3R(Posted 2005) [#189]
@Shifty Geezer: It's important to remember that the standard 'Cylinder' is not part of the original ODE library but is in fact an addition made by other contributors. This was added to JV-ODE as an extra, but it isn't very stable yet. The reason the cylinders disappear is due to faulty collision contact joints being created which actually send them off flying at high speed (they don't disappear, they just move real fast). There is now a 'Cylinder2' function available too which I shall examine and if stable enough include into the JV-ODE wrapper in the future. Capped Cylinders are the only 'official' ODE cylinder available at the moment. Obviously being relatively new to the library you wouldn't have known this ;)

@Slenkar: Think of it like you would real life, if you try to stack cubes by dropping them from pretty high up, they'll just start rocking and tumble eventually. In reality you would add each cube slightly higher than the one below it and so on. The same applies here, stack each cube carefully. You can of course stack all of them first by setting their positions before calling dWorldQuickStep(). Also, set the cubes contacts up with zero bounce, low to mid 'erp' and mid to high 'cfm' same as I mentioned to Caff about 10 posts up ^^^. If you're still having trouble feel free to let me know and I'll do my best to help ;)


KuRiX(Posted 2005) [#190]
Well, just as Viper says the Cylinder Geom is not natively supported by ODE. There are two contributions for this. The most advanced is in the dcylinder2 of the ode source. This has dCylinder vs Trimesh support, or at least in theory because i have tested it with bad results.

And the dcylinder2 contribution is very hard to include in the original source, because the lack of good explanations on how to do it.

The Viper dll and my dll includes the dcylinder contribution, which is the only that can be used with some geoms with some real use.

You can download the demo for KODE EDITOR and see how the Boxed CCylinder works. They are really great for that purpose. The only limit is that the total length of the final cylinder must be at least of 2*radius of the original ccylinder, so there are come cylinders that cannot be represented, for example wheels.

Cheers, KuRi!


Shifty Geezer(Posted 2005) [#191]
VIP3R : Okay. Seeing it in the official .pdf docs I had no reason to think it wasn't a full component. Is there anywhere a newbie guide to what's really in/not in ODE? ;)

KuRiX : How are your boxed cylinders created, so that some can't be represented? It should technically be quite easy I'd have though.

Edit - of course, using capped cylinders the rounded ends are too big to represent a cylinder of higher radius:length ratio.


VIP3R(Posted 2005) [#192]
No, I've not seen any docs which refer to non-ODE contributions separately.

There is a list of the non-official stuff here:
http://cvs.sourceforge.net/viewcvs.py/opende/ode/contrib

The boxed cylinders KuRiX is talking about is what I was referring to when I mentioned cube wrapping the ends of the cylinders above ^^. You just attach a cube to each end of the cylinder in the exact same manner as shown in the Demo-SphereWrapCylinder.bb file. Just replace the spheres for cubes. The cubes will lie inside the cylinder body with the face of the cube meeting the edge of the cylinder.

This should prevent the faulty contacts generating, but it still won't collide with a TriMesh (apart from just the cubes themselves).

You can adjust the length of the cylinder to accommodate the cubes properly. But you are limited, the cylinder length must be twice as long as the radius.


KuRiX(Posted 2005) [#193]
Hey Viper, i was talking about boxed-ccylinder. So you can make it work with trimeshes too!


slenkar(Posted 2005) [#194]
I tried messing about with all those settings and still could not get it to work, please can you create a small demo? (of a cube stack)
Ive been trying for about 2 hours now


VIP3R(Posted 2005) [#195]
@KuRiX: I think Shifty Geezer wanted to stack normal cylinders end on end without the faulty contacts. You can box both cylinders and capped cylinders, but like you say only capped cylinders will work with a TriMesh. Anyway, thanks for your input on this ;)

@Slenkar: Did you try the Demo-Rope.bb code? This code also shows boxes being stacked. If this demo isn't quite what you wanted, let me know what specific requirements you need and I'll build you a demo to show it, no problem ;)


slenkar(Posted 2005) [#196]
oh, so its best to stack them in real time one-by-one


Shifty Geezer(Posted 2005) [#197]
VIP3R : dGeomContactSet...() don't appear to affect trimeshses. Indeed, neither do global Bounce and Mu values. Have Trimeshes got fixed parameters?


VIP3R(Posted 2005) [#198]
No, they use the global parameters. You must be using them wrong I think, they're working here.

Try this in the TriMesh demos...

dContactSetMode(dContactSlip1+dContactBounce) ; <<< If you want to use bounce you must set the mode to use it

dContactSetBounce(0.95) ; <<< add the global bounce

dContactSetMu(64) ; <<< change the friction in the WorldFriction variable or directly with this

[edit] Btw, I'll create a new JV-ODE thread tomorrow when V1.04 is released, this thread is getting a bit long now ;)


VIP3R(Posted 2005) [#199]
The ODE library has just received some new updates (including the compiler fix I'd mentioned to them) so I'll add these to the V1.04 update too. Providing they're stable of course ;)

Optimizations have been made in the following areas:

box>TriMesh collision improved
sphere>TriMesh collision improved
ccylinder>TriMesh collision improved
quickstep performance improved

This is quite significant, there has been a flurry of activity over the last two days. Including a few words from the fella who created ODE. I haven't seen this much activity for months so it's quite exciting. The future looks bright for ODE :)


VIP3R(Posted 2005) [#200]
THIS THREAD IS ABOUT TO CLOSE!!!

PLEASE USE THE NEW THREAD LOCATED HERE

THANKS