Jedive ODE Wrapper
Blitz3D Forums/Blitz3D Userlibs/Jedive ODE Wrapper
| ||
Ok, I haven't test it as much as I would have wanted to, but here it is: http://www.galeon.com/jedive/odewrapper/ I am selling the lib for the ridiculous price of 10€. I am selling it through PayPal, so you need a PayPal account in order to purchase it. If something is wrong with the library, PLEASE tell me, and I will fix the issues as fast as I can. I wrote this due to a request from a user in this forum. He was going to pay me for my work, but I have decided to better sell it here so other people can use it. That's why it costs money ;) I handle the sales myself, so after you make the payment, you'll have to wait until I receive an email from PayPal telling me you bought it, so I can send you the .zip. Have fun! |
| ||
I gave my input to Jedive in creating this DLL, and I can honestly say, he did it all right. The commands are just as they are in the ODE docs, and the annoying freezing and invisible object problems the other DLL had are nonexistent. This is well-worth the meager price he is asking for. |
| ||
Now i have a dilemma, I was just starting to experiment with Tokamak rather than ODE because of the problems i had heard of with the 'old' wrapper. If this wrapper is as good as it sounds would you guys recommend going for ODE over Tokamak (a measly 10 euros aside)? |
| ||
A demo of some description would be nice. Can't see many people 'blind-purchasing' tbh.... |
| ||
I have released it now because people were getting impatient, and I haven't had time to make a decent demo of it. I promise to upload one as soon as I have time to make it. It's exams time for me currently :( |
| ||
Good luck with exams, concentrate on those and not this - in the long term that's better. When it's over I'd like to see some demos and an overview of features / commands etc. too :) |
| ||
I just ordered it! |
| ||
Jedive is a solid programmer. I'm sure he has done a good job on it. |
| ||
You could have made life much easier for yourself by setting up a Share*it account, which can deliver the download automatically for you :) In fact it would have made life easier for me too as I don't have a PayPal account. Now I've got to fill in loads of forms and wait a week because it won't take a simple direct payment with a card... what a load of crap. Good luck with the exams btw ;) |
| ||
Paypal processed my debit card just like a payment, all one one screen, only took a couple of minutes. I just got confirmation, and now waiting for Jedive to send the goods. I agree share*it would be faster considering Jedive has to sleep. He's probobly sleeping right now damn it. hehe 8) |
| ||
Strange, it won't accept mine (Visa) for some weird reason, it keeps refusing the process and tells me I need to go to the PayPal homepage and setup an account. Nothing wrong with the card that's for sure, PayPal sucks! |
| ||
I've tested it, it's solid. Any demo you have seen using ODE is representative of this. I would strongly recommend ODE over the alternatives like Tokamak and Newton. I researched all three, and ODE is far superior. Why do you think AAA games like S.T.A.L.K.E.R. use it? Oh, and he was smart enough to include a non-capped cylinder in the lib. It's a whole new primitive to use, and a very useful one. |
| ||
I printed and bound the ODE manual for reference. The manual can be found here: www.ode.org I'm anxious to resume my project I'm working on. I'm really pleased Jedive took time to do this wrapper, and want to thank Halo for talking him into it. What a bargain for Aprox $12.00 US. Cylinders too.. woohoo!! Somebody go wake Jedive up and have him check his damn email. 8) |
| ||
Yeah, thanks halo. Arrggg, I tried PayPal again, still won't accept the payment. I hope Jedive considers using Share*it too, I want to play with it now dammit *sniff* ;) |
| ||
Oh yes, great! At last I have solid choice for my physics needs... physics are "mandatory" these days not to mention how cool & fun they are. Having 100% working "HL2 level" physics in your "indie" gamelet is good for sales... I'll order it next week... have to clear my VISA tab first because I've bought so many books and DVDs from abroad this month already. And my missus is having a big birthday party next weekend so I wouldn't be able to play with ODE anyways :) [or at least that would make my wife VERY unhappy]. |
| ||
Non-capped cylinders would be v.useful. If i could pay by share-it i would probably get this immediately (don't like paypal at all). |
| ||
I received the goods in email this morning. yes! Looks clean and I can't wait to try it out today, at work so it will have to wait till noon. The zip file contains: ode.bb 2kb Blitz ODE constants ode.decls 17kb Blitz Declares ode.dll 664kb ODE DLL readme.txt 2kb test.bb 3kb Readme says: Jedive's ODE Wrapper version 1.0. This library contains most of the ODE functions wrapped inside a Dll, and the files needed to use this library in Blitz3D and BlitzPlus. Many functions in the C version of ODE return a vector to represent a position, rotation, etc, in 3D space. In this wrapper, these functions do not return any value, but fill the data of an internal vector which you can get by calling dVectorX#(), dVectorY#() and dVectorZ#(). The original ODE uses a different coordinate system than Blitz. This wrapper uses the same coordinate system as this language. The original ODE uses quaternions or matrices for rotations. This wrapper uses euler angles (the same as Blitz). It lacks some of the commmands, for example some math functions (because they deal with quaternions and matrices, while this wrapper uses euler angles). LICENSE: You ARE allowed to distribute the ode.dll file included in this package with your games and applications. You are NOT allowed to distribute this library as part of another physics system (for example, a high-level physics system which uses this library), or as a single package. The rest of the files included here cannot be redistributed. Wrapper made by Javier "Jedive" San Juan Copyright © 2005 Niven Interactive |
| ||
The demo program with the wrapper runs, but it's pretty soft and needs some love and care. I'll have the demo retuned shortly. 8) Thanks Jedive fantastic job! |
| ||
Is it already almost the final version?? Or are they some improvements to come?? I would like a demo before buying it, and be sure that it's not too buggy... Anyway, good job, and I am looking forward to test it!! |
| ||
a user has found some oddities in the rotation system. I am testing them right now, but it seems that Blitz is a bit odd handling pitch rotations... Not improvements, as all the Cipher API functions that can be ported are now in. As Blitz does nor support callbacks, the functions that use them have not been included. Collision is done in ODE through a function callback, so this is not done by the user in this wrapper, but internally by the Dll. |
| ||
Any chance you could add the Share*it option Jedive? I can help you set it up if you like, so you'll only have to add the personal details, passwords and payment info. Btw, that pop-up advert is pretty annoying - I take it the host is forcing you to use it? There are plenty of free hosts that don't do that now. |
| ||
So is this the complete wrapper with everything in it? |
| ||
The wrapper is very detailed, I'm not sure if it runs the ODE demos 100% correctly yet, but it's close. I'm checking the original ODE cube stacking program parameters against the demo cube stacking program and parameters. |
| ||
The author and I identified some imprecision in the rotation code, which he is fixing up right now. It's just a matter of switching a couple of axes and flipping some signs. |
| ||
Bugs like this can't be avoided - good thing is that they were found so quickly and are being fixed. This just convinces me more that Jedi-ve-ODE is the right choice for me. |
| ||
Im definitely going to have to get myself involved in selling something Rather than givin it away free. I'l be keeping my eye on this as i will be the one i get should it turn out to work properly ;) tis a little early yet though... |
| ||
An interesting development from Arkon on the BlitzODE sticky thread! Was Arkons wrapper only problem the freezing issue or where there others? |
| ||
I like this... would get my vote instead. Jedive isn't a time waster. |
| ||
Arkon had his chance. Besides, his wrapper hides a lot, whereas Jedive's gives you direct access to the whole command set. AND Jedive's has a non-capped cylinder primitive. Here is a demo that better demonstrates the lib. I just made a few changes to the Blitz code: |
| ||
At last, PayPal has finally accepted payment, what an unpleasant experience that was :/ All I've got to do now is wait for the goodies :D Thanks again Jedive & halo for the work you've both put into this userlib. |
| ||
hmm. whats happened to the ODE website? I get a 404! :( ...if only this wrapper had non-capped cylinder primitives! (rotfl) IPete2. |
| ||
I have just bought this. |
| ||
Take a look at the UpdateEntities() function in halo's example. We have been taking a look at soem issues with rotation. Half of the problem was my routine to convert from quaternions to euler angles. The other half of the problem was due to the way in which Blitz handles rotations. If you rotate an entity like Halo has done in his example, it'll work perfectly. I have to take a look at my quaternion to euler code to fix it anyway ;) Are you guys still interested in ShareIt? I used PayPal because: 1) I get more % of the money. 2) I can transfer the earned money to my bank account whenever I want. 3) In five minutes I had the Buy Now! button. |
| ||
I would buy it instantly if you did share-it aswell, although i understand perfectly why you prefer PayPal. |
| ||
I hope the changes are quick and easy for you. Get it fixed and send out a new DLL soon as your schedule permits. Thanks ps I also noticed that ode.org is down (maybe getting too popular). I do have backups of the documentation. |
| ||
How do you load your own level mesh in? Can you specify different parts of the level to have a different effect? How do you know what your object has collided with? |
| ||
Are you guys still interested in ShareIt? The best option would be to set up both I guess, that way you'll please everyone. You could always add a few extra $$ to the price of the Share*it option to cover your losses. Yippee, I've received the goodies, thanks for the speedy response Jedive :) |
| ||
Those of you that found 'BlitzODE Car Demo' useful will be pleased (I hope) to hear that I've begun work on converting it over to a new 'JediveODE Car Demo' :) At first things were looking a little grim, but after some adjustments were made it's beginning to work out ok. As soon as it's ready I'll let you all know. |
| ||
While www.ode.org is down if anyone needs the documentation please send email with the subject line: ODE Doc Request Ill send you the file: ODE_v0.5_Docs size:213kb Great to see you onboard VIP3R! |
| ||
Flying Willy, Yes to your questions flying willy. probobly take a few days as demos are revised and any remaining bugs fixed. It's going to be fun. Having a nice physics engine can do magic for your Blitz projects as some of us already know. 8) |
| ||
Cheers Wayne :) Ok, I've found some problems so I've made a little demo to show what's happening. Halo and Jedive, that rotation fix doesn't seem to fix the problem properly. I noticed this when some spheres weren't rolling correctly. The 'dVectorY#()' is out by -90. Here is a sphere and cylinder demo which demonstrates correct rotation: Try removing the '-90' in the UpdateGeoms() function and you will see what I'm talking about. There appear to be some other minor problems: Boxes bounce on the plane Cylinders and spheres don't bounce on the plane Try replacing the cylinder code in the AddObject() function with the following code: Notice the boxes bouncing, but not the spheres. Also, the createbox params need to be twice the size of the blitz entity, unlike the sphere and cylinders. It's good practice to rotate before positioning when updating the objects with ODE. I'll keep you posted if I find anything else, you've both done a great job so far :) |
| ||
I notice boxes having funny rotations sometimes too. |
| ||
@Jedive Maybe a stupid suggestion but have you tried the Quaternion to Euler code that Mark posted a while ago? Here--> http://www.blitzbasic.com/Community/posts.php?topic=42657 |
| ||
Does someone have some exempel how to implant it on .b3d or .x objects... I´m to new to ode psy.. Need something to work on. please ? /Alienforce |
| ||
You'll need to use trimesh functions for those, should have something ready soon: http://www.blitzmax.com/Community/posts.php?topic=43168 |
| ||
Cool, looking forward to see it. /Alienforce |
| ||
Success! It took some working out but here it is, the new 'JediveODE Car Demo'. http://www.blitzmax.com/codearcs/codearcs.php?code=1269 Have fun with it :) Now on to the TriMesh function... |
| ||
Really good! Thanks VIP3R, Waiting for your TriMesh :) /Alienforce |
| ||
THe major problem with that car demo I see is the friction is too low, and the car slides rather than turning. I increased the friction, which causes the car to flip...probably why the author turned the friction down so low. The solution is to decrease the steering angle with speed. If you did the same kind of turn on a freeway that you do in a parking lot, of course your car would flip. |
| ||
I wanted to keep it as close as possible to the other car demo I did, so that users of the previous wrapper can compare the differences and make amendments to their own code. The default settings used would probably suit a dirt track (rallying) or something like that. You need to play with the friction, mass, speed and torque settings to suit your requirements. The steering angle can also be adjusted with the speed as you said. I tried that before releasing the last demo and it can cause problems of it's own, mainly understeering at high speed. Btw the friction is quite high, not low - it's the mass that causes the sliding, try lowering it and see (CMass#=100 WMass#=4). Oh, the other thing is it uses spheres for the wheel geometry, the old wrapper (unlike this one) didn't work well with cylinders, so this obviously affects the handling too. I'll experiment with that and make some changes if need be. It serves its purpose, that is to act as a guide for new ODE users. Anyway, should have the TriMesh routine ready for tomorrow ;) |
| ||
The solution certainly isn't to decrease the steering angle with speed. With real cars you have variable masses around the car - for example suspension below, heavy engine at the rear or front. And so on. Tyres are different psi at the back and front too, and this can be emulated by having slightly different friction and mass. Arodynamics plays a part - for example the airfoils of a rally car and low centre of gravity all help the car remain very stable. To emulate this, we can joint it with a dummy weight lower below the car. This will help prevent high speed flips. A lot of creative license goes into making what appears to be realistic physics. |
| ||
To emulate this, we can joint it with a dummy weight lower below the car. This will help prevent high speed flips. That's exactly right, I forgot to mention this. There is a function in the demo that does this very thing. If you check this line: dMassTranslate(mass,0,-1,0) setting the -1 parameter to -10 or greater will increase stability with high friction by lowering the center of gravity. It's all just a balancing act really, that's why it's so difficult to get it right. If you change any one individual setting it will affect all of the others. For example, by changing the mass of the car body it will affect the friction, torque and suspension balance. Quite tricky stuff really, it was tough to get it as stable as it is now tbh. Heck, even the big guns don't get it right sometimes. |
| ||
There's a typo in the decls file: dJointCreatelider%(world, group):"odeJointCreateSlider@8" should be... dJointCreateSlider%(world, group):"odeJointCreateSlider@8" |
| ||
And a possible bug? ;PositionEntity o\ent,dBodyGetPositionX#(o\body),dBodyGetPositionY#(o\body),dBodyGetPositionZ#(o\body) ;RotateEntity o\ent,dBodyGetPitch(o\body),dBodyGetYaw(o\body),dBodyGetRoll(o\body) ...does not work. |
| ||
Use dVectorX(), y z for now. |
| ||
dvector x,y,z gives incorrect rotations - in your own demo. The boxes tumble down as expected, but they don't actually tumble in the right direction. It looks like it to the untrained eye, but on my computer, I'm seeing the wrong stuff. |
| ||
Can we see some results please jedive as the following needs to be fixed: - correct rotations - dBodyGetPositionX#() etc Since we have paid for this out of good faith, we would expect some fixes to come. I don't usually demand, but I have paid you so a fix would be very nice :) |
| ||
;creates the mesh to collide with - see ODESPACE variable and pass your space to it. Function ODECollisionMesh(mesh) tris_count% = 0 vert_count% = 0 For i = 1 To CountSurfaces(mesh) tris_count = tris_count + CountTriangles(GetSurface(mesh, i)) vert_count = vert_count + CountVertices(GetSurface(mesh, i)) Next vertices_bank% = CreateBank(vert_count * 4 * 4) indices_bank% = CreateBank(tris_count * 3 * 4) offset = 0 offset_tris = 0 baseverts = 0 For i = 1 To CountSurfaces(mesh) sf = GetSurface(mesh, i) For v = 0 To CountVertices(sf) - 1 PokeFloat vertices_bank, offset, VertexX(sf, v) offset = offset + 4 PokeFloat vertices_bank, offset, VertexY(sf, v) offset = offset + 4 PokeFloat vertices_bank, offset, VertexZ(sf, v) offset = offset + 8 Next For t = 0 To CountTriangles(sf) - 1 For j = 0 To 2 v = TriangleVertex(sf, t, j)+baseverts PokeInt indices_bank, offset_tris, v offset_tris = offset_tris + 4 Next Next baseverts=baseverts+CountVertices(sf) Next t_data = dGeomTriMeshDataCreate() dGeomTriMeshDataBuildSimple(t_data, vertices_bank, vert_count, indices_bank, tris_count * 3) Return dCreateTriMesh(ODESpace,t_data) End Function For your level mesh. I modified it from my arkon ODE work, I haven't tested it - but it should work fine. Can someone modify it further so we can build it up with different meshes having different friction and so forth, or is that kind of flexibility a dream? |
| ||
Hi guys. VIP3R, your car demo rocks. flying willy, thanks for your TriMesh snippets. I am very busy these days with exams. I took a look at the rotation problems but couldn't go much further with all the things I have to do these days. Of course, they will be fixed, as well as all the problems which are fault of my wrapper and not ODE itself. IT's cool that people here is finding workarounds for it while the update arrives. I think that, as I don't have all the time I would like to get this addresses shortly, I will add a dBodyGetQuaternion() or something. There are many experienced people here which can make a QuatToEuler function which works properly. Anyway, I hope than in one week I can have some time to completely fix it myself. I haven't tried Mark's code, thanks for the link. Will take a look at it tomorrow. Who nows, maybe it's easier than it looks ;) I have never been very good at maths. I also have the intention of making new updates with all the additions that the author of ODE makes, although in its current state I think it is the best *accesible* phyics library. |
| ||
I updated the decls, thanks VIP3R ! ODE wrapper patch, I wish Mark would take 30min of his time and help Jedive correct the small remaining issue with angles. Consider it customer goodwill. Heck I wish he would just buy the wrapper from Jedive, offer it as B3D and BMAX addon. I'm going to want it when it comes time to do BMAX. Damn exams *bites tongue* |
| ||
Yes... Good luck with your exams Jedive. I'm not sure with your idea of doing quat to euler in blitz as it will be slower than quat to euler in C++ won't it? Have you tried emailing Mark about this? My main worry is that things are completely rotated wrong... Jedive, perhaps you should provide the source of the wrapper to people who have actually bought it. Then they can help you further develop it and fix bugs. We are not gonna pirate it or post up the source. |
| ||
another bug: stack overflow in jedives and halo's box demos. Keep hitting space rapidly to see it. Debug mode on... sounds like when too many things are made at once in close proximity. |
| ||
I have just sent the version 1.01 of the lib. It includes the following: - dBodyGetLinearVelX/Y/Z() and dBodyGetAngularVelX/Y/Z() added. - Fixed dJointCreateSlider() declaration in ode.decls file. - Fixed dBodyGetPositionZ(). - Added dVectorW(). - Added dBodySetQuaternion()/dBodyGetQuaternion() and dGeomSetQuaternion()/dGeomGetQuaternion(). - Full source included! Haven't had time to check Mark's library, but I'll do it soon. Anyway, it includes the source, so feel free to take a look at it yourself if you have C++ knowledges ;) The wrapper includes a project file for Dev-C++, which is what I used for the lib. |
| ||
Thanks Jedive! I knew we could count on you! people - if you fix the quaternion/euler thing, or make improvements - please end the results to jedive so he can impliment them! |
| ||
bug report: if you make enough boxes in test.bb, eventually it will quit without warning. Hopefully some guys will take a look at it. |
| ||
flying willy: How much are 'enough boxes'. I created a lot of boxes in my test to see the 'Stack Overflow' error but it didn't happen. That error only happened when I didn't remove the contact joints each frame. |
| ||
replace If KeyHit(57) Then ent.Entity = CreateEntity....... with: For i=0 To 1 ent.Entity = CreateEntity(world, space, 0,500,0, 10,10,10) : EntityTexture ent\ent, etex Next To see stack overflow... |
| ||
Ah ok. That happens to me with 657 objects, both in Release and Debug modes. There's probably nothing I can do to fix it. The error occurs in the dWorldQuickStep command, to I guess that means that there are too many objects for ODE to handle them. |
| ||
this isn't the only occurence of it - it will happen if many overlap too soon - the code above happens immediately in the first loop for me... |
| ||
Here is some code for testing the quaternions. The quaternion to euler routine is in the UpdateEntities() function. Not correct right now: Here is the code of interest: dBodyGetQuaternion ent\body x#=dVectorX() y#=dVectorY() z#=dVectorZ() w#=dVectorW() sp#=-2.0*(y*z+w*x) If Abs(sp)>0.9999 pitch#=1.570796*sp roll#=-ATan2(-x*z-w*y,0.5-y*y-z*z) yaw#=0.0 Else pitch#=ASin(sp) roll#=-ATan2(x*z-w*y,0.5-x*x-y*y) yaw#=-ATan2(x*y-w*z,0.5-x*x-z*z) EndIf RotateEntity ent\ent,pitch,yaw,roll |
| ||
This is closer:dBodyGetQuaternion ent\body x#=dVectorX() y#=dVectorY() z#=dVectorZ() w#=dVectorW() sp#=-2.0*(y*z+w*x) If Abs(sp)>0.9999 ;ERROR IS IN THESE THREE LINES: pitch#=1.570796*sp roll#=ATan2(-x*z-w*y,0.5-y*y-z*z) yaw#=0.0 Else ;This code is fine: pitch#=ASin(sp) roll#=ATan2(x*z-w*y,0.5-x*x-y*y) yaw#=-ATan2(x*y-w*z,0.5-x*x-z*z) EndIf RotateEntity ent\ent,pitch,yaw,roll |
| ||
Well, until the bugs are fixed and until jedives exams are over I wouldn't consider purchasing yet. I kindof need it to be stable. Good work though jedive. :) |
| ||
Yeah, I had the stack overflow too when I was playing around with the demos. Seems to work ok until the pile of boxes reaches the height of the creation point. It appears to throw the error when there's no more room for the created objects to move or too many objects overlap? Speeding up the box creation in halo's test shows up the problem. I couldn't get the problem to appear in the spheres & cylinders demo I posted earlier though. No luck with the TriMesh function yet, it's very similar to the one posted above, so I doubt that one will work either unfortunately. When the TriMesh is created it appears to be rotated incorrectly. It's hard to tell exactly which way because the visible mesh doesn't line up with the invisible collision geometry of the mesh properly, the visible mesh is horizontal and the collision geometry seems to be vertical. If you get chance Jedive (or halo), could you try the TriMesh function posted above and see if you can figure out what's wrong. Thanks for the update :) |
| ||
ODE FAQ 12.11. The Windows version of ODE crashes with large systems ODE with dWorldStep requires stack space roughly on the order of O(n)+O(m2), where n is the number of bodies and m is the sum of all the joint constraint dimensions. If m is large, this can be a lot of space! Unix-like operating systems typically allocate stack space as it is needed, with an upper limit that might be in the hundreds of Mb. Windows compilers normally allocate a much smaller stack. If you experience crashes when running large systems, try increasing the stack size. For example, the MS VC++ command line compiler accepts the /Stack:num flag to set the upper limit. Another option is to switch to dWorldQuickStep. THOUGHTS I'm wondering if Blitz3d needs and option to set a larger stack size? As for the MAV or stack overflow at 657 objects I could probobly live with that limitation. I just got ver 1.01 of the wrapper. Great to see changes made. I was surprised to see the source code is included! Providing the source code is icing on the cake, great buy for $12.00 US. I have no doubt any remaining issues will be resolved. I'm off to test the bad boy out. |
| ||
You should be using quickstep anyways, not step. |
| ||
Not necessarily. There are many situations where you have high friction contacts - these will just fail with quickstep no matter what you try. I'm wondering if Blitz3d needs and option to set a larger stack size? As for the MAV or stack overflow at 657 objects I could probobly live with that limitation. it fails with TWO objects here - just create them at the same time in the same place... |
| ||
Halo, this update function I posted in the spheres & cylinders demo code above appears to have correct rotation, did you try it? Here is the function converted to your type properties: If there is something wrong with it, what is it exactly? |
| ||
if the only problem is -90 in dvectorY, then perhaps this can be fixed in the dll. edit: viper you are correct, it seems -90 fixes the problem. Still getting stack overflows though. Perhaps the stack size can be sufficiently increased. Also, whats up with the Get position commands - don't they work yet? we should not actually be using vector etc should we? |
| ||
And those having problems with the trimesh function, try using tformpoint to transform the verts into world space properly and use the tformed results in place of vertexx etc... See if that fixes your incorrect placement errors. |
| ||
There is a way to get the position by cheating btw ;) When you create your object, do the following after creating the Blitz entity: BlitzMesh=ent\ent (or BlitzMesh=g\mesh with my demos) Then you can just call EntityX(BlitzMesh) as if it were a Blitz entity, I did this in the car demo. You can also use the other Blitz entity commands like EntityPitch/Roll/Yaw etc. Thanks, I'll try out that TFormPoint idea. |
| ||
BUG FIX NOTES: Please Read I wasn't convinced by the -90 degree rotation solution I suggested so I looked closer at the problem, sure enough it hasn't fixed it properly. Halo's solution doesn't seem to help fix it either. The dVectorY#()-90 fix appears to correct the rotation of moving objects but it DOESN'T fix the rotation problem, instead it throws everything else out by -90 degrees. This may give Jedive a clue as to what needs tweaking though. I've recreated the JediveODE Car Demo below with identical settings to the BlitzODE Car Demo to see if this helps show up the incorrect physics. The reason it was so tricky to get working when I converted it was due to a number of problems which may explain the weird rotation issues. Other possible problems have also been highlighted and are as follows: Accelerate/Reverse - backwards (Z Position reversed?) Steering Left/Right - backwards The car 'rolls' when it should 'pitch' and vice-versa. Swapping the pitch and roll in the UpdateGeoms() function partly fixes the issues, it corrects the wheel rotation and roll/pitch - but the roll is backwards so you have to add a minus to correct it (see the UpdateGeoms() function in the demo below). Jedive, here is the JediveODE Car Demo with the BlitzODE Car Demo settings. It shows all of the errors described above and should work correctly if the problems are identified/fixed within the wrapper. Hopefully it may help you when you get chance to take a look at the wrapper code. Also, it would be better to use the Geom functions in the UpdateEntities()/UpdateGeoms() function instead of the Body functions, as this will allow you to build static objects (which don't require a 'body' to be assigned to them). |
| ||
Nice work VIP3R, and for it's worth I noticed the Blitzode update geoms had comma one parm on the end.Function ODE_UpdateGeoms() For g.TODEGeom = Each TODEGeom PositionEntity g\mesh, ODE_dGeomGetPositionX(g\geom), ODE_dGeomGetPositionY(g\geom), ODE_dGeomGetPositionZ(g\geom) RotateEntity g\mesh, ODE_dGeomGetPitch(g\geom), ODE_dGeomGetYaw(g\geom), ODE_dGeomGetRoll(g\geom), 1 Next End Function |
| ||
That means rotate globally, not locally, I think it's only used for children isn't it? |
| ||
http://www.blitzbasic.com/codearcs/codearcs.php?code=490 shows how to take a typical quat and convert to blitz euler. I would prefer this to be done in C++ for speed of course! Another thing - ODE has a function to convert quat to euler - why isn't this used? ; convert a Quat to a Rotation Function QuatToEuler(out.Rotation, src.Quat) Local sint#, cost#, sinv#, cosv#, sinf#, cosf# Local cost_temp# sint = (2 * src\w * src\y) - (2 * src\x * src\z) cost_temp = 1.0 - (sint * sint) If Abs(cost_temp) > QuatToEulerAccuracy cost = Sqr(cost_temp) Else cost = 0 EndIf If Abs(cost) > QuatToEulerAccuracy sinv = ((2 * src\y * src\z) + (2 * src\w * src\x)) / cost cosv = (1 - (2 * src\x * src\x) - (2 * src\y * src\y)) / cost sinf = ((2 * src\x * src\y) + (2 * src\w * src\z)) / cost cosf = (1 - (2 * src\y * src\y) - (2 * src\z * src\z)) / cost Else sinv = (2 * src\w * src\x) - (2 * src\y * src\z) cosv = 1 - (2 * src\x * src\x) - (2 * src\z * src\z) sinf = 0 cosf = 1 EndIf ; Generate the output rotation out\roll = -ATan2(sinv, cosv) ; inverted due to change in handedness of coordinate system out\pitch = ATan2(sint, cost) out\yaw = ATan2(sinf, cosf) End Function Perhaps this can be converted to C++ and included in the lib? |
| ||
Yeah, the '1' is a global/local parameter, it doesn't have any effect on the geometry update from what I can see. I've been thinking more about this rotation problem, if there was some way to seperate the initial rotation (when the object is created) from the update rotation this problem would be quite easily fixed with -90 on the Y axis (during the updating only). This would need to be done within the wrapper code though. The trouble is, without the -90, all rotation and positioning matches blitz's rotation and positioning exactly. So any objects created using ODE or Blitz would have identical orientation. But adding -90 means that although it fixes the movement rotation, every object created ends up 90 degrees out from blitz's rotation. Hope that made sense :) Btw, the GetPositionX,Y,Z and GetPitch,Yaw,Roll work ok with the new update so we can do away with the vector stuff in the update function now. |
| ||
have you tried the above func to see if it works? I don't know much C++ |
| ||
It's already in, I've checked the lib source against that QuatToEuler function and it matches exactly with the exception of the following:roll = -atan2(sinv, cosv) * RAD2DEG pitch = atan2(sint, cost) * RAD2DEG yaw = atan2(sinf, cosf) * RAD2DEG RAD2DEG is a constant set at 57.2957795130823208767981548141052 These are the ODE functions to call within Blitz (halo uses one of them in his fix attempt above): dBodyGetQuaternion(body) dBodySetQuaternion(body,qw#,qx#,qy#,qz#) dGeomGetQuaternion(geom) dGeomSetQuaternion(geom,qw#,qx#,qy#,qz#) |
| ||
I'm wondering if we should call the ODE functions within C++ and see what the result is then. Also, in my trimesh function above, I can't seem to get it working under jedive ODE for some reason! it was working fine with arkon's lib... But the priority is correct rotations of course :) edit: yeah I see what you mean about the rotated stuff. This needs fixing in the actual dll for sanity's sake - if arkon and vorderman can do it, so can we. Lemmie see if I can get vorderman's email as he may be able to throw us a bone.... ok - I couldn't find his email, but he's here: http://www.blitzbasic.com/Account/showuser.php?id=954 sweenie might be able to help us as well if you can get hold of him. |
| ||
:( |
| ||
I can't find my old ODE dll source code, but I have the blitz side of it - this is the function that returns the orientation of an ODE body for Blitz to use - Remember this was made before Blitz could use DECLS files so you had to use banks and suchlike, so it's pretty clunky... Function ODE_Get_Object_Rotation(obnum , ob.ODE_Object) ; Local mBankOut = CreateBank(12) ; Local mBankIn = CreateBank(12) PokeInt(mBankIn,0,obnum) PokeInt(mBankIn,4,0) PokeInt(mBankIn,8,ob\geomonly) ;geom only flag returned = CallDLL(DLLNAME$,"get_object_rotation_component",mBankIn,mBankOut) ob\q1# = PeekFloat(mBankOut,0) PokeInt(mBankIn,4,1) PokeInt(mBankIn,8,ob\geomonly) ;geom only flag returned = CallDLL(DLLNAME$,"get_object_rotation_component",mBankIn,mBankOut) ob\q2# = PeekFloat(mBankOut,0) PokeInt(mBankIn,4,2) PokeInt(mBankIn,8,ob\geomonly) ;geom only flag returned = CallDLL(DLLNAME$,"get_object_rotation_component",mBankIn,mBankOut) ob\q3# = PeekFloat(mBankOut,0) PokeInt(mBankIn,4,3) PokeInt(mBankIn,8,ob\geomonly) ;geom only flag returned = CallDLL(DLLNAME$,"get_object_rotation_component",mBankIn,mBankOut) ob\q4# = PeekFloat(mBankOut,0) tempx# = EntityX#(ob\mesh,True) tempy# = EntityY#(ob\mesh,True) tempz# = EntityZ#(ob\mesh,True) PositionEntity ob\mesh,0,0,0 PositionEntity ODE_tempPivot,0,0,0 RotateEntity ob\mesh, 0, 0, 0 AlignToVector ODE_tempPivot, -ob\q2# , -ob\q4#, -ob\q3#, 3 ; aim z-axis... EntityParent ob\mesh, ODE_tempPivot TurnEntity ODE_tempPivot, 0, 0, 2 * ACos( ob\q1# ) EntityParent ob\mesh, 0 ; undo parent / child relationship PositionEntity ob\mesh,tempx#,tempy#,tempz# ob\xa# = EntityPitch(ob\mesh,1) ob\ya# = EntityYaw(ob\mesh,1) ob\za# = EntityRoll(ob\mesh,1) End Function |
| ||
You are using the quaternion to align the entity, but I am actually looking for code to convert the quaternion to euler angles. Points for inventiveness. |
| ||
check out the advice I got from a C++ programmer using a 3D engine which accepts Euler angles:void AnglesFromMatrix ( D3DXMATRIX* pmatMatrix, D3DXVECTOR3* pVecAngles ) { // Thanks to Andrew for finding this gem! // from http://www.martinb.com/maths/geometry/rotations/conversions/matrixToEuler/index.htm float m00 = pmatMatrix->_11; float m01 = pmatMatrix->_12; float m02 = pmatMatrix->_13; float m12 = pmatMatrix->_23; float m22 = pmatMatrix->_33; float heading = (float)atan2(m01,m00); float attitude = (float)atan2(m12,m22); float bank = (float)asin(-m02); // check for gimbal lock if ( fabs ( m02 ) > 1.0f ) { // looking straight up or down float PI = D3DX_PI / 2.0f; pVecAngles->x = 0.0f; pVecAngles->y = D3DXToDegree ( PI * m02 ); pVecAngles->z = 0.0f; } else { pVecAngles->x = D3DXToDegree ( attitude ); pVecAngles->y = D3DXToDegree ( bank ); pVecAngles->z = D3DXToDegree ( heading ); } } What do you think? he says ODE returns a MATRIX which you can use the directx-native function calls to extract. Hope this helps... better we do this in the C++ DLL than in blitz for simplicity and speed. I think this is the baby we need. |
| ||
I examined the wrapper source and I'm a bit worried that for each call to getposition and getangle, jedive is calling the ENTIRE QuatToEuler function over and over again, instead of just once... a lot of optimisation can be done there I think :) |
| ||
in blitz3d programming, mark has pasted his code for blitz3d transforms. Of particular note: inline float quatPitch( const Quat &q ){ return q.k().pitch(); } inline float quatYaw( const Quat &q ){ return q.k().yaw(); } inline float quatRoll( const Quat &q ){ return matrixRoll( q ); } I included Mark's entire maths code and tidied up a couple of things, however, I tried to modify the ode getpitch/yaw/roll to throw the quat given by ODE directly into marks functions and return the results but no joy (syntax errors as I am not familiar with C++). However I believe the code I pasted a couple of paragraphs above IS what we need to do. Instead of COSTLY conversion from quat to euler, we have to access the ODE rotation matrix for the rigid body DIRECTLY. ODE goes through this transformation anyway to give you a quat, so you may as well cut a long story short and do it directly. The above code does this, however I lack the means to put it into action. |
| ||
This lib isn't going anywhere really is it? I'm just talking to myself I guess. |
| ||
Hello Friends! I Am Register At End!. I have been working with Arkon Wrapper and Jedive Wrapper. Both Great. I have a very realistic car demo with suspension, gears, no roll's, brakes, hand brakes, etc. I am going to prepare a little .zip or .rar demo and i will advise you! It uses an own modified version of Arkon Wrapper. P:D: Perhaps Jedive Could ask Arkon for the rotation code and trimesh code! |
| ||
@KuRiX: Sounds good :) @Flying: I've currently got my head stuck deep into C++, trying out a few ideas. Not quite there yet, but I'm getting closer to nailing the rotation errors. I'm not sure whether this is a conversion (Quat>Euler) error, the geometry rotation is correct (or at least very close), it's the mesh that's misaligned. Once I've figured that bit out we should be fairly close to getting it working correctly. From what I can tell, the TriMesh data functions aren't yet fully supported by the wrapper, that's why we can't get the TriMesh working at the moment. I'll keep you up to date on my progress ;) |
| ||
Ok, here it is, my car demo. Should be in the Arkon thread, but this is the actual ode thread i think: www.lcuriel.arrakis.es/CarDemoKuRi.rar Take care when driving :) Infinite plane to avoid falling in the holes :D |
| ||
Nice demo! how do you prevent "sinking" artifacts in the trimesh? Look forwards to your progress viper :) Anyone got arkon source code? I dropped a donation by but never recieved anything - I guess $1 isn't enough hahahahaha! :) |
| ||
For the sinking problem, if using Arkon Wrapper, be aware that the mass you set is the mass for a simple objeto, it doesn't take care if it is a box, sphere (bug corrected in my modified wrapper version). So set the mass to a high value (200) but not too much. It is better to have less mass and more gravity. And of course use a step of 0.05 or 0.08 Good Luck! |
| ||
Thanks for the tips! Even rotating the trimesh in jedive ode, it's clearly apparent that it's broken to bits and doesn't work well at all. I leave this problem in the hands of greater minds. |
| ||
I wonder if this would help: http://q12.org/pipermail/ode/2003-April/008123.html |
| ||
ummm... I don't get it - wayne, in your link it shows that "You can use dBodyGetRotation() to get Euler angles" -- if this is the case why are we all trying to pointlessly convert? All we need to do is swap the order right? |
| ||
someone posted a question on the OdeMax thread on the max forum asking about eular rotations The full source code to odemax can be downloaded from www.traklink.com Its a simple solution to eular rotations, but it works! hope this helps All the best... |
| ||
' transfers the objects matrix into opengl ready for render Function SetTransformMat(geom:Int) Local R:Float Ptr Local pos:Float Ptr Local matrix:Float[16]; pos =Float Ptr dGeomGetPosition (geom); R = Float Ptr dGeomGetRotation (geom); matrix[0]=R[0]; matrix[1]=R[4]; matrix[2]=R[8]; matrix[3]=0; matrix[4]=R[1]; matrix[5]=R[5]; matrix[6]=R[9]; matrix[7]=0; matrix[8]=R[2]; matrix[9]=R[6]; matrix[10]=R[10]; matrix[11]=0; matrix[12]=pos[0]; matrix[13]=pos[1]; matrix[14]=pos[2]; matrix[15]=1; glMultMatrixf (matrix); EndFunction Function EulerRotateGeom(geom:Int,x:Float,y:Float,z:Float) glPushMatrix() glLoadIdentity() glRotatef x,1,0,0 glRotatef y,0,1,0 glRotatef z,0,0,1 SetTransformMat(Geom) Local m:Float[16] Local m2:Float[16] glGetFloatv(GL_MODELVIEW_MATRIX,Varptr m[0]) m2[0]=m[0]; m2[1]=m[4]; m2[2]=m[8]; m2[3]=m[12] m2[4]=m[1]; m2[5]=m[5]; m2[6]=m[9]; m2[7]=m[13] m2[8]=m[2]; m2[9]=m[6]; m2[10]=m[10]; m2[11]=m[14] m2[12]=0; m2[13]=0; m2[14]=0; m2[15]=1 dGeomSetRotation(geom,Varptr m2[0]) glPopMatrix() End Function Thanks Chris! This seems to be the blitzmax/opengl code you refer to that performs quat to euler. Is it a bit like the void AnglesFromMatrix C++ routine above? Nice work btw, although I can't understand it :) |
| ||
jdive feel free to contact me... briefly get the ODE matrix (from the quat, using ODE) convert to an openGL matrix and multiply with SetTransformMat (this routine is primarly used for directly using the ode geom matrix to setup each ogl model matrix) EulerRotateGeom does the ogl>ode matrix conversion after rotating it btw i've had 60+ d/loads on ODEMAX and 1 tentitive offer of help, please if you have max step up... v0.03 "world" here created with the ODEMAX demo keep up the good work here, good to see some community spirit! |
| ||
Chris C, thanks for all of your help it's much appreciated, you've done a great job with your ODEMax project so far :) Unfortunately, I don't think the ODEMax equations would be compatible with this lib as an OpenGL matrix (BlitzMax) is a bit different to a DirectX matrix (Blitz3D). |
| ||
Viper - did you check out the dx matrix stuff above? it's being used by a bloke using ODE with an euler DX engine. |
| ||
Just bought it - hopefully Jedive (or somebody) can find time to fix those smallish bugs it has. It looks generally speaking great and I really need it for my game(s). Thumbs up Jedive! |
| ||
FIXED ROTATION/POSITIONING & ORIENTATION!!! :) Well, my head hurts a lot but I've managed to pinpoint and correct the errors with the rotation/positioning and orientation issues. I've also managed to increase stability in the physics. As I suspected the (Euler<>Quaternion) conversions were not at fault as far as I can tell. The problems were in the following areas: maxcontacts (changed internal integer for stability) dBodySetRotation (corrected yaw) dBodyGetYaw (corrected yaw) dGeomSetRotation (corrected yaw) dGeomGetYaw (corrected yaw) dCreateBox (corrected orientation) My main objective was to use the same orientation for ODE entity positioning/rotation as Blitz itself uses. So if you create a cube in Blitz, and then create another using the ODE wrapper they would have identical orientation properties. It's worth noting that Arkons wrapper does NOT have the same orientation as Blitz's entities, which leads to confusion when creating and positioning ODE/non-ODE objects. The reason it was so confusing to figure out what was wrong with the wrapper, was due to the fact I was using a Blitz cube and an ODE box to figure out alignment issues. As soon as I realised the ODE box was being setup incorrectly, it was a simple process to correct everything. With the fixed ODE.dll you can now create objects and expect them to be orientated as they would be using Blitz's own entities - and of course everything rotates/collides correctly now. I've tested this on the (corrected) Car Demo and it works fine. I'll send Jedive the new source with all of the corrections so that he can add it to the next update. In the mean time, try this car demo code below, it contains all of the corrections (via blitz) so that you can test it with the current dll. The only thing it doesn't correct is the stability (which is internal to the dll). The white rectangle is a standard Blitz entity and the blue one is an ODE entity, as you can see they are correctly orientated to each other. Btw, the ODE box dimensions still need to be double that of the Blitz entity dimensions, this is easily fixed within the wrapper too. I'll check the dimensions of the ODE objects against Blitz entities next and see if I can correct those before I send Jedive the updated source. Let me know if you find any problems. |
| ||
oh you little genius! you've brought a massive grin to my face! :) Does this fix trimesh orientation n sutff as well? also, do you want 10 euros? hehe |
| ||
Your the man VIP3R, well done fella :) :) :) |
| ||
Not sure about the TriMesh yet, as soon as I've checked the dimension stuff I'll take a closer look at it. Hehe 10 euros, nah this ones on me :) Feel free to make a purchase at Devious Codeworks though if you really want to help me out, that way you get a free product too :P |
| ||
Wow this is awesome. Couldn't read all the post in this thread (getting big!), but I'm glad you found the error with rotation. Will check it when I have some time, really really busy this week. Anyway, if you e-mail me the code, I'll make another update. Thanks man. |
| ||
waiting for my update :) please look at trimesh as well if you can as it's important to collide with levels! |
| ||
No problem, I'll email the source as soon as I've finished tweaking :) Currently fixing: dCreateBox (all dimensions need to be doubled) dCreateCylinder (orientation wrong, maybe dimensions too?) dCreateCCylinder (length dimensions wrong - see below) Anyway, I'll try and get those fixed and email the source to Jedive by tonight, he can then send you all the new update ;) [edit] @Flying: I'll be taking a look at the TriMesh stuff too after these tweaks :) |
| ||
I was getting worried I might have to learn c++ Nice team work, looking forward to the update. Thanks |
| ||
The length of capped cylinders is the length of the shaft. Add the 2*radius for total length. |
| ||
Whoo-a... am I glad that I bought this. Good work Jedive, Halo and VIP3R and all other that have helped to find/fix bugs! JediveODE looks really nice now. |
| ||
if trimesh can be sorted out, then finally we will be able to get started - even if other bugs remain... very few levels have a plane and some cubes :) |
| ||
Ok, I've now fixed the following: maxcontacts (changed internal integer for stability) dBodySetRotation (corrected yaw) dBodyGetYaw (corrected yaw) dGeomSetRotation (corrected yaw) dGeomGetYaw (corrected yaw) dCreateBox (corrected orientation and dimensions) dCreateCylinder (corrected dimensions) *Orientation still broken, use dCreateCCylinder for now* dCreateCCylinder (corrected dimensions) You're close halo, the length needed correcting like so: length=(length-radius)*2 I've sent Jedive the new C++ source plus a few simple demos to have a play with, so you should receive an update shortly. Thanks for all of the support :) |
| ||
brilliant init... btw what do you mean by fixing maxcontacts? I set mine at about 10 - what changes have you made under the hood - the default amount? Thank you for fixing this. |
| ||
Yeah, the default amount. The maxcontacts used in the lib was set at a default of 1. I read in the ODE docs while researching the bugs, a recommended default setting would be 128. Objects in mid-air can shake all over the place if this setting is too low, so I thought it would be wise to change it. You can still alter the maxcontacts using the dContactSetMaxContacts function if you need to. I've updated the 'JediveODE Car Demo' to run with the new version of the lib (V1.02). Now you get a ramp too, whoopee! :) You can find it here: http://www.blitzmax.com/codearcs/codearcs.php?code=1269 |
| ||
I am currently looking for the source. Your examples seem to work perfectly. The only thing that it seems you've done wrong is correcting the dimensions of the boxes. Consider that when you create a box in Blitz, it has a size of 2x2x2, so if you use ScaleMesh box,10,10,10, it has a size of 20x20x20, not 10x10x10. That's why your objects are bigger than the box geoms. The same applies to cylinders for the radius (not for the length). Gonna change this to the default behaviour and send the new update. |
| ||
[edit] You're right, oops :) |
| ||
I use Meshwidth(), MeshHeight() and meshdepth to calculate the bounds of my meshes and fit an ODE box to it, so I need it to use blitz sizes.... so long as I can make a mesh that is ten units wide and the ode box of 10 units wide will fit it, I'm happy. ie... importing a custom mesh and using meshwidth to find the unit width etc... Looking forwards to the update - please send soon jedive :) |
| ||
Ahhh, yes you're quite right, this didn't occur to me before. Jedive, you'll need to halve the sphere dimensions to give correct proportions, otherwise MeshWidth() etc will return double the size of spheres, won't it? |
| ||
My current code looks like...;creates a rigid body Sphere from a source entity's dimensions and link them together Function ODESphere(ent) ;EntityParent ent,0 ;get transform x#=EntityX(ent,1) y#=EntityY(ent,1) z#=EntityZ(ent,1) sx#=MeshWidth(ent)/2 sy#=MeshHeight(ent)/2 sz#=MeshDepth(ent)/2 ;get radius (radius is biggest scale) radius#=0 If radius<=sx radius=sx If radius<=sy radius=sy If radius<=sz radius=sz ;create ode rigid body o.odebody = New odebody o\body = dBodyCreate(ODEWorld) ;create the rigid body geometry for ode o\geom = dCreateSphere(ODESpace,radius) dGeomSetBody o\geom,o\body ;set position and rotation dBodySetPosition o\body,x,y,z dBodySetRotation o\body,0,0,0 ;link o\ent=ent Return o\body End Function Basically I parse my LoadAnimMesh and easily link stuff up and turn it into rigid bodies. Eventually I'll sort the mass and other stuff too... |
| ||
Jedive, you'll need to halve the sphere dimensions to give correct proportions, otherwise MeshWidth() etc will return double the size of spheres, won't it? MeshWdith() will give you the total width of the mesh. As dCreateSphere() expects a radius parameter, you have to halve the width to get it. So yes, you are correct.[EDIT:]Update 1.02 sent. |
| ||
Great, I'll update the Car Demo with the adjusted dimensions as soon as I've tested it ;) |
| ||
maybe you could have a url and use htaccess for a password for regged users. Might be easier for you... also, did you fix trimesh? I am anxious to be able to drive my car on roads and hills :) |
| ||
I like that Flying Willy. It's been longer than five min Jedive. 8) pS. It's here !! That was fast. thank you |
| ||
Ooops, the demos are broken and the C++ source is still showing the dimension corrections I made. Jedive, I'll tinker with the C++ source now, check/correct the demos and send them over in a moment, don't go to bed just yet! :) |
| ||
yes.... hey viper how about swapping emails and we'll continue working/testing etc? |
| ||
Uh? The demos are ok here. |
| ||
Ok, Flying no problem, I think I have your address here somewhere ;) [edit] Jedive, I got confused a little there, you've updated the demos, and commented out the dimension stuff, but you've missed the orientation fix in dCreateBox (swapping lx and lz). Also, check the CCylinders-Demo, the cylinders don't touch the ground plane. I'm changing dCreateBox (with the orientation fix), dCreateCylinder and dCreateCCylinder back to their original state and adjusting the demos now... I'll send them over very shortly... |
| ||
I've been working on the Trimesh code posted above, and it seems just totally and utterely buggered. I think something in the wrapper is the cause - not just the orientation. |
| ||
You are right, they are not touvhing the ground. This is because of this line:ode\geom=dCreateCCylinder(Space,2,5)Cylinder geom radius is set to 2, while the cylinder entity radius is 1. Change the radius in that function to 1 and it'll work. I have made sometinhg 'odd' anyway: I scaled the entity height using the same value as the cylinder geom's length, and I have not halved it like I shold have done. This is because the length of the geom does not include the caps, and the entity height does not have caps. And about the dimension of the objects, this is how th esource looks: DLLint odeCreateBox(int space, float lx, float ly, float lz) // FIX (VIP3R) { //float vlx, vly, vlz; //vlx = lz * 2.0f; //vly = ly * 2.0f; //vlz = lx * 2.0f; return (int)dCreateBox((dSpaceID)space, (dReal)lx, (dReal)lz, (dReal)ly); }The code you added doubling the size of the geom has been commented out, so geoms are nto doubled. |
| ||
Have you managed to see whats wrong with trimesh yet? perhaps it's a small bug stopping it working..? |
| ||
Yeah Jedive, not only did I double the size but I also swapped lx with lz, to correct orientation (if you run the Rectangles-Demo you'll see they are 90 degrees out). |
| ||
As you've probably discovered dCreateBox() is still broken in V1.02 (Jedive commented out the orientation fix by mistake), sorry about that :/ The good news is I've corrected both that and the demos. I've also added a new function to offer an alternative to dCreateCCylinder() called dCreateCCylinderIncCap(). This adds the length of the caps to the overall length of the cylinder (the original function doesn't do this). An example of both functions is in the new CCylinder-Demo. I've sent the new C++ source, demos and decls files to Jedive, so if he's happy with it you should receive another update (V1.03) sometime very soon (he's probably in bed now). I'll start playing around with the TriMesh stuff shortly :) |
| ||
Outstanding! I welcome our new wrapper overlords.. Crap my dll is out of date before I can get home from work! Arkon is probobly breaking into a sweat wondering how he can make a buck out his dying wrapper. 8) |
| ||
Just got 1.02 and now I'm waiting for the 1.03 I guess... this thing is getting more and faster updates than IE+XP! :) |
| ||
VIP3R, jedive and all, nice work comming on well! |
| ||
Trimesh Trimesh Trimesh Rah Rah Rah! |
| ||
The good news is I've corrected both that and the demos. I've also added a new function to offer an alternative to dCreateCCylinder() called dCreateCCylinderIncCap() GREAT work so far... but how does the above function work? for cylinders! which version do I choose for matching with MeshHeight() to the length and MeshWidth for the radius? I don't mind having to /2 or *2 :) |
| ||
[edit] I'm going to alter the standard ODE CCylinder to match the size of a blitz entity. Therefore there would be no need for the extra function. If you create a cylinder like this: mesh=CreateCylinder(8) ; Blitz cylinder ScaleMesh mesh,1,5 The returned sizes using MeshWidth() and MeshHeight() for the above mesh dimensions would be radius=2 and length=10. So you would do the same as for spheres and divide the MeshWidth() and MeshHeight() by 2 to give the correct ODE dimensions (1 & 5). This may change depending on what Jedive thinks... I'll let you know :) |
| ||
You two know best! *whispers something about trimesh being utterely broken* :) |
| ||
My advice is to not make changes to the DLL that are specific to Blitz3D. Most of his sales will come from non-Blitz users. ODE functions should behave like the standard ODE functions. Otherwise, you isolate "BlitzODE" from the rest of the world. Arkon's wrapper was an extreme example of modifying ODE for Blitz. When you can isolate a chunk of code like this, it is really important to leave it with the standard functioning. For example, I have a PureBasic dll that wraps almost all the PB functions. I thought about modifying it to make the functions more Blitz-like, but it really works better to just use the standard commands. |
| ||
I'm happy with the standard commands: it lets me modify C++ code and learn from it. HALO - do you have trimesh working? IMHO it's essential. |
| ||
I agree that ODE functions should remain unchanged, and function as documented for ODE. It's of primary importance that the documentation from www.ode.org match. By not corrupting the original meanings we can all focus our efforts and communicate on common ground, and across platforms. At the same time lets consider the value of adding Blitz equiv functions like : ' Creates ODE Cylinder dCreateCylinder%(space,radius#,length#) ' Creates ODE Cylinder same as Blitz3d bCreateCylinder%(space,radius#,length#) The Blitz Equivalent function might be the same as: dCreateCylinder%(space,radius#*2,length#*2) All this does not mean I disagree with the current direction. There are pros and cons to everything and many possible favorable outcomes. |
| ||
ok thats a pretty happy situation! I definately like wayne's suggestion as it is the best of both worlds. I like trimesh even more though, and you must hate me going on about that now... |
| ||
The changes made so far aren't really specific to Blitz3D, the orientation issues are relative to each other regardless of the 3D system they are applied to, only then are they aligned the same as blitz's own coordinates. Also, this readme.txt included with the wrapper states that this system is designed specificly with Blitz in mind: The original ODE uses a different coordinate system than Blitz. This wrapper uses the same coordinate system as this language. So it would make sense to me for the wrapper to be as close to blitz's own system as possible. With the standard ODE spheres function, the user needs to divide MeshWidth() and MeshHeight() by 2 to give the correct ODE sphere size. The new changes to V1.03 are as follows: * Corrected dCreateBox orientation. * Changed ODE dCreateCCylinder function to behave the same way as with the 'STANDARD' ODE spheres (i.e. MeshWidth()/2 and MeshHeight()/2 to give correct ODE cylinder size). Only the length of the cylinder was affected. This adjustment is needed otherwise the visible mesh will be too long compared to the ODE geometry. I'll leave it up to Jedive to decide whether the CCylinder function remains like this. Working on the TriMesh issues now, I'll let you know as soon as I can. This is still the same as it was before, I think you misunderstand what I'm changing here: ' Creates ODE Cylinder dCreateCylinder%(space,radius#,length#) |
| ||
ohhh.... music: Working on the TriMesh issues now, I'll let you know as soon as I can. |
| ||
You see, this is what I'm talking about: The Blitz Equivalent function might be the same as: dCreateCylinder%(space,radius#*2,length#*2) This is how you would expect it to work, but it doesn't work properly in V1.02 because the visible cylinder length is wrong, try it and see! (using CCylinder not Cylinder - which is broken) The changes I've made to the CCylinder function will allow this to now work... give me strength :) |
| ||
OK my example was a little confusing, but since your onto trimesh I'm on your side ! |
| ||
we'd like realtime raytracing and a muffin with a cup of tea as well please. |
| ||
No problem, I'll add a dCreateBlowJob() function too eh? Hehe :) The standard ODE dimension system sucks when compared to entities IMO. Here are the standard ODE functions compared to Blitz entity scales: dCreateSphere(Space,MeshWidth()*0.5) <<< Half dCreateBox(Space,MeshWidth()*1,MeshHeight()*1,MeshDepth()*1) <<< Same dCreateCCylinder(Space,MeshWidth()*0.5,(MeshHeight()*1)-MeshWidth()*1) <<< Wtf! I've changed the CCylinder function to this: dCreateCCylinder(Space,MeshWidth()*0.5,MeshHeight()*0.5) If it were up to me I'd change them ALL to... MeshWidth()*1,MeshHeight()*1,MeshDepth()*1 ...the same scale as Blitz entities (and dCreateBox). |
| ||
if the only difference between 2 different functions is the first letter b or d, it will be hell for dyslexic people and easily missed if typed wrong even by a non-dyslexics... I'd say :- ' Creates ODE Cylinder dCreateCylinder%(space,radius#,length#) ' Creates ODE Cylinder same as Blitz3d b3ddCreateCylinder%(space,radius#,length#) or b3d_dCreateCylinder%(space,radius#,length#) basically include the origonal function name but make the prefix easily decernable. $0.02 from a dyslexic |
| ||
I'm in agreement with Halo there, in that there should be no prefix. Like this: dCreateCylinder(space,radius#,length#) It's easier to understand the ODE user guide without prefixes too, as the original ODE function names don't have prefixes. |
| ||
...And soon ppl start adding BB3D or whatever prefixes to every possible and impossible ODE function and cry when it doesn't work. KISS, keep it simple... no prefixes! |
| ||
Would it make sense to create and include file for B3d ODE extensions to support stuff like B3d_dCreateSphere. Doing that would keep DLL clean. 8) 'If it were up to me I'd change them ALL to... MeshWidth()*1,MeshHeight()*1,MeshDepth()*1 ...the same scale as Blitz entities (and dCreateBox). ' The Important Thing is Trimesh! |
| ||
I now have the TriMesh *almost* working perfectly :) It's more of the same, rotation and orientation errors. I've got a TriMesh terrain (.b3d) which I can drive over and it matches the geometry exactly. The only snag is that it's upside down, so the texture/colour of the mesh is really dark. I haven't managed to turn it the right way up yet, sounds simple doesn't it, just rotate one of the axis by 180 degrees - but no it ends up vertical instead of horizontal. Any suggestions welcome. I'll keep trying... more soon... :) |
| ||
Make sure the blitz3d part that generates the trimesh transforms the verts into world space. That's the first step.... As for it looking dark, thats just a crap mesh or something wrong with what you're doing in Blitz3D :) so the texture/colour of the mesh is really dark Wots that got to do with ODE? is the ODE bit ok? if so bring it on!!! :DSo long as I can throw a mesh at it and ODE works perfectly thats all that matters.... :) |
| ||
When I create the TriMesh its geometry is vertical instead of horizontal, so I've rotated it until it's horizontal. Then I have to rotate the visible TriMesh 180 degrees to match the ODE geometry (the texture isn't dark until I do this). If I rotate the geometry but don't rotate the visible TriMesh this is what happens: Imagine looking forwards with a slope going up from left to right, this would be your visible TriMesh... >>> / <<< But, the geometry of the TriMesh slopes up from right to left... >>> \ <<< ??? |
| ||
The ODE dll is one level of complexity, and should remain as close to the original ODE as possible. Additions and alterations are a second level based on that, and should be implemented via Blitz code or a separate DLL. I know this. I am presently developing an editor based on an engine I am still writing, both written in BlitzPlus, but both are compartmentalized into different levels, so I can take the engine code out and compile it into a DLL, or use it to write another program. It is extremely important to keep your levels of complexity separate. |
| ||
Your problems in blitz are nothing to do with ODE - they don't affect one another... I don't know why you're mentioning the Blitz3D problem? there is no visible trimesh. There is only a Blitz3D mesh - with all associated Blitz3D problems... I take it you're prolly not that used to Blitz3D yet? ODE keeps it's own mesh data entirely seperarate. I think you are working with a bad mesh. Here is some extra trimesh code, taken from arkon's, and modified by me to use world space verts: ;creates the ent to collide with - see ODESPACE variable and pass your space to it along with your mesh. Function ODECollision(mesh,ODESpace) tris_count% = 0 vert_count% = 0 For i = 1 To CountSurfaces(mesh) tris_count = tris_count + CountTriangles(GetSurface(mesh, i)) vert_count = vert_count + CountVertices(GetSurface(mesh, i)) Next vertices_bank% = CreateBank(vert_count * 4 * 4) indices_bank% = CreateBank(tris_count * 3 * 4) offset% = 0 offset_tris% = 0 baseverts=0 For i = 1 To CountSurfaces(mesh) sf = GetSurface(mesh, i) For v = 0 To CountVertices(sf) - 1 TFormPoint VertexX(sf, v),VertexY(sf, v),VertexZ(sf, v),mesh,0 PokeFloat vertices_bank, offset, TFormedX() offset = offset + 4 PokeFloat vertices_bank, offset, TFormedY() offset = offset + 4 PokeFloat vertices_bank, offset, TFormedZ() offset = offset + 8 Next For t = 0 To CountTriangles(sf) - 1 For j = 0 To 2 v = TriangleVertex(sf, t, j)+baseverts PokeInt indices_bank, offset_tris, v offset_tris = offset_tris + 4 Next Next baseverts=baseverts+CountVertices(sf) Next t_data = dGeomTriMeshDataCreate() dGeomTriMeshDataBuildSimple(t_data, vertices_bank, vert_count, indices_bank, tris_count * 3) Return dCreateTriMesh(ODESpace, t_data) End Function When you're done with ODE, it should just work with this routine fine with no changes in Blitz... Verts are in world space so the orientation of the entity doesn't matter. PLEASE DONT take this routine as gospel though as obviously the Jedive ODE wrapper might be different? |
| ||
It's just the way I'm trying to explain things: When I say visible TriMesh, I mean the Blitz mesh. And when I say the TriMesh geometry, I mean the TriMesh Data used for collisions. At this stage I think I can see what's wrong now. I have the Blitz mesh ;) and the TriMesh aligned to each other correctly. Everything is as it should be, except the collision surface is on the underside of the TriMesh instead of the surface. The mesh I'm testing it with is from the Quadbike demo that was around when Arkons wrapper was first released, the mesh itself is fine (you probably have the same one 002.b3d). All I need to do is figure out how to change the collision surface from the underside to the surface. I'll try that function too, and see if that makes any difference... |
| ||
the reason this happens is the "winding order" of the triangles. Basically instead of going 0,1,2 to make a triangle, you need to go 3,2,1. Your routine for trimesh simply has flipped triangles. Use flipmesh on your mesh, feed the trimesh to ode, then flipmesh again to put it back to normal for blitz. If thats the problem then all you need to do is modify your make trimesh function so the winding order (normals) are reversed.... (to avoid a pointless flipmesh call) ODE uses normals to figure out what way up things are. So changing the way you feed triangles to ode will fix this I suspect... |
| ||
Ok, I'll try that. The exact same thing (collision surface wrong) happened with your function too btw. |
| ||
hmmmmm weird init? that function's fine with Arkon's lib, so I assume he's probably doing a little fixing behind the scenes in his lib. Did you try flipmesh to test if that was the case? |
| ||
Yep, flipmesh corrected the collision surface but it caused that texture/colour darkening weirdness again. |
| ||
Send the lot over and I'll give it a shot here if you like? |
| ||
That code didn't work for me... maybe you made some updates to the dll? |
| ||
How about sending out what we got so far and getting some more eyes on it. |
| ||
Flying, I've just sent the complete test code for you. Wayne, do you want to try it too? |
| ||
When I try it on a variety of meshes, it simply falls through, going to experiement further :) |
| ||
yes, please send me what I need to see the problem. |
| ||
No problem, check your inbox :) |
| ||
Just got home from work and had a bite to rat. I'm checking it out now. Thanks for sending it so quickly. |
| ||
Having a bite to rat eh? What does rat taste like then ;) I'm gonna have to continue my TriMesh quest tomorrow, got to get some zzzZZZZ now. |
| ||
From ODE docs: The Normals argument is optional: the normals of the faces of each trimesh object. For example, ... This pre-calculation saves some time during evaluation of the contacts, but isn't necessary. If you don't want to calculate the face normals before construction (or if you have enormous trimeshes and know that only very few faces will be touching and want to save time), just pass a "NULL" for the Normals argument, and dCollideTTL will take care of the normal calculations itself. http://ode.org/ode-latest-userguide.html#sec_10_7_6 ...So it shouldn't need any normal info at all? |
| ||
That only applies to dGeomTriMeshDataBuild() which isn't implemented into the wrapper yet. This is the one we're playing around with: dGeomTriMeshDataBuildSimple() What concerns me most at the moment is that in Arkons wrapper the ODE TriMesh always stays aligned with the Blitz mesh when positioning or rotating the Blitz mesh using RotateMesh and PositionMesh. I've noticed that once the TriMesh is aligned correctly, changing the 'position' of the mesh with PositionMesh causes it to 'rotate'? Something is still very wrong with the alignment stuff. |
| ||
I think this wrapper was a mistake, and should have not been released until something as obviously important as orientation and trimesh was fixed. Quite disheartening cos VIPER has put in so much effort trying to nail the problems and the problems keep coming! Jedive said he can't look at it for another 2 weeks (15th I think he said). |
| ||
I think this wrapper was a mistake, and should have not been released until something as obviously important as orientation and trimesh was fixed. It was hardly a mistake - bugs are found when you test the product and this is what we do now. You're just too inpatient... Jedive/VIP3R will fix it but it won't happen during the next nanosecond. This is looking good and is more usable than Arkon's was in the end... but I wish they could combine their talents because Arkon had some things right in there... maybe splitting up the cash or something? It WOULD be a shame to have two "almost there" but non-working ODE wrappers in the end. :) |
| ||
TriMesh now works perfectly as it did in the Arkon wrapper. I've had to basically rewrite the whole wrapper though. There are still some errors to nail so I'm going to have to work on those a little longer. I'll keep you updated... Jedive please contact me asap, I understand you are busy at the moment but I'm not spending hours of my time fixing your code only to have my emails ignored. |
| ||
VIP3R, can you email me (my email address can be found from my profile)... I think you have deserved $US10 as well. I did say that if someone would make a working ODE lib I would buy two :) ...To me it seem fair that you get something too. |
| ||
I believe that the ODE code Viper has fixed belongs to viper and should be made opensource as a mark of respect for the pioneering work by ODE authors. The new ODE lib would be free for all to improve on and become the definitive solution for Blitz physics. Jedive released something clearly broken and has chosen to release it at a time when he cannot support it. |
| ||
Nice job VIP3R! I spent 4hr last nite trying to get what seemed like a simple problem resolved. Great to see you nailed it. |
| ||
VIP3R, What Issues are left? let me guess cylinders ?? Will you market a line of skillfully coded ODE demo programs with source code? Send over a working trimesh if you have sometime. Thanks 8) |
| ||
I have made a PayPal donation to VIP3R for his support of this library. I have sent him half them money I made from this lib (which is not too much BTW). For respect to the buyers, I will not made this free. The reason why it were not free at the beginning, is because this is a work I made for Halo, and he was going to pay me for it. Instead of that, I decided to sell it to other people, and the fact is that I have made less money than what he was going to pay me (and now that I have sent half of it to VIP3R, it is even less!). |
| ||
I'm even more pleased! This product is a fantastic buy right now, and would easily be worth double the price. I'm happy we can continue to move forward. |
| ||
Jedive, after it is tested completely, post an ad on the ODE forum, and set up a package for use with DBPro, and you will make more than I offered you. That's what I was going to do, because I know I would make up my own losses that way. Do not ever market anything primarily to Blitz users...just look at what happens to the products that do (Quill3D, etc.) I would also raise the price to around 40 USD. People who need it will pay a fair price, and people who don't will complain no matter what. If you had started at that price, you would have all the sales you got anyways, and three times as much money. |
| ||
BULL[poop] halo. Jedive: what you do is your business: I don't care if you give half the money to Viper or not... that is none of our concern. My concern is that I paid for a library that didn't work like you advertised it to... However because you provided the source, we can try to fix the broken parts and for this I thank you... I hope you will continue providing the source code. |
| ||
You're right, I don't know anything. I've only done $100,000 in sales with my own work. Maybe $2000 of that came from Blitz users. |
| ||
Gentleman, lets move and make this the number one wrapper, and let the kids play with Arkon's wrapper. I'm stoked to get a new update, lets do it guys! |
| ||
$100,000 is fine, cartography shop was it? Thats not a wrapper. Anyway the reason halo is talking utter [poopies] here is because ODE is in actual fact, free. Therefore 10E is a good price for the wrapper, not $40. [*** flying willy: please stop swearing in your posts -- it's against the forum rules -- BlitzSupport.] |
| ||
Quick Update: Things are looking very promising now that the TriMesh works correctly. Issues Remaining: * Re-alignment of the entire ODE geometry. * Capped cylinders don't collide with the TriMesh. * Normal cylinders need checking (they can crash the wrapper). Please be patient, I'm working flat out to correct these issues. I would also like to thank Jedive for his kind donation, which came as a complete surprise :O I'll keep you all updated on the progress... more soon... :) |
| ||
alls well ends well :) |
| ||
C'mon ppl... patience. Nice gesture there, Jedive! Two wise heads are certainly better than zero [my head...]. I'm just glad that this ODE *is* going somewhere, even if it needs two coders. It has been WIP just over *one* week now, so of course it's not "done yet". Blitz3D will really get a "new" life when we can use true physics (that work and are stable). I have some stuff on the pipeline that will show off JV-ODE nicely when it's 100% finished (and my models, which will take some time, but they are far from RBG boxes...). Thumbs up! [edit] Wo-hoo - 200th post on this thread... maybe it's time to lock this and start a new one? It's getting long :) |
| ||
Just sent a mail to BRL to lock this thread and start a new one. |
| ||
Do not pass this point, senor. This way please... http://www.blitzmax.com/Community/posts.php?topic=43468 |