[K]ODE EDITOR Thread 3
Blitz3D Forums/Blitz3D Userlibs/[K]ODE EDITOR Thread 3
| ||
| [K]ODE EDITOR THREAD (ODE Physics VISUAL EDITOR AND WRAPPER) Actual Version: 1.08d Price: 15€ www.lcuriel.arrakis.es/kode/ Latest Version: www.velocitynet.org/kode/kodefull109.zip Ode editor to be used with c++ or blitz3D code. With a very simple editor you can make ragdoll's, vehicle's, and test them inmediately in a Blitz3D window. Then you can export to b3d code (with my own wrapper dll or standard c++ code or Xml-ODE format). The editor comes with the last version of my dll wrapper with working trimesh collision and full set of commands (ray collision, ccylinder, box, trimesh, geom transform,spaces, all joints, etc...). Please check the demos before buy! Cheers, KuRiX! Links to Older Posts: [K]ODE Thread 1: http://www.blitzbasic.co.nz/Community/posts.php?topic=46625 [K]ODE Thread 2: http://www.blitzbasic.co.nz/Community/posts.php?topic=47920 |
| ||
| well i would really appreciate that function kurix. |
| ||
| Ok Clarks. I have just released the 1.08d version of the DLL. The most important change is the new function: KODE_dSetBodyWheel(body,wheelmode) When Setting the wheelmode to 1, the body, in the nearcallback function generates automatically a FDIR1 contact in the direction of the wheel, where the friction directions are calculated automatically within the DLL. This is hard to code, so i really hope you enjoy it! Check emails for links. Cheers, KuRi! |
| ||
| theres a problem kurix, blitz is telling me that it cant find the new function. |
| ||
| Sorry, "typo" problem. Download it again please. Thanks! |
| ||
| ok that fixed the problem. a new problem, it seems as if ode if having problems with sphere to trimesh collisions. the problems seems to occur at triangle edges. |
| ||
| Hehe, the world famouse edge triangle problem! This is a well known problem in the ODE community. I have avoided that problem with correct tuning of ERP and CFM in the contacts. You can tune it in B3D. And if you are using multiple steps per frame, be sure to call dSpaceCollide between them too! And try reducing the time step to be under 0.1 Good Luck. Cheers, KuRi! |
| ||
| my time step is 0.01 fixed, my car wheels only suffer from the problem only at very low speeds and also when the car is not moving, but at high speeds it doesnt happen. next question - whenever two body geoms collide, do the different surface settings really affect what happens. i mean in real life they do, i was just wondering about how ode goes about dealing with them. since youve been working with this for a year, i know that youve learned alot on how to use ode. lets say i have three geoms, a dry track , a wet track and a wheel. now the coefficients of friction for each geom is supposed to affect what happens. now the wheel should more likely slip on the wet track. how do i go about doing this. i looked at the slip1 and slip2 functions but i dont really have an understanding of what its exactly saying. |
| ||
| Well, two questions, two answers :D 1) IT is very strange that you notice that at slow speeds. I only noticed it at high speeds. Try setting erp and cfm to high or low values to see if you need soft or hard contacts. 2) Of course the best way of doing this is changing the sleep of the wheels (the bodies or the geoms) depending on the surface they are. The Slip parameters gives you an amount of force in the perpendicular direction to the friction direction. The best way is to change this depending on the surface and the speed. You can change the friction too, but i have noticed that setting the friction to low values is a bad idea to simulate the snow or wet road. And remember the order of priority when setting frictions and slip's: Body, Geom, General. Cheers, KuRi! |
| ||
| ok - you are talking about correct tunning of erp and cfm, what functions are you talking about. ill take another look at the userlibs, and ode user manual. change the slip parameter depending on the surface and the speed. if i have a road and a wheel, do i set the slip parameter in the road or in the wheel. thats what is confusing me. the force that is generate in the perpendicual direction, is this force supposed to stop the wheel or not. slip1 and slip2, slip1 is the forward direction and slip2 is sideways, i can use the velocity of the wheel and some constants for these parameters. the order of priority when setting frictions and slips, Body, Geom,General. Do you mean that bodies have to get their parameters set first, then geoms. What are the differences in the "Kode_dBodySetSurfaceMu" functions and "Kode_dGeomSetSurfaceMu" functions. Bodies also have geoms so can you use the "Kode_dGeomSetSurfaceMu" for the bodies geoms. thanks for all your help. |
| ||
| ok - i figured the slip1 and slip2 params, i understand them now. but can you still respond to my thread above this one, thanks |
| ||
| Well, regarding the surfaces properties. You can set the mu for geoms and for bodies because in ODE you can have geoms without bodies, but if you have bodies, it is better to set the parameters to the body. The priority means that if you have set a body surface parameter, the rest are ignored, if not, check for geom surface parameters, if not, general config is used. You can select the surface parameter for the body or the ground, but select only one. For example, you can select the global mu to be the body mu, then setting the ground geom mu when necessary. I am planning on making a "Select mean function for surface parameters conflict". And last, about the erp and cfm. There are 4 functions that you should try: KODE_dWorldsetERP KODE_dWorldsetCFM these values are for joint correction, velocities correction, etc... KODE_dSetSOFT_ERP KODE_dSetSOFT_CFM These are the functions to set the contact default erp and cfm. Good values for both are: ERP: 0.5 to 0.75 CFM: 0.01 to 0.0001 depending on the size and masses of the object. Hope this helps. Cheers, KuRi! |
| ||
| you surely have been a big help kurix, thanks alot. |
| ||
| Some ideas I had for KODE: Single large window supporting the perspective view. This would increase the size of the workspace. Allow KODE Editor to support different graphic resolution. Allow KODE to import a b3d or 3ds model to be used as a transparent 3d template. This would help guide to user in creating the physics skeleton. Allow KODE to display model group names, and let user assign group names to physics entities. This would animate the 3d model as the skeleton changes. |
| ||
| i second wayne on his ideas, wouldn't even care if the gui wasn't resized just the viewports in higher resolutions. |
| ||
| Ok, then it is time to work hard on kode again. I will check it to see what can i do :D Thanks for your suggestions. In advance i can say that the resize viewport can be done, and the import as template too. Different Gui Resolutions can be done using different versions of the Executable (this is harder to implement). I will try that too. The animation of the model depending on the skeleton is what i am working now, and it is hard because the different rotations of 3dsmax (and other exporters) and b3d. Cheers, KuRiX |
| ||
| Hi, Good to hear your still working on KODE KuRiX :) Hmmm, I have a problem that I have been messing about with for a while now! I have I very simple car layout. A single body for the chassis without any geom and uses a 'box mass'. There is a wheel on each corner consisting of a body (sphere mass) and geom (sphere), each linked to the chassis using a Hinge2 joint. When I apply force to either the front wheel bodies or the front wheel joint '2' axis, the wheels rotate correctly and move forward. Now, the strange thing is, the rear wheels 'follow' the front wheels perfectly but the chassis body lags behind (moves at about half speed, maybe less)!! I can't figure this out! All the wheels are connected via a hinge2 joint to the same 'central' chassis body, so how can the rear wheels move at a different rate than the chassis itself??? Maybe its something to do with the suspension axis (hinge2 axis 1), but I tried messing with that. But maybe I did not mess with the right bit! ;) Btw, the hinge2 joints are connected in the same way as shown in the pdf ODE manual. Ok, I need a break - been at this for several hours last night and a few more this morning (I must be a dummy I know). I have tweaked masses, joint parameters, global parameters, axis orientation etc - obviously I have not tweaked the right thing yet though!! ;) Any help much appreciated, Rhy :) |
| ||
| Wow, it is the first time i hear from that error. Try Exporting the vehicle.kode demo and changing your code to match that example. Good Luck. Cheers, KuRiX! |
| ||
| Thanks for the suggestion KuRiX :) I had already exported the vehicle demo to .bb and used it as reference. Only difference I can see is I am not using any transform on the body, but I thought this was just to lower the centre of gravity to stop 'tipping'? Anyway, I may try and add that - but not really got my head around transform yet ;) Cheers, Rhy :) |
| ||
| Doh!!! My mistake, nothing to do with ODE!! Rhy ;) |
| ||
| I have been out for 3 days. Now i am going back to work again!. Nice to see that you have fixed your car problem. As you know i have been working with ode cars for 1 year, almost every day, and i am still tunning my params!!! Cheers, KuRi! |
| ||
| Kurix. Haha, I've been tuning for much longer :P As you know, Tweaking the Physics means you need to tweak the cars to substitute. Can be a Pain in the Butt, eh? :D |
| ||
| Now i am fighting to choose the simple step or the double step per frame. Who will win? You never know... xD |
| ||
| Hehe. I doublestep for precision :) Else, you get that wheel-angle-changing thingy :/ hehe. |
| ||
| Ahhh, i fixed that with single step and accurate cfm and erp values! Anyway i prefer double step too! |
| ||
| Ahhh, i fixed that with single step and accurate cfm and erp values! Heh, Increase the stepsize- Its still there :) Out of interest, what values did you give world cfm/erp? I dont get the wheel issues in the new wrappers- But the old one's awful. hehe |
| ||
| Now i am playing with: ERP: 0.5 - 0.6 CFM: 0.0001 :D |
| ||
| Woah, This thread died. What happened. Whats new KuRiX? :D |
| ||
| Hey. I am at vacation time now (in Germany!!!) so i will keep the work when i am back. Now i only have time for checking emails! Cheers All, KuRi! |
| ||
| YAY :D Enjoy yourself Pal :D |
| ||
| hey cygnus hows your engine coming along |
| ||
| Well, i thought it was complete, but then a pile of people reported some bugs :P hahaha. Well, though. Ive got the car handling way more realistic and the AI alot better too- no wobbly cars and better ability to get themselves out of a spin (or at least ensure they come out of one facing the right way :) ) And yours? :D |
| ||
| well i run into major problems with ode, ode just couldnt handle what i was throwing at it. so i took a good look at the user manual and i made some adjustments, and the stability of the car jumped high. now accelerating to break neck speeds happens smooth but the car has a problem when its traveling at speeds higher than about 50 mph. It seems like the slipangle forces are not stabilizing the car so it has a hard time keeping oin a straight line. i dont know if it happens with front wheel drive configuration but i know it happens with rear wheel drive configuration. the braking is also smooth too. a next proble i have is that when doing high speed turning, the wheel move out of position, the outside wheels move closer to the cars x axis, so im working on a way to stop that problem. overall its okay, the car is driveable and i have a simple ai that can drive around my test track. the ai is very simple and goes off of waypoints. as far as the engine,clutch,transmission and dif goes, i halted work on them because i have to make sure that ode can handle some things first. but they are useable and brings a different feel to the whole simulation. i dont know how far ill take it but depending on how everything turns out will depend on what ill do with it. If it turns out good, youll have a demo in your email. i also have other projects on my hand so putting time in is tough, but never the less, good luck to you. |
| ||
| Hmm, clarks- I recently found a method to correct the wheelbend problem better- which actually involved forcing the wheels to "bend" the other way. Purely adding the force to do it didnt work, so i had to literally re-rotate the wheels. I could actually then up the physics speed from 1.0 to 1.6 without seeing any errors, and was able to go straight at stupid speeds. Sadly something happened to that code but yet again, IM sure i could help if/when i recode it- I decided not to use the method purely for the reason that it wasnt required in my code. |
| ||
| Echo echo echo! |
| ||
| adding forces is surely not the best method. |
| ||
| No it isnt. Thats not what i'm donig either- I tried it, but it just plain never worked. im simply setting the wheels rotation speed to 0,0,0, rotating the wheels manually (on top of the normal physics) to cancel out the rotation caused by fast spinning objects, then setting the wheels rotation back to as it was. :) Not perfect, but it worked really well if you really needed the extra speed. |
| ||
| thanks for the input |
| ||
| Anything neu, Lord Kurix? |
| ||
| Hi Cygnus. Not too much time here. Thanks for Asking. I am working on a 1024x768 editor version due to number of requests. Some things have been improved in the DLL and the Editor, but i wait for the new editor to be finished until releasing. I am finishing my multiplayer racing game too, so you will have some great news soon (i hope xD) Cheers, KuRiX! |
| ||
| Sounds great :D Mines been finished for weeks, but we keep pecking at it like vultures. Just made the cars suspension more bouncy so you can see the physics better. Updating its ODE version/wrapper has not happened- We're waiting for Max3D now as writing a nother engine is no longer feasible. May do it for fun anyway, like :D your editor- It should be able to handle different resolutions realy. My screen can only handle 1024x768 properly :) |
| ||
| Any news my friend? |
| ||
| Hey KuRiX, Just out of question, does your Editor let me intergrate into JV's ODE easily or is it designed to incorporate into your [K]ODE wrapper..? Thanks. If I saw better tutorials online that might answer alot of my questions on weither to purchase it. |
| ||
| Well, kode wrapper is very similar to the jv-ode's one, although mine is easier to use, but jv-ode's is more complete. For example, my wrapper encapsulates the world time step and the contact group delete. Anyway they are very similar, because viper and i have been talking about ode several times. So, kode bb exported code could be easily adapted to jv-ode code. For other side, it could be great to make a JV-ODE's exporter for KODE, and then joining forces in the ode battle with viper. What do you think viper? Do you want to develop an exporter for kode? |
| ||
| Sorry KuRiX, I've only just noticed this as I've been a bit busy with the JV-ODE update. I'll certainly have a look at developing a JV-ODE exporter for [K]ODE :) Can you email me with some details KuRiX, thanks ;) |
| ||
| I can send you the struct specification for all the bodies, geoms, meshes and internals, so you only need to generate a .bb file based on those structs and your ode wrapper code! I will send you them later, thanks! |
| ||
| I thought I replied ot this already but it's not here. Would it be a good idea to use something like .xml to define a scene? It's portable and expandible. eg. In my simple file format for 3D scenes I store custom data for each object like 'magnetism'. Presumably with [K]ODE's editor I can't specifiy custom values per object, but with an .xml specification I can parse the data, include my own, and export. I can then still use [K]ODE to make changes if it too supports .xml as it'll just ignor my magnetism tag, allowing me to move objects around and create joints with messing up or losing my custom data. I don't know if the Collada specification is applicable. This is an interchange format for 3D scenes for both offline and realtime rendering. It's supported in the key 3D graphics applications. This would mean you could create scenes in 3DMax and import them into [K]ODE to set properties, or export a [K]ODE scene into Max for editing. Collada support skeleton definition AFAIK, so it ought to be quite simple to import a Max skeleton and create joints appropriately. This could also extend [K]ODE to be a useful editor for all ODE projects where the user has access to an .xml parser. DarkBasic or C++ developers might find [K]ODE useful too, using an existing .xml parser to read the file and create the ODE objects and meshes accordingly, meaning a larger customer base. With a proprietary format people would have to write [K]ODE importer/exporters to get cross-application interfacing. You'd need an importer/exporter for each application, like a [K]ODE exporter for Max. Using an existing standard would negate that. Dunno how much effort it'd be to write the Collada exporter/importer for Bitz, but AFAIK there's already an .xml parser available. If so it's down to the user to create objects based on the tags, so with one change, and .xml/Collada import/export in [K]ODE, everyone can use it. |
| ||
| The XML Export/Import is ALREADY included in the latest version of KODE ;) It uses the XML-ODE format from the java community! |
| ||
| Wow, cool! In which case an .xml parser is all that's needed for use with JVODE, and one's own custom ODE object creation methods. Have you looked into Collada at all? I haven't any Collada capable apps so couldn't help, but being able to import/export into major apps might be very useful for some. |
| ||
| It is the first time i hear about Collada. I have been looking at it now. Looks Interesting... but i think i don't have so much time right now... sorry... |
| ||
| Kurix, I just bought [K]ODE a couple of days ago, and the wheel fdir function you added doesn't seem to be in it. The readme says I have version 1.08 not 1.08d. |
| ||
| Oh my god. You're right! I forgot to send the latest dll to the latest customers!. Please use your user/pass to download the latest patch: www.velocitynet.org/kode/kode108dpatch.zip Sorry Everybody! P.D: The original link is fixed too, so you can download the full version again with the latest patch. |
| ||
| Thanks KuRiX! Great stuff. The link you gave here doesn't work, though, it needs to end in .ZIP, not .RAR! :D |
| ||
| Fixed! |
| ||
| Okay, I have a couple of questions about setting up a car in ODE (who doesn't). I've got the car handling alright-ish, I can work on that, but I need guidance in a couple of areas: 1) The front two wheels, used to steer the car. When one of these wheels strikes an obstruction directly, or the car lands heavily on the front two wheels, they tend to turn in odd directions. To clarify, I understand why they turn the way they do, physically speaking it's accurate. The wheel is striking a wall or road at a certain angle and friction makes it turn on it's hinge. However, since each wheel reacts individually this way, they usually aren't pointing the same way, and it's very easy to knock the car off course this way. The wheels always right themselves again after the impact, but during the impact it's, well, not very car-like. 2) On a similar note, the back wheels will also turn independantly. For example, during a tight turn to the right, the right side wheels may both lift off the ground ever so slightly. This allows the rear right wheel to spin much faster than the left. The two wheels aren't connected, so this makes sense: the one touching the ground is pushing the car, and turns normally, the one just above the ground is spinning freely because there's nothing to stop it. Real cars, of course, have axles connecting the wheels. Any reccommendations on simulating this behaviour in ODE? I'm using the [K]ODE vehicle setup was a base. Or rather, I started with that. The joints setup is basically still the same as that, though. |
| ||
| Hi Glenny. Well, if you are using kode vehicle as setup, the parameters should be right. 1) How are you steering the car? The better idea is to set the histop and lostop to the value you want to achieve using pi angles. 2) There should be no problem leaving every wheel alone, although you can cannot them using amotors (too complex and the result is not far better). If you are having one wheel on the ground and not the other on plane grounds there is some parameter problem... Please let me know if you have any problem! Cheers, KuRi. |
| ||
| 1) Great idea, didn't think of that. I'll give it a go. I'm actually using the steering code from the JV-ODE demo, with some tweaked values. I can't figure out why this problem doesn't happen there. 2)The situation of one wheel being off the ground and another on the ground doesn't occur often, and isn't as much of an issue as the first point, and it doesn't affect the handling of the car much, but it does look odd sometimes during tight turns if the one side of the car lifts a little allowing one wheel to spin up to max speed while the one on the other side drievs the car forward at the usual speed. Thanks for your help, KuRi, I'll have a stab at implementing your solution to 1) tonight! |
| ||
| If when steering you car one side lifts then there is a problem in the mass assignment or you should down the mass using geomtransform... Good Luck! |
| ||
| Okay, cheers, I'll give it a try. Since fixing the steering, it's been quite prone to flipping anyway, so I need to do something about that! |
| ||
| NEW RELEASE: Version 1.09 of KODE has been released. The most important change is the full c++ exporter completed, which is now directly compilable under the standard distribution of ode.org The next version, 1.10 will include the jv-ode exporter and some more adds like more resolutions, etc... To download use the link on the top of the thread. Cheers, KuRi. |
| ||
| The next version, 1.10 will include the jv-ode exporter and some more adds like more resolutions, etc... I will purchase for sure once this is in.I also predict that no one will post in this thread for about 2 months, then the silence will be broken by an 3ch0. |
| ||
| The next version, 1.10 will include the jv-ode exporter and some more adds like more resolutions, etc... so any update??already 2 month |
| ||
| Well, i am very busy now finishing my commercial game with blitz3d, and i am still waiting for viper to give me the jv-exporter, although changing my actual ode exporter to jv-ode should be easy. Damn, i need more time! |
| ||
| Hmm, I thought I'd already emailed you about the exporter Kuri? In fact, I'm almost certain I did. I've re-sent, check your inbox ;) |
| ||
| Ok, Got it now. Anyway, as i told viper, i will think more about the jv-ode exporter, because they are a lot of great functions in jv-ode not supported by my editor. I am thinking of a new version with full jv-ode support (perhaps all the support redirected to jv-ode). Of course this version would be free for "already customers". I need more time right now, because i am very busy, but you will have news soon. Thanks all! |
| ||
| Hows this one going? :-) |
| ||
| One month to release Granada Racer! no time to sleep! |
| ||
| You go man. :-) |
   |