[K]ODE Physics Editor (thread 2)
Blitz3D Forums/Blitz3D Userlibs/[K]ODE Physics Editor (thread 2)
| ||
| Previous thread here: http://www.blitzbasic.com/Community/posts.php?topic=46625 www.lcuriel.arrakis.es/kode/ |
| ||
| Thanks Beaker. Version 1.06 almost finished with some extra tweaks. Sending soon! Cheers. KuRi. |
| ||
| GREAT!! Did you get some sleep :) /Alienforce |
| ||
| KuRiX is this the kinda thing will be able to export ? ODE Homepage: http://opende.sourceforge.net/ |
| ||
| Yes, it is. This is what i am including. The exporter is almost finished, but the importer will be included too. Then a library to load and save directly from Blitz3D will be included too! |
| ||
| Hey people, as you know, i have surface parameters for every body in my dll, but now i am adding surface parameters for every geom. What would you like to do when the surface has been set for two geoms colliding. Do you want me to set the mean of both values?. for example: i have set a wheel a friction of 0.5, then it collides with ice, with friction of 0.2. So? |
| ||
| This is great news :) I am far from an expert, but setting the mean seems good to me (so 0.5 + 0.2 = 0.7 / 2.0 = 0.35). In fact, not sure how else you could do it! Rhy :) |
| ||
| Rhy i have sent you [K]ODE 1.05 again. Have you received it? Anyway i have prepared a web download with user/pass. Next Release will be downloaded in this way :D |
| ||
| Make and example, and let the programmer decide at the point of collision what to set the values at. |
| ||
| Ok, then we have: - You can set global contact parameters, body parameters and geom parameters. The priority order is: - First Body Parameters - If not, Geom Parameters - If not, Global Parameters. So the best way is to set global parameters and geom parameters (for trimesh and static). Then wait for the collision information and set the body parameters as desired, because you can access parameter settings for geom or body in any time. Ok? |
| ||
| Sounds like a winner to me. |
| ||
| Let's take an example to make it easier: Suppose I have a wheel over a road, then the road becomes snowy. g = KODE_dBodyGetCollisionGeom%(Wheel, num%) Will give me the geoms i am colliding at pos num. Then: mu = KODE_dGeomGetSurfaceMu(g) Will give the friction of g. then: mu2 = KODE_dBodyGetSurfaceMu(Wheel) KODE_dBodySetSurfaceMu(Wheel,(mu+mu2)/2.0) You can of course use the "formula" you want. Time to sleep other 4 hours, heheh. P.D: Do not use the above method in a constant way, because you are getting and setting the mu for wheel in a constant way too. It is better to use a global value for wheel friction. |
| ||
| The exporter is almost finished, but the importer will be included too. Then a library to load and save directly from Blitz3D will be included too! Cool! Does this mean that we can then load physics objects just like any other model (.B3D,.X) using import funtion like LoadMeshKODE("blaablaa.kode") without having to include loads of physics creation code that defines the object (to the main code)? What would you like to do when the surface has been set for two geoms colliding. Do you want me to set the mean of both values?. I'd like get two choices, either average or lowest... IMO it would be funny if very sticky (like rubber/tire) and very slicky (like ice) would only result losing half the friction of the tire... I live in Finland and can tell you that you get ZERO friction when you are driving on ice, unless you have very good spiked winter tires... :) |
| ||
| [K]ODE 1.06 Problems. I get MAV on these tutorials. boxedcylinder.kode driver.kode geomtransform.kode :( /Alienforce |
| ||
| KuRiX - yes thanks, I now have 1.05 and 1.06 full versions. I have no idea why I did not recieve the first email (maybe my spam killer - dunno?). Ok, its early here and not been up long and prolly gonna make a fool of myself (not for the first time!). Are the GEOM surface properties stored as 'custom' data rather than actualy effecting the physics directly? Or does setting GEOM surface properties automaticaly affect the contact joint and thereby affect the body? Will we be able to add geom/body surface parameters in the editor at some point? Thanks for all the additions in latest release, KODE is really coming along nicely. Shame the 1280x960 resolution is only for simulation window rather than the editor - boy, was I excited when I first read the update notes ;) But hey, I would have been amazed if you had done it already, I now what a pain GUI's can be :) Nice work, Rhy |
| ||
| Alienforce: Ohhh, sorry, that's true. I forgot to create the custom Data for the dCreateGeomTransform Function!, to work with new surface parameters! I am going to update the 1.06 function Asap, i will name it 1.06b to avoid confusions! I will tell you via email when it is uploaded! (It will be a patch, only dll will be downloaded) Sorry Everyone! |
| ||
| Kurix. Ive tried several ODE wrappers and paid for one. I *may* buy this, Whats different about this from all the other wrappers? what is is strong points? If you can sum up why i should buy this, what advantages i would have using it, then you'll have another customer. Thanks, |
| ||
| Hi Cygnus. This Wrapper is similar to the Arkon's original one. It is easier to use that JV-ODE's, but encapsulate some functions like dCreateWorld that creates all the space, world, and jointgroup and dWorldQuickStep that encapsulates spacecollide, step, and emptygroupjoint. JV-ODE's is more powerful, because let you control more things, like the space to be created. I am not sure which one is better for you. Today the main advantage is the very good trimesh collision that my wrapper has, and of course the editor, that it is very good for making tests of ODE capabilities in a very fast way. I am adding more features to the DLL and the editor almost every day, and the last one has been geom surface contact data. Perhaps you should download the demo, that includes the userlib file to see the available functions... Cheers, KuRi. |
| ||
| Kurix, 1.06b works like a dream!!!! Thanks for your great service!! /Alienforce |
| ||
| Kurix, You seemto have quite a few key functions i need, but i do need access to spaces, this is a key to having 48 cars instead of 8 in the current EngineV2. Although without this, i cant use it for that purpose, I think i'll find this particular tool useful in other areas, as you say, you have trimesh working, and IMO, the editor itself is worth the money. Does the editor export to some standard format that i could read later, say so i could set up my current ode wrapper? If so, its sold. I'm not expecting this export to work 100% because of differences in ODE versions, but it'll be good enough for my purpose :) |
| ||
| Well, it is not a problem to add commands to create spaces and world in separate functions, i will think of it. The exporters include now BlitzBasic, C++ and XODE (XML - ODE). The last one (xode) it is a good standard for ode (not well tested yet), although i think that you can use the exporter to .bb as a base, then changing to the other wrapper shouldn't be difficult. You can see an example of the exported .bb in the first thread of KODE. |
| ||
| Export to BB isnt what i really was looking for although this is a KEY feature i will use. Something along the lines of a .dat file that has world data stored, and perhaps a "loadworld" function include (that i'd modify for my currently used wrapper.) This would enable the ability to "loadlevel(1)" pretty easily from a .dat :) XODE may be the ticked, though i had a simpler format in mind. I'll take a look :) Do you have a demo of the latest build i could try? sounds like you never sleep so alot of stuff would have been added. I'll try it when i'm home later. I'm really looking for a system that suits me, and this could very well be it :) |
| ||
| Well the actual version is 1.06 with some extra tweaks from the actual demo, that it is at 1.05. Anyway, the demo version cannot save or export anything... The XODE format is very good, although i will have to add changes for the blitzbasic users, to include mesh information and more... My next release will have the XODE importer and exporter working... but it will take 2 days at least... |
| ||
| Okay Cool. What if, say, ive got my external media files, and i just want to read a "world setup" file that positions and sets these up? This data format wouldnt need mesh information, just filenames, world locations, parents, physics properties, etc etc. Kind of like its own internal file format :). Then all you would need to do (as i said) is use "loadworld" command with this setup file and it loads all the meshes and positions them for you... If it doesnt have this already, Thered be a ton of uses for it. :) On another note, i'll check my bank account later.. Can't complain at this price :) |
| ||
| Well, i have decided what to do with export/import directly to/from BlitzBasic. I will use the XODE format, with added tags. Then i will make my internal types of public domain (they are very efficient). And last, i will release a loader ans saver that will take the .xode format into the types, containing all physics and mesh information. Then the user can select what to do just looping trhough the types. Release Date of this great feature: 2 days? |
| ||
| Sweet. One last question. Does the XODE format allow you to use external meshes? so i could change one of the files used and without having to go into the editor, the object is replaced in game? Sounds like you sold it ;) but this last feature is very important to me. |
| ||
| The Original XODE doesn't allow external meshes. But i can add this feature to the xode format and the xode community just ignore that tag... |
| ||
| That, would be perfect then :D *adds another ODE wrapper and system to try out to his list* I'll get this the day that system is added :) then i can modify the XODE loader to load with whatever ODE wrapper i choose. As i said, The ability to export in such a way that only references files rather than stores meshes, is one hell of a useful feature for alot of people; Imagine i design a room, with certain objects, but the room's objects can change, but theyre always in those certain places. I'd need to create every single level usually, but if it just references external files, i can just change n swap as i want in code :D |
| ||
| Super, just what I wanted from exporter/importer too :) Did you see my question about geom surface properties earlier? And am I missing something about spaces (@Cygnus). I used NewSpace = KODE_dSimpleSpaceCreate(Space) Geom = KODE_dCreateSphere(NewSpace, MeshWidth(Sphere(i)) / 2.0) Rhy |
| ||
| hmm... Those two are fine. WHat commands are included for collision of spaces? I cant check as i'm at work :/ |
| ||
| @Cygnus: Ah, maybe thats the problem. I 'think' you can only get geom collision info, not spaces. Tbh, I am still learning this so prolly best to wait for an answer from KuRiX or someone more knowledgeable ;) Rhy |
| ||
| I am working on Separation of SpaceCollide from DworldQuickStep. So, all Space Commands will be available. GroupJoint for contact generation will still be part of the DworldStep. |
| ||
| Perhaps for "newbability" you could simple have two quickstep functions, one with and one withour Space commands. In most cases i see why its not necesarry for them to be apart :) (Just thinking of the newbies here....) |
| ||
| Hey Friends, i have not forgotten you! I keep working in the XODE thing and the exporter/importer. The results i am getting are amazing. Working on the new wrapper version too, with optimized callback and support for spaces. Just give me more time please! Cheers, KuRiX. P.D: Meanwhile i will propose a game. Open GeomTransform.kode and try to put all the geoms on the top of the main blue table. Then put here your captures to see the result!. Mine:  |
| ||
| As soon as i can create, save and load a level based on external objects, You shal be my master. (for the editor at least :) ) |
| ||
| Looking forward to support for spaces. Any idea how long it might take ? |
| ||
| The next update is getting big. It will be release very soon. Perhaps today... tomorrow... It will include samples of: - Import/Export in Direct B3D using XODE - Multiple Spaces - More! |
| ||
| Great KuRix, /Alienforce |
| ||
| The Importer/Exporter is Finished right Now!!! Now finishing the dll update. Take Care, because XODE has some limitations (i have resolved most of them adding extensions to the xode format). The bigger is that two bodies cannot have the same name, otherway they will not be linked to the joints correctly. I keep working. Cheers! |
| ||
| i was playing with the editor and it needs work, lots of it. the ode wrapper itself works pretty good from what ive seen. i shouldnt have to select which viewport i want to work in by clicking in its upper left corner, its very annoying. think of a 3dmodeler in which you just click into viewports and select objects, in which you have the ability to zoom in and out of viewports, i should be able to select which object i want to edit by clicking in a listbox, those sphere like objects that appear with an "e" inside of them everytime i create a new object are very annoying. remove the windows ability to maximize because it only stops the application from working. find a new means of allowing the player to edit object properties than the edit tab because they may not only want to change the position and rotation. Consider using a new window to do it that opens up by clicking a button on the tab or by using rollout windows or some other means. I think that using that gui lib are putting some limits on what you can do gui wise. thats all for now, ill play with it some more. i need an ode wrapper myself so you might have a next customer here, ill check out JV-ODE next. |
| ||
| Thanks for your comments clarks. You can select an entity with Menu->Search Entity, then a listbox for you with all entities. I am very busy now with the importer/exporter and new dll, but i will take a look for your advises later. Anyway, i think that 15€ is very cheap for wrapper + basic editor :D Cheers, KuRiX. EDITED: If the maximize button hangs your program, change in the config of KODE the option that says: "Use Scaled Window" :D |
| ||
| Well, Version 1.07 Finished. Check your emails! And please, send me bugs asap! |
| ||
| Thanks KuRix, Will try it asap. /Alienforce |
| ||
| Hey Cygnus, what you asked for should be working, but the demo version cannot export so you cannot test them. If you want some sample code please ask! |
| ||
| now thats just ugly, now that the window can be maximized, the application looks distorted, its just ugly now. |
| ||
| Thanks for the update Kurix. Lee. Blitz-Backdrop IndeED Free IDE |
| ||
| Clarks: Sorry about that, maximizing a GUI lib it is not easy. It is like programming in a visual programming language (such as c++ builder or visual c++). This is easier when programming web applications for example. Well, the Blitzkode.dll is getting very complete now. I have now seen some posts i have not seen before!!!. Like those talking about spaces and getting geom surface properties. The New DLL allows all those things. Multiple spaces, setting and getting some geom properties, and some more new things that the original ode does not have, like the ability of making group of bodies that not generate contact points between them. Cheers, KuRiX. |
| ||
| Thanks KuRiX, I look forward to trying 1.07 out - especialy the XODE importer/exporter and 'spaces'. Thanks for listening to us and working hard on KODE :) Cheers, Rhy :) |
| ||
| Hi Kurix. If that feature is now working, I'd like to see how before i make the purchase, so an example of saving and loading a level from external meshes would be great to confirm if it suits my needs. Email to DAMIENSTURDY a t GMAIL.COM :) Thanks very much And, Keep up the good work. I have to ask.. When the feck do you sleep? :D |
| ||
| SOLD TO THE MAN WITH THE VERY SLEEPY EYES!!!! [edit] Thats me by the way. Tis 1:30am here :) Not to be confused with Kurix, who prolly hasnt slept in weeks :P |
| ||
| Version 1.07 is really a nice hunk of code. Importing, exporting , spaces, sample code and all. Judging from the english comments it looks like you got some quality help. Nice work, I'm off to try some more stuff with spaces. |
| ||
| Cool! I was away for few days, now I just have to find a time to test this new thing... [K]ODE really evolves fast! [G]ood work! |
| ||
| Thanks for the comments!. Perhaps now i have some time to continue the work with the automatic ragdoll creation... Cheers, KuRiX! |
| ||
| now i have some time to continue the work with the automatic ragdoll creation... ... *wavers* *Passes out* This keeps getting better, dunit? No doubt this will be fun :D |
| ||
| Rhy has emailed me about some concepts of multiple spaces. Here it is what i told him: Let's see how a complete but resumed nearcallback works: void nearcallback(void *data, geom o1, geom o2) { if (dgeomispace(o1) || dgeomispace(o2)) { dSpaceCollide2(o1,o2); if (dgeomisspace(o1)) dSpaceCollide(o1); if (dgeomisspace(o2)) dSpaceCollide(o2); } else { // GENERATE CONTACT POINT FOR O1 and O2 } } Then, you were asking about what dspacecollide does and what dspacecollide2 really does. If you call dSpaceCollide(space) then all geoms in the space is tested (their bounding box first) to collision between them. If you have more spaces inside space, those are like geoms, but with bounding box around the entire space. So, suppose we have: Space - Geom Box - Geom Sphere - Space Car The, calling dSpaceCollide(space) will test: - BoundingBox(Geom Box) Vs BoundingBox(Geom Sphere) - BoundingBox(Geom Box) Vs BoundingBox(Space Car) - BoundingBox(Geom Sphere) Vs BoundingBox(Space Car) If the bounding boxes of geom box and geom sphere collides, then the function calls the nearcallback with both geoms. If the bounding box of the geom box collides with the bounding box of the "space car", then, the nearcallback is called with the geom box and the space car. So in the nearcallback we will execute: dSpaceCollide2(o1,o2). dSpaceCollide2 can have as parameters any kind of geom (including spaces). If both geoms are normal geoms, then, their bounding boxes are checked, and called the nearcallback with both geoms if collided. If one of the geoms is a space (suppose o1), then... we check for every object in one space with the geom o2. If both geoms are spaces, we check every geom of o1 with every geom of o2, but NOT GEOMS INSIDE EACH SPACE EACH OTHER. This is why we later call dSpaceCollide with every space again. I hope this helps you a bit. Anyway take care of Spaces. Using Multiple Spaces is only good when you have a big object composed by several objects that are ALWAYS NEAR! (For example a car with its jointed wheels). BAD uses of Multiple spaces are: - Objects that can be separated by any distance. (Bounding Box too big, so always checking) - One space per object (If you do this you will check for its bounding box TWICE!!!). |
| ||
| My use for spaces is with Car wheels, where theres no potential for the wheels of the same car to collide with other wheels in the same space- So i can give each car one space and only collide each car. MASSIVE speed increase when done right. [edit] Okay, maybe not massive.. but its mroe efficient. |
| ||
| Of course, but in my racing engine i have deleted the dSpaceCollide for the same space, because although there is no potential check for wheels collisions, their bounding boxes are checked anyway! Not too much gain, but better than nothing! |
| ||
| because although there is no potential check for wheels collisions, their bounding boxes are checked anyway! Thats exactly what i meant where i wrote "...no potential for the wheels of the same car to collide with other wheels in the same space-" :) |
| ||
| ...but....!! I still don't get why we would ever want to call dSpaceCollide2 from within .bb code? I fully understand its use during the nearcallback function to check spaces where there bounding boxes have collided. But surely calling it from within .bb code is going to be very slow because its checking ALL geoms in any spaces passed to the dSpaceCollide2 function and is NOT using the spaces bounding box ie. you may as well not have used a space! Surely its always going to be quicker to call dSpaceCollide and let it check bounding boxes for you first and then ONLY if bounding boxes have collided call nearcallback which in turn calls dSpaceCollide2? Thanks for your patience, Rhy ;) |
| ||
| But using dSpaceCollide2 won't check for objects in the same space!. So if you have: Space1 = Ragdoll with 100 bodies Space2 = Ragdoll with 100 bodies All objects in the same space: 200x199 checks Two Spaces: 100x99 checks |
| ||
| Yes, I understand that. But.... So if you have: Space1 = Ragdoll with 100 bodies Space2 = Ragdoll with 100 bodies Using dSpaceCollide: 1 check if spaces do not collide Or have I completly misunderstood something?? Cheers, Rhy :) |
| ||
| Of course!, if both spaces are inside one father space, then you call dSpaceCollide(space), and then first you check the bounding boxes, and after that, the dSpaceCollide2 checks for every geom. But this has a problem. Supposing the above nearcallback function (do not suppose too much, that is the nearcallback of my dll :D), then, the callback checks for every geom in the same space. So if you do not want to check this, you use dSpaceCollide2 with both geoms. The best is using both ideas, so call dSpaceCollide(space) and do not check dSpaceCollide(space1) and dSpaceCollide(space2) inside the callback. Perhaps it should be a good idea to add an extra param to the spaces, some like: KODE_dSpaceDisableInternalCollision(space sp1). |
| ||
| Space1 = Terrain and static objects. 8x8 trimeshs with each seperate trimesh being 32x32 quads. Also includes all static objects. Space2 = Dynamic player objects. Space = (Space1 and Space2) KODE_dSpaceDisableInternalCollision(space1) Would this tell ODE that objects in space1 will not be colliding with each other ? dSpaceCollide(space) This would check bounding boxs in space1 (terrain) against the bounding boxes of space2 (players) and upon finding intersections would process the geoms for the colliding bounding boxes ? Thoughts ? |
| ||
| KuRiX, your sig is out of date were at 1.07 now. 8) |
| ||
| Ok, I understand, but.... In your earlier car examples, it works fine when you have a single car space and a single world space which are nearly always colliding with each other. I can see how you can save some time by not checking the car space geoms against each other. However, you will be checking EVERY car geom against the world space, which is fine if they would be colliding anyway. But, if you have lots of cars then you will end up checking EVERY car geom against EVERY other car geom!!! This will be slower (I think) and so better to use dSpaceCollide again (especialy if you can disable internal collisions)?? Even if my maths is wrong, this method can not be faster with multiple cars, only the same or slower - can it? However, I can now see dSpaceCollide2 being useful in a few limited situations, although I can't actualy think of one off hand! Its the fact that it does not check its own geoms against each other (which is what I was missing). I think your KODE_dSpaceDisableInternalCollision(space) is an excellent idea, is it possible within ODE itself or will you be 'customising' your wrapper? This would actualy help my current project (unlike everything else we have been talking about!!!). What would also be nice is to disable collisions between geoms which are 'directly joined' together. So, a lower arm would not collide with the upper arm but would collide with the legs, head, body etc. This is how Tokamak works and, along with built in damping and surface friction, are the features I miss :( But ODE makes up for it with spaces and your excellent editor ;) Rhy |
| ||
| My nearcallback function does not create contact points for joined bodies ;) In the case of multiple cars, the best is to get every car in one space, so you will only check geoms of very near cars, and if we add the DisableInternalCollision function you will have a very good optimization! @Wayne: This is like you say! |
| ||
| Yes, the more I think about it, the better the DisableInternalSpaceCollisons becomes - DO IT NOW!! Do not sleep until it is finished! Ahhh, now I understand why the ragdolls upper arm sometimes clips the body. Nice feature, cheers :) Hmmm, I guess it would be nice to set this by joint!! So, the elbow joint could disable 'connected collisions' but the shoulder joint could enable 'connected collisions' between the bodies it is joining. Clear?? Never satisifed am I ;) Rhy ;) |
| ||
| I am making some tests and ODE does not allow to set user data to spaces... so i am trying to figure how to add the DisableInternalSpaceCollisions Function... |
| ||
| KuRiX, What do you mean when you say, 'ODE does not allow to set user data to spaces' ? What about supporting these ode functions ? dGeomSetCategoryBits (dGeomID, unsigned long bits); dGeomSetCollideBits (dGeomID, unsigned long bits); Maybe simple example too. 8) |
| ||
| I beleive he means that you can not store data (variables) for spaces within ODE, but I believe you can for geoms (or was it bodies?). So, for a geom, you could set data a bit like using 'EntityName' in blitz. If you could set ODE space user data, the data would be transparent to us, the users. So, unless Kurix finds a way around it, he will probably have to use a Blitz type which is set and stored within blitz rather than ODE. Using this method, the data would be visible to us, the users. Right, I have hopefully answered that question correctly, so Kurix has no excuse to stop working on his code ;) Rhy |
| ||
| Yes, so it is. Thanks Rhy! |
| ||
| Well, thanks to Rhy i have detected a very big memory problem with the DLL in version from 1.05. Now it is fixed and you can use the normal download to download again the 1.07 version or check your emails for the link to the dll patched. I have also included a Global setting to choose if check for internal collision for spaces while i find a way to select it individually. Thanks Rhy! Cheers, KuRi! |
| ||
| Thanks KuRix, /Alienforce |
| ||
| :( Sorry to say KurIx, The cylinder is now falling throw the trimesh.... (trimesh.kode) /Alienforce |
| ||
| Yep, this is a very clear case that i need to sleep more. When fixing the memory, i commented some lines, hehe, now they are uncommented, recompiled, and please download the link that i have sent to your emails! Sorry for that mistake :( |
| ||
| kurix, im trying this dll of yours to see if it fit my needs. i would like you to post a demo of a simple cube bouncing on a plane. im just trying to get the hang of it, in other words evaluating. |
| ||
| Kurix, This is great work. payday for me today! Thought id let you know, you, (and every other Wrapper creator) Deserve good reward- I tried working on the Old wrapper last night- Took me 3 days to get it to compile, 5 mins to implement QuickStep- (which is actually slower for some reason) and now, it freezes my system every 5 minutes. /me stumped! I've found this fun, But i couldnt do as much as the people aronud here do- Hah... DworldStep gives me 150-200fps... DworldQuickStep? i get 30fps!!! hahaha... mmm.Maybe i compiled with Debug on.. D'oh :D |
| ||
| As KuRiX is probably still sleeping (I hope!), allow me ;) The easiest way to create your bouncing cube is to use the KODE editor. I am saying this from memory, so not sure of exact button names etc. 1) Create a new entity (this is just a 'placeholder' for everything else - very clever btw). 2) Switch to the edit tab and click Edit button. Use the automatic creation tab and create a large ground 'plane' by using x=50, y=2 and z=50 for example. Click the 'Create Box' button. 3) Create a 'Fixed Joint' and then EDIT its properties. On the 'Main' tab, 'attach' your ground plane to the 'World'. This stops the ground plane from moving. EDIT: Step 3 will work and is a nice introduction to joints <cough>! However, the correct, better and faster way is to create your ground plane as a GEOM only - that is it has no physics 'body' but only a collision 'geom'. Since it has no physics body it can not move ie. its a 'static' object. See posts below for how to create geoms. Sorry about this, I think I forgot you could create static geoms in the editor! 4) Create another entity and then move it above the ground plane (use 'space' to switch between control methods). Create a smaller box using the automatic creation again, something like x=5,y=5,z=5. 5) From the menu, choose 'Setup' and 'Config'. Find the 'Bounce' parameter and change to 0.7 and then change the 'Bounce Velocity' to zero (this disables it). Click 'Save' (or 'Ok' or something). 6) From the menu, select 'Simulation' and then 'Run'. Ta da, hopefully a bouncing cube, which you can also 'pull about' with the mouse if you want too! You could also try rotating the cube and messing with other settings etc. You can change resolution from the Simulation menu if needed. To learn more, try loading some of the .kode examples, they are very good for learning by messing about with stuff ;) I think they come with the demo, if not download from KODE website. Of course, you do not need to use the editor. You can achieve EXACTLY the same effect by coding yourself and using the KODE dll wrapper. KODE is written in Blitz so WYSIWYG. The best way to learn is just 'play' with it ;) Make sure you have read the ODE manual from the website. I posted a link somewhere in the first KODE thread. EDIT: Here is link to ODE manual (PDF download) www.ode.org/ode-docs.html Hope that helps, Rhy @KuRiX - Yeah, the dumb things I have done due to lack of sleep!! Its often better to go to bed and get up early to finish something off, but how often do we actualy do that!! Well, I have kind of learnt that lesson, but then I have the luxury of working full time on my coding projects so don't have to burn the midnight oil anymore. It still takes quite a bit of discipline to stop what I am working on some times and go to bed, but always better in the long run :) |
| ||
| Wow! Nice Tutorial Rhy!. But hey!, you don't need to use a fixed joint to make static geoms! You just use the automatic creation then go to the Body Tab and Unselect the "USE BODY", so you will have static geoms, with fast solver and stable as trimesh (or even more!)! These geoms do not need the mass value. Thanks! @Clarks: What kind of demo do you want? executable? blitz basic code? kode file for the demo? :D |
| ||
| Doh! Yes, your absolutly right KuRiX - I don't think I got enough sleep last night (or maybe I went too bed too early and got too much sleep)!!??!! I would usualy just create a GEOM on its own and not use the automated box thing at all for a static object. Hehe, oh well, think of it as an introduction to joints ;) Rhy |
| ||
| ahaha :) Yeah. Last night i got a 2Am bedtime. Pain in the ass init? I found a problem in my car engine that meant it should have crashed from the day i placed the feature, so i never got to bed at 11.. hehe.... Kurix.. no matter what we ask for on here.. sleep is important- Otherwise you wont be able to think about how to add things :) |
| ||
| Just to say, KODE 1.07C works like a dream :) The dSetInternalSpaceCollisions(mode%) is excellent. Great work KuRiX, Rhy :) |
| ||
| dSetInternalSpaceCollisions(mode%) If this does what i think it does.... This just keeps getting Better and Better!!! |
| ||
| Thanks for your words, i see how my editor and wrapper are getting great pieces of software, and in some way is thanks to my customers, the best beta testers! Hey Cygnus, i will read your email slowly later and if you want we can chat at some irc channel. Is there any official Blitz irc channel where we i can enter and answer your ode questions? |
| ||
| Hi Kurix. I dont use IRC, but i'm sure i wouldnt mind trying. I may have Mirc somewhere... I wont be around today though. Any help you can offer is apreciated of course! |
| ||
| i don't use it neither, but it is a good day to have a fast multi user chat :D |
| ||
| Well, you can always find an unused irc channel and let people know what it is. Of course, this can always be hijacked at a later time unless you actualy register it (dont ask me how to register, I dont know!). And, yes, I would log in ;) I have another feature request ;) Would it be possible to include a dSpaceGetNumGeoms function. If you think its a good idea, can you give me an estimated time for it to be included. I am not being cheeky, but I need to do this for my current project and so if its gonna be too difficult or take too long then I will keep track of it myself within .bb code - but would make more sense to use the ODE command if possible ;) Cheers, Rhy ;) |
| ||
| Hehe, you will have that function for today! (well, i hope..). Cheers, KuRi. |
| ||
| God Save the double post... :( |
| ||
| Your a star KuRiX :) But hey, don't rush it in just for me. I can wait until tommorrow ;) Seriously though, I can wait a few days until your next official release! |
| ||
| Rhyolite-thanks for the tutorial but i should have stated that i wanted it in bb source to save you the trouble. Kurix-i would like to see this in bb source. Can someone please send me the ode manual in pdf format. i using firefox and for some reason its not showing the manaul. Cllkgs@... thanks |
| ||
| @Clarks: You need to downlaod the PDF viewer for Firefox or better still 'right-click' the link and 'Save link as' and then you have it on your hard drive and can open it with Adobe Acrobat Reader (if you have it, if not do a search and download the free viewer). |
| ||
| thanks Rhyolite |
| ||
| Directly from 1.01 Version of KODE so you can compile it and test it with the demo version of KODE. A bouncing Box for Clarks: |
| ||
| thanks alot kurix |
| ||
| well testing is going good so far and im getting pleased. i wish that you had put a longer limit on the demo but nevertheless everything is working great. Some more testing and ill tell you if ill be your customer. |
| ||
| Hi there! I have added a function to create trimeshes from "loadanimmesh" and any other parented entities. It will be included in the next version (1.08) that add some commands to the DLL and fixes some entity movement issues in the Editor. Cheers, KuRi! |
| ||
| COOLIES :D I'd just like to add that i cant really see the red too much on your website.. All i see at first when looking is: "KODE Costs only and comes with a full DLL Wrapper for Blitz3D and direct exporter to BlitzBasic Code or C++ Code." Lol :) |
| ||
| Just so you know: there is a #blitzbasic IRC channel at irc.blitzed.org Use MIRC or click here: www.playerfactory.co.uk/irc.php |
| ||
| Hey Beaker! Thanks!. I will be on that channel this afternoon, if anyone wants to chat about ODE. Well, afternoon here is in 2 hours! :) |
| ||
| Hi! I have just released the 1.08 Version of KODE. The most important changes are with the Wrapper, where i have included (due to popular asks) lot of functions to access spaces, geoms data, etc... Check Emails for download link and versions.txt to read the changes!. Cheers, KuRiX! P.D: I have forgotten to include in the versions.txt that i have added a function to create trimeshes from loadanimmesh!!! |
| ||
| Thanks KuRiX - very nice update. Just make sure you update the dll in your game/app folders!! Rhy :) |
| ||
| OK, so I'm thinking I'll be buying into this one at some point in the next week or two. However I want to make a vehicle simulator. It's mostly about having another medium for my 3d models as I am sick of not being able to have the animations working on them due to sim writers not being interested in supporting those small features which bring the models to life. I know a few other model makers who feel the same, so I'm going to see what I can do about it. I've bought blitz3d recently and I'm really rusty, but I also want to find a way to make it all happen so I'll get back into it I guess. What else will I need to use to get a sim together? And are there any 3rd party systems that this system pre-dictates I use, or avoid for that matter. I'm liking the look of Giles etc to help out with making it all look reasonable. I want to be able to use directx as that provides a viable, and almost pleasant workflow for me and I also use lightwave exclusively to provide it. Initially I want to model traction engines, and have steering courses etc. Other vehicles types could well follow as I already do planes and other flying stuff. I quite like boats too. Some level of net play would be nice too I think for compos. I'm a fair model maker but a very rusty and not that great programmer, I don't seem to be able to find a vacant coder of talent and enthusiasm (unless you're reading this, in which case please speak up!), but needs must, so I'll do it, probably quite badly, and definitely rather grudgingly! ;O) I want to use a variety of cotrollers inc FF wheel and pedals etc. Any advice? |
| ||
| I believe ODE is well suited to vehicle sims. You do not NEED anything else, but you may WANT to buy other things to make the job easier, faster or better looking etc. Check out the toolbox page on this website (which I guess you have already done). Yes, Giles is an excellent lightmapper and basic world builder. TerraED is good for terrains, but may or may not be what you want. TerraEd uses 'Blitz Terrains' which are different to normal meshes, not better or worse, just different. BlitzPlay is good for networking but costs, their are some others too. You may want to consider a GUI system and a single particle effects system. You can write them yourself, but will save you a lot of time. These are just suggestions based on my own research and purchases ;) Blitz3D supports .X format (DirectX), but most people try and use the native .b3d format. Reason, because as I understand it, Blitz3D does not support all the features of .X and conversely, .X does not support all the features of Blitz3D! However, you can use .X but you may want to consider if their is a .b3d exporter available. EDIT: http://www.blitzbasic.com/sdkspecs/sdkspecs.php Your project sounds quite large, especialy if you want cars, planes and boats in a single simulator AND network play! I hope you know what you are letting yourself into, especialy the network side of things are gonna be pretty tough. Blitz can support multiple joysticks which is how most driving devices are implemented, so you should be fine (after a bit of experimentation with each device). Their is a dll to add force feedback support to blitz. http://www.twinno.com/ffplugin/ My main advice would be to design a simple prototype involving simulating a single 'simple' vehicle driving over some bumpy terrian. This will help you get an idea of the work involved and the general requirements of the project. Then try adding in one of your complex vehicle models and get all those 'small features' working ;) It does sound an interesting project and I myself love simulators (I am currently working on a flight sim type game). However, I am really only interested in commercial projects as I need to feed my family (hopefull independant developer speaking!!!). Perhaps post in the general Blitz3D forum for volunteers? But be aware, most volunteers are very enthiuastic for the first few weeks then 'dissapear'!. All the best, Rhy :) |
| ||
| Rhyolite> I believe ODE is well suited to vehicle sims. You Rhyolite> do not NEED anything else, but you may WANT to buy Rhyolite> other things to make the job easier Absolutely! Rhyolite> Yes, Giles is an excellent lightmapper and basic Rhyolite> world builder. TerraED is good for terrains, but Rhyolite> may or may not be what you want. TerraEd uses Rhyolite> 'Blitz Terrains' which are different to normal Rhyolite> meshes, not better or worse, just different. I am used to getting SRTM data into a mesh and using that as DX object I was hoping to continue in that way as I am more comfortable with it like that. Rhyolite> BlitzPlay is good for networking but costs, their Rhyolite> are some others too. You may want to consider a Rhyolite> GUI system and a single particle effects system. Rhyolite> You can write them yourself, but will save you a Rhyolite> lot of time. These are just suggestions based on Rhyolite> my own research and purchases ;) Is that ALL wrapped up in blitzplay? Not heard of that one yet, must find out more I guess. Rhyolite> Blitz3D supports .X format (DirectX), but most Rhyolite> people try and use the native .b3d format. Reason, Rhyolite> because as I understand it, Blitz3D does not Rhyolite> support all the features of .X and conversely, .X Rhyolite> does not support all the features of Blitz3D! Rhyolite> However, you can use .X but you may want to Rhyolite> consider if their is a .b3d exporter available. I don't think there is for lightwave, so I'm not sure if that's an option at present, would be nice to have a choice though. Rhyolite> EDIT: www.blitzbasic.com/sdkspecs/sdkspecs.php OK, shall check it out. Thanks Rhyolite> Your project sounds quite large, especialy if you Rhyolite> want cars, planes and boats in a single simulator Rhyolite> AND network play! I hope you know what you are Rhyolite> letting yourself into, especialy the network side Rhyolite> of things are gonna be pretty tough. Oh if I was up for all that from day one I'd be quite mad. I presently make models for one which does all that, well planes and ground vehicles with minimal boats and netplay and another that does just boats, and I'm finding I have just outgrown it as a model maker. Developer does not seem to be interested in polishing the product. Says they are, but no code is ever forthcoming to back up the words. Waited a year, and time is now up from my view point. However it sounds like the networking is something which is far from straight forward and this almost defats the point of even trying, so I'm glad you mentioned that. I was more concerned that the physics and animations was going to be the the major sticking point. I think ODE should nail the physics and more particularly [k]ode and there are plenty of other solutions to all but the network side by the looks of things at this stage of research. Rhyolite> Blitz can support multiple joysticks which is how Rhyolite> most driving devices are implemented, so you Rhyolite> should be fine (after a bit of experimentation Rhyolite> with each device). Excellent, a bit of a bonus that one! Rhyolite> Their is a dll to add force feedback support to Rhyolite> blitz. www.twinno.com/ffplugin/ Thanks, interesting. Rhyolite> My main advice would be to design a simple Rhyolite> prototype involving simulating a single 'simple' Rhyolite> vehicle driving over some bumpy terrian. Actually that's the main plan, the extra vehicle types is a bit of a pipe dream and might be more likely to happen as AI background eye candy. I would really imagine going for separate sims for different vehicles that the user actually controls. Rhyolite> This will help you get an idea of the work Rhyolite> involved and the general requirements of the Rhyolite> project. Then try adding in one of your complex Rhyolite> vehicle models and get all those 'small features' Rhyolite> working ;) Yes, it's just so that things look right instead of disjointed and low quality and even plain missing. Rhyolite> It does sound an interesting project and I myself Rhyolite> love simulators (I am currently working on a Rhyolite> flight sim type game). However, I am really only Rhyolite> interested in commercial projects as I need to Rhyolite> feed my family (hopefull independant developer Rhyolite> speaking!!!). I've no problem with commercial! Not so far anyway! ;O) Rhyolite> Perhaps post in the general Blitz3D forum for Rhyolite> volunteers? Yes, wondered about that, but there could be some issues there..... Rhyolite> But be aware, most volunteers are very enthiuastic Rhyolite> for the first few weeks then 'dissapear'!. That was the main issue! ;O) It's not so different from the problem I have with the present developer really. The biggest problem seems that I am trying to do something different, and that means most utils don't really fit quite right. Most would say what I am doing is eye candy, well maybe, but since the consensus seem to be that this is a sin there are not so many tools that will go all the way down that road. Sure I guess it is eye candy mostly and that's not as bad as some would tell you. Producing a "showcase medium" for good 3d modelling is not that much of a sin after all. There's plenty of model makers out there who would actually like and probably pay for a good showcase like that to extend the functionality of the models they have spent an awful long time making in many cases. The desire to do that is pretty easy to understand. Not everything has to be crash.turbo.frag.the.hell.out.of.land ;O) Thanks for some very useful info. Sorry I seem to have wibbled a bit, oh well I'll shut up now! |
| ||
| Hi all!. I have been very busy. Just one note about BlitzPlay. I bought it some time ago and i must say it is a really good piece of software, but the developer (Surreal) has dissapeared, and BlitzPlay has some little bugs (i have fixed most of them personally). So be careful! Cheers, KuRi! |
| ||
| KuRiX, What do you "prefer" to use for creating land mesh so far? |
| ||
| Land Mesh? If you use ODE you can use a trimesh of course. I have not used terrains too much, but i prefer making my maps in 3dsmax or other editor then exporting and loading as trimesh! If you have any more questions, ask! cheers, KuRi. |
| ||
| OK, cool I was just trying to organize my intended work routes for data. I prefer lightwave and also can use directx as an export route which seems to mostly leave my data intact. Just looking for more options to try out and see if things can become even easier to route into [k]ode. Blittz/[k]ode is an new one for me so I may well be missing several points quite possibly. |
| ||
| Does [k]ode let you export a b3d of the scene data (with embedded/hidden physics data)? You could then load the b3d and parse it to setup the physics, thus making it less language dependent. |
| ||
| Hi Beaker. At this momento the export to b3d format is not supported. I didn't know i could include extra parameters in the b3d format. Anyway, the xode format include the model parameters and the physics parameters. Cheers, KuRiX! |
| ||
| Keep it up Kurix. Hows it going? Any screenshots of that car game you mentioned ^.^ |
| ||
| Hey! I put some screenshots in the gallery some time ago. Now we have the real maps and more advanced engine. We hope to release it in 2-3 months! Cheers, KuRiX! P.D: There was some minor bugs with the last wrapper. Now they are fixed in the 108c patch available. Check your emails for the link. Thanks! |
| ||
| *finds screenie* http://www.blitzbasic.com/gallery/view_pic.php?id=923&gallery=&page=3 That looks feckin awesome! Demo? ;) |
| ||
| Nice screenie - looks good :) Keep up the good work with KODE, Rhy :) |
| ||
| Kurix - remember the bouncing box demo that you posted, it doesnt work now. I read the ode manual and rewrote it but collisions dont work. Can you post an updated version. |
| ||
| forget, by looking in the importer folder i found out the problem. i wasnt calling dSpaceCollide, nice one kurix, i blame that on you. |
| ||
| Nice One! Cheers, KuRiX! |
| ||
| Hi again Friends. I have recorded a small video of my kode-racing engine. The video is to show the new friction mode and perfect trimesh collision, so all the visual elements are off (not speed meter, not single surface particles, not IA, etc..). Hope you like what you can be done with ODE and B3D! www.lcuriel.arrakis.es/kode/koderacingdivx.avi Enjoy! |
| ||
| this one goes to kurix and cygnus and anyone else who can help. ok heres the thing, i made an engine that plugged into arkons ode wrapper, and i got some good results. the engine is no where complete. arkons wrapper had some problems, and freezing was one of them. so i bought kurix wrapper. Now i want to continue work on my engine, but im not going to if i cannot get the results i want from kurix wrapper. im aiming for a car simulation, and the cars are going to be powerful. I ran some test to see how kurix wrapper would respond to what i was going to throw at it. these are test. accelerate the car to speeds in excess of 200mph - pass( the car was stable) brake the car from speeds in excess of 200mph - failed( the car was not stable) turn the car at 10mph - passed( the car responded quite nicely) turn the car at 20mph - failed( the car flipped ) - unrealistic, a real life situation that would not happen. ---------------------------------------------------------------------- im using cylinders for my wheels, and im wondering if spheres would be better. kurix, im also wondering what kind of inertia equations youre using in your wrapper and if they are the right ones. how did you guys achieve good stability? when it comes to surface against surface, like wheel against dry road and wheel against wet road, do you store coefficient of friction with the road or wheel. I tried storing them with both and the results failed. One problem might be in how ode handles some things, like set the mu for a surface and set slip1 and slip2 makes no sense to me. I read the manual, but i need someone to clear that up for me. I really need some help on this, its really bugging me. Its holding me back on what i want to achieve so please, please, please help. |
| ||
| Well, making a car simulation with ode can be very well done, but it is not as easy as you can think. You need some tricks: - Low the body mass using geomtransform to raise the chassis - Change Friction FDIR1 to the correct friction vector with high rotation wheels (this is hard to do, but fixes the brake problem). - Implement Stability bars, or at least some kind of angular dumping. - Use good friction coefficient, depending on the dimension of the cars, the masses, etc... - Set ERP and CFM to good values - Much More! I have been developing racing engines with ode for almost a year, and i must say that you will need lot of tunning to fit your needs. The best option is to use Spheres for the geoms, because they have good trimesh collision and are very stable. Use Cylinder Mass anyway if you want. I am still tuning my engine to fit the new maps we are designing. If you have more questions do not hesitate to ask here! |
| ||
| kurix - i looked at your advice, the spheres gave me more stability, i also went deeper into the whole simulation and i can now get the car to turn at 130mph with stability so thats good. (- Change Friction FDIR1 to the correct friction vector with high rotation wheels (this is hard to do, but fixes the brake problem)) i looked at the functions in the decls file but saw not one that allowed me to do that. i used Kode_dContactSetMode, and used dContactFDir1 and the wheels just spinned and the car didnt move. the ode user manual doesnt really help. |
| ||
| The problem is that FDir1 must be set correctly in the nearcallback, during contact generation. I am thinking on including a ODE_dbodysetwheel function that set this automatically for those interested :D Cheers, KuRi! |
| ||
| Kurix - time to make a new thread with links to this one etc in it. Once you've done it I will lock this one. |
| ||
| Done. Thanks Beaker! |
   |