JV-ODE Physics Thread 4
Blitz3D Forums/Blitz3D Userlibs/JV-ODE Physics Thread 4
| ||
| The JV-ODE user library contains almost all of the ODE functions wrapped inside a DLL. The library can be used in any programming language that supports DLL's, including Blitz3D and BlitzPlus. The functions have been adapted to use euler angles (the same coordinate system as Blitz3D), however functions for accessing quaternion angles are also included. The download contains all of the necessary files to get you started, including some simple demos showing various ODE objects and TriMesh collisions. To view more information and screenshots click here. Options are now available to purchase the wrapper using either PayPal or Share*it. The restricted demo version is now available for download here (185KB) Have Fun :) Previous JV-ODE Threads: 1 2 3 JV-ODE Player Factory Forum Useful Links: ODE.org Website - ODE User Guide (PDF) - ODE User Guide (HTML) - ODE Archives |
| ||
| Oh man, Now I really feel like a dweeb. been testing for over 2 hours on using Transalations lol and you come along with...Oh just add ONE here LOLOL...Many thanks.... I never thought of checking the CarStart Global, not even thinking of realizing it's also used in the wheel setup ;) Now I finally got a bounding box half alphaed for testing that lets me ram, slam, flip, and generally cause mayhem with the model to make sure it's to size Topknot ;) P.S. BTW VIP3R, thanks for your sponsorship, you've been added to the Sponsor tagging ;) |
| ||
| You're welcome :) |
| ||
| Hey VIP3R or anyone else into this, Is there a site, location, or docs on setting up vehicles? Seems that since I change my Geom up higher now all my previous settings are trash, including having to pump Gravity up to 2.20 just ot keep the dang thing on the driving surfaces..:( Tried googling and reading over most of ode.org, but not seeing alot of community chit chat on things like this. Granted the Car demo's work for what they are designed for but I'm guessing I'm missing out on many more factors yet used that might stabilize this do-hicky..;) Here's the example now just to keep it on the up right: Global CMass# = 125 Global WMass# = 8 Global WorldERP# = 1 Global WorldFriction# = 124 Global HingeTorque# = 24 Global SuspensionHS# = 0.009 And the Car Setup for reference:
Global ode.ODEGeom = New ODEGeom
ode\body = dBodyCreate(World)
Car = ode\body
dBodySetRotation (ode\body,0,0,0)
dBodySetPosition (ode\body,0,CarStartY+1,0)
mass = dMassCreate()
dMassSetBox (mass,1,4,2,8)
dMassSetBoxTotal (mass,CMass,4,2,8)
dMassTranslate (mass,0,-3,0)
dBodySetMass (ode\body,mass)
dMassDestroy (mass)
ode\geom = dCreateBox (CarSpace,4,2,8)
CGeom = ode\geom
dGeomSetBody (ode\geom,ode\body)
ode\mesh = LoadMesh("Truck02.b3d") ;CreateCube()
TruckTex = LoadTexture("Truck03.png",4)
CMesh = ode\mesh
ScaleMesh ode\mesh,.12,.12,.12
RotateMesh ode\mesh,0,-180,0
PositionMesh ode\mesh,0,-1,0
EntityTexture Cmesh,TruckTex
EntityShininess Cmesh,.3
Topknot ;) |
| ||
| I don't work with cars so can't offer specific advice. What I can see is a WorldERP of 1.0. That's how much bounce is aplied when an ODE object passes through a surface, to restore it t the right place. This typically ranged from 0.1 to 0.8 (according to the manual). Hige values mean more bounce. If your applying a world ERP of 1.0, that'll cause a bit of bouncing in my experience (especially without a low CFM). I've has a sphere roll down a plank onto the floor and bounce of it unrealistically as a result of setting these values wrong. I suggest you try a word ERP of 0.2 or 0.1 and reduce the gravity back to where it was, to see what effect that has. Even if nothing, changing the gravity to get your objects to work properly is asking for trouble. It means more downward force, faster falling objects, more penetrations and more errors. |
| ||
| Can someone tell me the best way to disable an ODE Body so it doesn't react to collisions or forces, but it's geom still acts? I want objects that move around at first but can come to a standstill on contact with other certain objects, and when they do no amount of force will move them. dBodyDisable() won't work because the moment the object is hit it's enabled. I'm thinking maybe moving the object into a different space could work somehow, but I can't see how to do it. Seems if there's a body object it has to partake in collisions. The other alternative is to delete the body, but I might want to be able to have the object moving again which would require creating another body, all of which sound a bit awkward. Or can I destroy the Contact Joint of a disabled object to stop being automatical updated? Or create a Fixed joint to hold it on the spot, but can't these be overcome with powerful forces? As the manual says... The fixed joint maintains a fixed relative position and orientation between two bodies, or between a body and the static environment.(~ sounding perfect ~). Using this joint is almost never a good idea in practice (~ boo ~), except when debugging. If you need two bodies to be glued together it is better to represent that as a single body. |
| ||
| This is great! I will be purchasing this! One suggestion though VIP3R, I am reading through the documentation and it doesn't seem to have a way of returning what objects collide with what. For what I will be using this library for, I would need to know if an object collides with something (to play a sound), is this possible? |
| ||
| Yes that's possible. Use the dGeomCountCollisions to get how many collisions there are, and then for-next loop through each collision with dGeomCollisionGeom() to find which geometry it hit. Then loop through your geometries to find which object has that Geom value to find eactly what game object it was. |
| ||
| Hey Shifty, try setting the body to a geom of zero. This will let the geom as static geom and the body will no react no collisions... Not sure, but you should try! |
| ||
| Nice idea Kurix, but it cause crazy wierdness to happen. A totally different unrelated object started dancing the Polka when I used dGeomSetBody(temp\geom,0)! Ona related note, at the moment I'm just testing to see if I can stop an object at the right time with dBodyDisable(). Trouble is the object stops having penetrated the other other object. I'm creating a magnet that's applying a powerful force accelerating the object towards it. This object gets faster and faster. I tried capping the velocity with bx#=dBodyGetLinearVelX(UI_object\body) by#=dBodyGetLinearVelY(UI_object\body) bz#=dBodyGetLinearVelZ(UI_object\body) b#=Sqr((bx*bx)+(by*by)+(bz*bz)) debug_vector\x=bx debug_vector\y=by debug_vector\x=bz debug_float=b If b>MAX_SPEED b=MAX_SPEED/b dBodySetLinearVel(temp\body,bx*b,by*b,bz*b) EndIfbut the force applied with dBodyAddForce() seems to apply to the force after the speed reduction. I guess in the QuickStep process the force become velocity. Do I need to work out a cap on the amount fo force to add when I apply it (ugh!!). Can I somehow force an object to be positioned at the point of contact before disabling it, instead of disabling it on the Collision when the object has passed through the magnet? The Simulation corrects these errors of interection when it runs normally. Is there, or could there be added, a way to process the object's individually to corrent such intersection errors using the techniques already employed by ODE? Like a sort of 'step one iteration for just this object to position it on the outside surface of the collision geom' function? |
| ||
| Kurix : Actually you may be right about setting the geom to 0. The crazy polka my objects were dancing was because I was applying forces to the wrong objects! |
| ||
| You could disable the objects after the time step and before applying new velocities... In fact, an object should be always non penetrating other object after a time step. The problem could be that one step is not enough not aviod the total interpenetration... |
| ||
| @Dark Half: JV-ODE has extra unique functions for getting detailed collision information, so as Shifty mentioned it's definitely possible ;) @Shifty: KuRiX's idea sounds good to me (attaching the geom to world (zero)). Does it work when you do this? Thanks very much for the help KuRiX ;) JV-ODE Update I'm currently building and testing V1.08 of the wrapper, so you should all have a new version to play with very soon :) |
| ||
| Excellent on the update VIP3R, any clues to what's in it..? ;) @Shifty Geezer: Thank you a ton....it works wonders adjusting the WorldERP.! Now to readjust all my values to match again ;) @Dark Half: DUDE, definitly worth the $$$'s. As frustrating as it is to learn it's a joy to enjoy ODE in your proggys. And JV-ODE has proven to be my top choice. Oh an excellent support ;) Working with car values is a sure hair puller lol.. BTW guys, small question: Does it matter the size of the tri's that make up your mesh for the ground area, meaning if you scale a mesh to larger sizes the tri's are bigger, or is it better to model the ground stuff to actual size where the tri's are smaller? Thanks. Topknot :) Oh and on that detecting the mesh it's colliding with, any change of a simple example to tell if your on a plane or a trimesh..? I got a particle system in place and having different particles based on which material your driving on by using a cheap Blitz sphere with internal blitz collisions parented to my mesh to detech which surface it's on, but it's not able to update as fast to the material it's on. Example: Driving on ground or dirt, you get dirty particles puffing up and such, and when you hit the water it changes to water sprays and such. With my current mode of detection it works but if you'll smoking fast it delays until you slow to a craw then the contact is made. Wanting to also use the internal ODE collisions for faster detection. |
| ||
| Triangle Size Matters!. Too small or too big triangles would case inter-prenetation or too bouncy surfaces |
| ||
| I don't know abuot tri sizes. I know if you have a vertex collision with a vertex rather than triangle you get funny reactions, so I guess less triangles is a good idea to have less vertex collisions. |
| ||
| Two things I've found out mainly: 1 - Too big a scale and spread of the tri's and you can have issues where a geom plops below the surface. 2 - Major reactions to friction if to bouncy, lots of slippage and odd results. Espically strong edges at higher velocities..;) Just wasn't sure if it was a written by-law of ODE lol.... |
| ||
| The new update will have a new surface contact option and a bug fix for the sphere mass functions. Most of the demos will also be tweaked slightly due to the new sphere mass fix. You need to experiment a little more Topknot, the detailed collision demos show you everything you need to know when detecting whether you're colliding with a plane or TriMesh. All you need to do is add the TriMesh identifier to the collision checking. You shouldn't need to use Blitz collisions as the JV-ODE detailed collision functions will work fine there ;) |
| ||
| Just paid for it earlier today ;-) Haven't had the chance to mess with it much (outside the demos), but it looks really promising! Keep up the good work there guys, you have a loyal supporter here :-) |
| ||
| Post some code Shifty and I'll be glad to help. |
| ||
| Was warming to that path of the Force VIP3R...;) I know use "Newer" peeps can be frustrating lol but hey ya learn by hours of expermenting. But since you brought that up. If I wanted to leave tire track marks on the mesh surface, should I: 1 - Use a simple Linepick from the two rear tire dummy objects and lay sprites down..(althou now I got a slew of issues with alignment and correct orentation. 2 - Is there a way to use the geom's or such to pinpoint the spots under the tires to use for feeding values to a sprite function. 3 - Or is there some simple solution I'm not aware of, all thought welcomed. @Dark Half: Good move, you won't be dissapointed once you can get your head around the whole ODE setup and workings. @KuRiX: You mentioned in a past post you use Gile[s]..Is this a world mapping style program that;s not a mile high learnnig curve to use, and can you generate world style areas, ie Road tracks and inclusive environments instead of me 3dMax'in my guts out with building.? I assume the b3d exporting lets one use it with the ODE mix. Or whatabout "3D World Studio ". Also VIP3R, this PacerMaker, is it using your ODE stuff and is it a good tool for intergrating game aspects to mix well with the JV-ODE.? I want to spend some money and not sure which to invest in. Thanks ;) |
| ||
| Hmm, I'm not sure what the best method for adding tyre tracks is to be honest. I've seen a few related threads in the Blitz3D Programming forums, if you can find them they should give you some good ideas. You can get the geom positions of the wheels with dGeomGetPositionX(geom), dGeomGetPositionY(geom) and dGeomGetPositionZ(geom), using this info you can then work out the position of the skidmarks. You can also get the orientation of the wheels using dGeomGetPitch(geom), dGeomGetYaw(geom) and dGeomGetRoll(geom), then using this info you can align the skidmarks with the wheels. I'm not sure which way would be best to align the skidmarks with the road surface though. Yep, PaceMaker uses JV-ODE, it's an amazing animation tool. There's a demo you can try here... www.goddysey.com |
| ||
| If you're placing Blitz meshes where the ODE geoms are, you can get all that info using Blitz functions. EntityX/Y/Z() for position etc., and I think Blitz can find a point on a texture map. You can get physics info from the Geoms like rotational velocity. |
| ||
| Here's an example program for magnetism for people (Wayne!) to have a nose at. Hit <spcae> to turn on the magnet. Cursor keys let you change view. When an object hits the magnet it's deactivated (geom set to no body) and turned blue. This example is all blocks. From line 92 where the objects are created you can select between all blocks, spheres, or a mixture. With blocks and spheres they hit but penetrate a little into the surface. Line 113 has an option to double the size of the blocks. When big they hit the magnet but don't get deactivate, but also don't penetrate. Probems to solve are to stop any objhect penetration, and to ensure all objects stick regardless of size. An extra feature wouldn't shouldn't be too hard is to have objects get deactivated when they hit any magnetised object. The ultimate feature would be to have objects slide around other magnetised objects towards the centre of magnetism. Also in the code, but disabled above, is code to limit the object's linear velocity. When using powerful magnets over large distances the acceleration becomes extreme and the objects can just fly through the magnet. In real life wind resistance limits top speed and reduces acceleration as the object gets faster. Not sure how to emulate this is ODE. I'm not after a full air dynamic model, but to limit top speed . In the above example I've capped the maximum force applied by the magnet which seem fairly realistic in results. |
| ||
| Giles is basically a lightmapper. It is for creating very realistic and easy lightmaps. As world editor is not as powerful as others... The very big advantage with giles is that you can lightmap multiple objects with just one lightmap! |
| ||
| Hehe, real nice magnetism example Shifty! :) |
| ||
| Ewww I feel all "sticky" hee hee. neat example. Changed it a bit to turn the maggy on and off to sling object around ;) VIP3R, the PaceMaker, is it mainly for Raggy dolls, or could you set up any ODE style objects, ie cars, cranes, stuff like that? Any everyone, any good suggestions of a solid World Editor to purchase, trying them out but with Demo's you get no ability to save or export and test the playability. Topknot ;) |
| ||
| To build any kode style object you can purchase mine: KODE (visual ode editor with exporter and wrapper). but it is not really powerful as world editor. Check the toolbox to see if any world editor fit your needs... |
| ||
| VIP3R : I've changed the magnetism function a bit to check collisions with magnetised objects. I'm showing level of magnetism by turning the objects blue. If the magnet is surrounded by magnetised (blue) objects, other objects hitting those blue objects also become magnetised and turn blue. I cycle through each of the collisions and for each collision geom, cycle through the array of objects to find that object with a matching geom. Only it doesn't work, and I can't find why. |
| ||
| [edit] Removed incorrect collision detection info |
| ||
| Won't counting collisions count all the clutter to clutter collisions though, as long as their in the parent space (which they are)? The only object in a subspace is the floor which I don't want to check for anyway. |
| ||
| It doesn't work like that unfortunately :/ [edit] Removed incorrect collision priority info The standard collision functions are filled by the collision data of geom1 and the sub-collision functions are filled by the collision data of geom2. So when they switch and geom2 takes priority, no data gets passed to the standard collision functions. |
| ||
| If I use dSubGeom... nothing happens to any of the objects. None of them turn blue. If I duplicate the tests and apply it to both normal and sub spaces it's no different to not using the Sub functions. I vaguely understand what you're saying, but I don't understand to code for it! I also removed the second Space. With everything running in only space it still doesn't work :( |
| ||
| Nope, it can't be that then. I'm trying to understand the logic, but I'm a little confused. You only seem to be checking for a collision with 'magnet\geom', so where are you checking for the collision with non-magnets (other boxes)? |
| ||
In psuedo-code
For n = each clutter object index
Count collisions
For each collision
collision_geom=object collided with
For o = each clutter object index
test if clutter(o)\geom=collision_geom
At this point o is a reference to the Array index that holds
the ODEGeom object whose \geom matches Collision_geom. n is the current ODEGeom object.
Stop magnetised objects
IF collision_object is the magnet
apply the magnetism, turn clutter(n)\mesh blue
ELSE
We've hit another clutter object. If this clutter(o) object is magnetised, magnetise clutter(n)That's what this bit of the advance_simulation function is supposed to be doing...
; Per collision processing
If dBodyIsEnabled(clutter(n)\body)
numCollisions=dGeomCountCollisions(clutter(n)\geom)
If numCollisions>0
; For each collision, test if with magnet
For m=1 To numCollisions
collision_geom=dGeomCollisionGeom(clutter(n)\geom,m)
; Get object that is parent to collision geom
o = 0
Repeat
o=o+1
If o>NUM_OBJECTS
Exit
EndIf
If clutter(o)\geom = collision_geom
Exit
EndIf
Forever
... deactivation code...
If collision_geom=magnet\geom
; Collided with magnetic object
EntityColor clutter(n)\mesh,255-(clutter(n)\magnetised*5),255-(clutter(n)\magnetised*5),255
clutter(n)\magnetised=clutter(n)\magnetised+1
Else If o<NUM_OBJECTS
If clutter(o)\magnetised>0
clutter(n)\magnetised=clutter(n)\magnetised+1
EndIf
EndIf
Next
EndIfThis doesn't look like an ideal solution. It tests every collision, but really I only need test if object 1 has collided with object 2 once. I ran it with only two objects and got I think 20 collisions of a flat box against box. Another example would be wanting to play a sound based on the different properties of the colliding objects. Say we've got a field Volume in our ODE_object type, along with mesh, body and geom fields. How would you write a routine to play a sound for each collision at an average of the volume field of the two objects, being sure to only play one sample for a collision even if there's lot of contact joints for two touching objects? |
| ||
| Hmm, are you trying to fathom why the outer objects (which don't touch the magnet) don't turn blue? Because that's what I thought you were trying to figure out. About the sound, do you mean play it every time step? |
| ||
| Yes, but it's the same problem. I want them to turn blue. They turn blue when their magnetism parameter increases in value. Every time they hit another object that has a magnetism parameter greater than zero, their own magnetism value goes up. The reason they're not turning blue is because when they hit another blue object, I'm failing to read it's magnetism parameter. If we ignore my specific problem and current solution that might be really bad, let's try a more general problem, let's try the sound one. For a test for each frame, each time step, what would be the code to achieve the following... Type ODE_Object Field mesh Field geom Field body Field volume End Type Dim objects(20).ODE_Object Populate our array with 20 objects and have them move randomly around. For each time step : For each object, objects(n) Find the geom it has collided with Find the ODE_object in the array with this geom, objects(m) Play a sound at the volume of object(n)\volume+objects(m)\volume / 2 If this is working, it's not difficult to change it to different responses like objects(n)\volume=objects(m)\volume, or IF objects(m)\volume>5 THEN object(n)\volume=2, and from this working I can make the objects turn blue or magnetic or bouncy or whatever. |
| ||
| Lol, Shifty I was just making sure I'd understood what you were looking for ;) I've found the problem (again) :P Replace this section of code... I've labelled the edits with '*****'. All I've done is comment out the 'geomsetbody to zero' line. Also, I've added another entity colour function to make the boxes that don't touch the magnet turn blue, how is the first one going to make them turn blue when it only detects the MAGNET collisions? This is what I was trying to work out earlier. The 'geomsetbody to zero' prevents the collisions from working, hence no detection and no magnetism increase. That's your problem right there. |
| ||
| Ah. So it was working, just I wasn't actually including a line to turn it blue. Oops :D |
| ||
| Grrr :) |
| ||
| Okay, after a fair bit of looking I'm still confused! I couldn't get it working right, until I added both dGeomCountCollisions() and dSubGeomCountCollisions() etc. But I'm only using one space. It seems as though to test for collisions you have to ALWAYS use both the normal functions and the Sub functions. Is this right, and if so, why? Does ODE create subspace fields (and inverse Tachyon pulses while we're talking StarTrekese) for some collisions? |
| ||
| Shifty, The CarDemo DetailedC seems to only use one Space and yet register full collisions with both the Plane, ramp, and all the other objects being assigned to space (Space) Althou the contact with the sphere's and cylinders is quick is does register hits, and it's just using the dGeomCountCollisions routine. |
| ||
| Though it is working differently. It's only reading the first collision fo rthe car and wheels. It's not checking every collision between every object. Dunno how much difference that mkaes, or what that is particularly. It seems to me that with multiple collisions between multiple objects dSubGeom...() works where dGeom...() doesn't. Unless I'm still doing things wrong! |
| ||
| Hmm, I'll look into to this because I can't stand having two sets of collision detection functions. I'm going to see if there's a way of incorporating them all into the one set instead. I did try this before, but couldn't seem to get it to work properly. |
| ||
| @Shifty: Ok, I've spent many hours looking into this problem. It was really difficult to work out because the ODE docs etc provide very little info on this (or none whatsoever), which just makes it even more confusing. But, I have finally found how ODE 'prioritises' the geom order when creating the contact joints and filling the detailed collision data. It's actually calculated by geom/space bounding box SIZE. Also, it applies to single spaces too! Here's an example of the situation with a single OR multiple space... In the Car Demo, the car body is smaller than the static Blue Block. If you collide the car body with the Blue Block, the collision data is detected by the standard collision functions for CGeom (car body), as seen in the detailed collision demo. Now, if you get the collision data for the Blue Block during the same collision, because the Blue Block is larger than the car body, it fills the data into the SUB collision functions and not the standard set. To put it in a nutshell, when two geoms collide (in single OR multiple spaces)... The standard collision functions are filled using the data from the smallest geom of the two. The SUB collision functions are filled using the data from the largest geom of the two. This leaves us with two problems... 1) We can't use a single set of collision functions, meaning both sets of collision functions must be used in both single AND multiple spaces. If you omit either, you will not retrieve all of the available info. I'm going to have to figure out a clean way of processing the collision data using both sets. 2) The detailed collision function names are misleading and will need to be changed. I would recommend something like the following... dGeom1CountCollisions(geom) replacing dGeomCountCollisions(geom) dGeom2CountCollisions(geom) replacing dSubGeomCountCollisions(geom) ...and so on for each detailed collision function. Any thoughts or suggestions welcomed :) |
| ||
| What a crazy way to deal with collisions!! Why seperate them into big<>small and small<>big? That seems a very arbitary and pointless distinction. Why didn't they just group all collisions geom1<>geom 2 and be done with it? Still, now we know we can work with it. Thanks for you time working this out. I'm okay with your 1 and 2 naming system as they're each 1 of 2 steps that need to be made. |
| ||
| After thinking about it, I suppose it makes sense to do it that way. It looks like ODE processes the largest object collisions first, then processes the smaller objects. I guess it would be much faster to do it that way, so I can understand why they do it. A JV-ODE user has identified a memory leak when using ccylinders and TriMeshes which could potentially be serious. I've managed to find the problem and it looks quite easy to avoid. I'll finish off the testing to make sure and post my findings later. |
| ||
| Any idea when abouts 1.08 will be released? |
| ||
| I'm aiming for 08 Nov, but if I run into any snags it may get pushed back a bit. There's quite a bit of work to do on the dll (including testing), the function ref will need updating and most of the demos need tweaking. The detailed collision demo will probably need a total rebuild too. The memory leak mentioned earlier looks like it's caused by any ccylinders being created (or falling through and getting trapped) beneath a TriMesh. If you're suffering memory leaks with ccylinders and TriMeshes, check to make sure none are stuck/created underneath your TriMesh. |
| ||
| Looking forward for the update. On another note, been reading alot lately trying to get knowledgable with building up for working with cars etc.. One thing I notice in anothers project was that they seem to be taking into there car physics alot more variables from the ODE: SetSoftCFM(cfm#) SetMotion1(motion#) SetMotion2(motion#) SetSlip1(slip#) SetSlip2(slip#) Just to name a few. So in assuming there is alot more that can be "plugged" in to assist the simulation along, but the answer is which and in what manner best. So is there any links or docs or standards for car coding..? So far my values greatly outmatch the cardemo's and the (i assume) need to have gravity at -0.98 is not happening due to everything just turning into a hyper Moon Buggy drive from Never Never Land. ;) Now I'm not sure if this or if ODE has a relation to actual MESH deisgn as in SIZE. I am working on an almost 1:1 scale, in Blitz I don't have to do a single scalemesh call due to modeling the different object to eachother. Of course I then have to wonder if using a certain scaling does have an influnence on the ODE's workings. Any ideas on this or it's a non-issue? Topknot ;) OHHH P.S. I got a little function finally tweaked to lay down sidemarks on the mesh aligned to it's vectors but be it from me to figure out yet how to limit the placement, i.e. If you power brake and smoke the rear tires then you could end up laying 100's of sprites all in one spot until the life# values cycles thru the types to delete them. Also any ideas on how to align the sprite, it's a rectangle to match to turning direction of the wheel? L8r'z ;) |
| ||
| Real Earth gravity is closer to -9.8 which you can use if you like. You should divide your mass values by 10 and alter your time step value if you change the gravity to this value though. The reason -0.98 is used, is that it provides a more stable (less jittery) simulation. It has nothing to do with scale and everything to do with mass. I've already told you the functions needed to align the skidmark sprites with the wheels... dGeomGetPitch#(geom) dGeomGetYaw#(geom) dGeomGetRoll#(geom) ...or you can use the equivalent blitz entity commands on the visible geoms ;) |
| ||
| If you use the Blitz command you can post in the main forum and probably get a lot more experience on the matter. Probably a lot more people out there having already done drawing to texture in their projects who don't use ODE and won't see your question here. |
| ||
| Been Testing many ways to get a nice huge tack style object in and: 1 - If I load as "LoadMesh" then it creates the trimesh fine. 2 - If I load as "LoadAnimMesh" to keep the clusterizing in place and keep the poly count very trimmed, it loads but the trimesh fails to produce. I know it's probably not possible to use Option #2, but then it sounds like I'm stuck filling the screen with tons of undeeded tri's to render when it's actually behind the player's FOV. not sure if this makes sense what I'm asking but just seeing if ODE it limited to single mesh types or can I expand on it. BTW thanks for "reminding" me again VIP3R..;) Just so you don't think of me as a complete pain in the ass here's how I used it.! ; ################################################################################################### ; # Place Fake Car Shadow on Terrain Mesh ; ################################################################################################## Function PositionShadows() FIndGround = LinePick( EntityX(Cmesh,1), EntityY(Cmesh,1), EntityZ(Cmesh,1),0,-200,0) AlignToVector shadow, PickedNX(), PickedNY(), PickedNZ(),1,1 AlignToVector shadow,-PickedNX(),-PickedNY(),-PickedNZ(),3,1 PositionEntity shadow,PickedX(),PickedY()+.1,PickedZ() RotateEntity shadow,90,dGeomGetYaw(CGeom),0 End Function |
| ||
| You could create a TriMesh for each frame of the anim mesh and tile them as needed. I don't think the tri's outside of the FOV would be rendered. Work on the V1.08 update is coming along nicely, I need to finish off the testing and it should be ready for release very soon ;) |
| ||
| Yea that is my goal (not to render the tri's outta FOV). And only using AnimMesh to load a clusterized mesh that's broken into chunks. Excellent news on the update...Thanks for your time in doing it ;) |
| ||
| JV-ODE Version 1.08 Released Please check your inbox :) IMPORTANT: It has been necessary to make some changes to JV-ODE that -may- affect your projects. If your project uses either the mass functions or the detailed collision functions, you should read the following notes to see whether you need to make any adjustments to your code. Mass Setup Changes Firstly, it has been wrongly assumed (mainly thanks to the sparse ODE docs) that both the dMassSet****() and dMassSet****Total() functions are needed to setup the mass on an ode rigid body. In actual fact only one of these functions is needed to set the mass based on either the density or total mass. How to correct your code: If your code was using both mass functions as follows... dMassSet****(mass,density,x,y,z) <- REMOVE dMassSet****Total(mass,totalmass,x,y,z) Or... dMassSet****Total(mass,totalmass,x,y,z) <-REMOVE dMassSet****(mass,density,x,y,z) ...to keep your existing physics setup without disturbing your mass settings, simply remove the first mass set function, as the first function is cancelled out by the second. This applies to all mass set functions: sphere, box, cylinder and ccylinder. A problem has also been identified with the dMassSetSphereTotal() function, which was internally calling the ODE dMassSetSphere() function by mistake. How to correct your code: As only one of the two functions was actually being called ( dMassSetSphere() ), the simplest way to keep your existing physics setup without disturbing your mass settings, is to use the dMassSetSphere() function only. You do not need to adjust the mass/density value if you do this. Alternatively, if you would prefer to use the dMassSetSphereTotal() function, you will need to adjust the total mass value as follows... Old settings: dMassSetSphere(mass,10,4) dMassSetSphereTotal(mass,10,4) New settings: dMassSetSphere(mass,10,4) <- Keep existing mass value Or dMassSetSphereTotal(mass,2680.83,4) <- Requires new mass value The new mass value for the dMassSetSphereTotal() function is calculated as follows... ((4.0/3.0) * Pi * 4*4*4 * 10) = 2680.83 NewMassValue=((4.0/3.0) * Pi * radius*radius*radius * OldMassValue) Many thanks to Shifty Geezer and Wayne for their help with this issue :) Detailed Collision Changes It had been previously thought that only the standard set of detailed collision functions would be needed in single space simulations and both sets for multiple space simulations. However it has been discovered that both sets are needed for both single and multiple space simulations. Due to this, the detailed collision functions have been renamed as their current names were misleading. The detailed collision functions are now renamed as follows... dGeom1CountCollisions(geom) replaces dGeomCountCollisions(geom) dGeom2CountCollisions(geom) replaces dSubGeomCountCollisions(geom) ...and so on for each detailed collision function. All of the changes have been updated in the JV-ODE Function Reference. How to correct your code: Just replace the old function names in your code with the new ones, their functionality remains the same. Please note that if you're only using the standard set of functions in your single space simulations, you may need to add the second set of functions to retrieve all possible collision data. Generally the dGeom1* functions will return data from collisions with larger objects, and the dGeom2* functions will return data from collisions with smaller objects. The 'CarDemo-DetailedC.bb' demo has been completely rebuilt with both sets of the new detailed collision functions to show this. It also has a much cleaner collision processing function than the previous demo. Thanks again to Shifty Geezer for highlighting this problem :) Other Stuff A new contact surface mode has been added to the dSetInternalContactSurfaceMode(mode) function. The new mode allows JV-ODE to use the minimum surface properties only during a collision. More info is available in the JV-ODE Function Reference. A new demo 'CarDemo-TriMesh-X4.bb' has been added to show multiple TriMesh use with the dSetInternalSpaceCollideMode(mode) function. Remember to update all of your existing JV-ODE files, including the demos, media, docs, 'JV-ODE.dll', 'JV-ODE.bb' and 'JV-ODE.decls' files. Many tweaks and changes have been made for this update, so some of the older files may not work as expected. Thanks everyone :) |
| ||
| Thanks for the update, and all your efforts. Much appreciated. Funky Frank |
| ||
| Many thanks VIP3R. Delivered on time and under budget - a rarity for software developments! My fans are working sensibly with spheres now. I'll look at my friction functions and rejig them to work with spheres properly now. Regards the dSetInternalSpaceCollideMode() function, is there a way to assign this to different collisions and attributes? Like in a collision between a rubber ball and icy floor, use the maximum of Bounce values and minimum of friction values? |
| ||
| Thanks VIP3R, Will try the new changes with my existing project. BTW, something I came up with that might solve the resetting of the CAR after it either flips or if you just want to use it like a handbrake. Replace your "Hit Space" code with this: If KeyHit(57) = 1 Speed# = 0 CarYaw = dGeomGetYaw(CGeom) CarPitch = dGeomGetPitch(CGeom) dBodySetRotation (Car,CarPitch,CarYaw,0) End If In a more normal Gravity world, ie I am using the standard -9.8 in my project so far to good results, it will reposition the car to the last facing directon and kill all forces that the car was under at the time. also seems to function as a cheap man's handbrake also. Topknot ;) |
| ||
| Cool - updates are always welcome! Now I only need time for programming... :) |
| ||
| Thanks all :) Regards the dSetInternalSpaceCollideMode() function, is there a way to assign this to different collisions and attributes? Like in a collision between a rubber ball and icy floor, use the maximum of Bounce values and minimum of friction values? It is possible, there would need to be either new functions to set each individually or a flag system. But it would come at a cost - speed. Each of the 10 properties would need to be conditional, adding a lot of overhead to each time step. Btw, you meant the dSetInternalContactSurfaceMode(mode) function ;) I'm still a bit confused why the alternative contact modes would be used tbh. In real life, wouldn't the icy floor and rubber ball values be averaged when they collide? It wasn't a problem to add them, but I need to make sure it doesn't affect the quality of the simulation for those that aren't likely to use them. Let me know how your testing goes on the new wrapper Shifty :) Thanks for the code snippet Topknot :) |
| ||
| Not sure about the numbers of a reallife response, but from personal experience I know Rubber bouncyball has high bounce and high friction Ice has low bounce and low friction Bouncyball will bounce on ice when dropped Bouncyball will slip on icy when pushed Hence in the contact the bounce is the higher of the two, and the friction is the lower of the two. I don't think an average works out because the material properties aren't just restitution and friction, but hardness features in there somewhere too, and maybe some other properties that I can't think of right now. ODE uses an approximation to cover physics responses without trying to emulate real-world responses, and some of these real-world responses seem t be outside the current scope of ODE. As an example situation, there's a slippery plank above the ground that's slightly inclined, and a rubber cube placed at the higher end. With the plank ultra slippery gravity should cause the cube to slide slowly off the end, hit the floor and bounce really high. If the floor is icy too, with little bounce, then the cube won't bounce as high as it should, and if the rubber if really...um...frictionary, the cube won't slide. Off the top off my head a puzzle game like Pushover might find a case of this situation. Such features probably won't be used by most people who I imagine don't go to great lengths with material properties but just use basic settings. Perhaps it's something you should get official feedback on to see if it's worth your while including? A performance hit would generally be bad as ODE is fast and we definitely want to keep it that way. Maybe an optional trade-off of performance vs. functionality would be welcomed though? I don't know what other JV-ODE users are after. |
| ||
| Pushover? the ant thing from the Amiga days? that was a classic! :) If I can add more functionality to the wrapper, I'm all for it. I'll have to give it some thought and do some tests to see how bad the speed hit would be. I think I can still keep the default option at the same speed though, so that it doesn't affect any other users who don't use it. What would you need ideally for each property? mean/min/max or just min/max? Obviously the two would be faster than all three. Thinking from another POV, if you had access to these functions, how would you setup each individual object? You would still need to evaluate each object to say whether it uses mean/min/max properties. Wouldn't it be very similar to making 'fake' adjustments to their default surface properties to get the correct response? If you can do it that way, there would be no further speed hit. Would you be able to create a very simple demo, showing something like the slippery plank situation you mentioned above? With a few notes describing what you would expect it to do, like the height you expect the bounce to be when the rubber block falls of the plank and hits the floor. That would be a great help :) |
| ||
| VIP3R, Thank you for many jv-ode Updates. The BlitzSupport can cut a thickness slice of you off. |
| ||
| Thinking from another POV, if you had access to these functions, how would you setup each individual object? You would still need to evaluate each object to say whether it uses mean/min/max properties. Wouldn't it be very similar to making 'fake' adjustments to their default surface properties to get the correct response? If you can do it that way, there would be no further speed hit. Would you be able to create a very simple demo, showing something like the slippery plank situation you mentioned above? With a few notes describing what you would expect it to do, like the height you expect the bounce to be when the rubber block falls of the plank and hits the floor. That would be a great help :) Thinking about this, there may not be a clear solution. My recent friction calculation functions were to find the friction required to allowing absolute friction against a surface of zero friction. Let's say I've a sphere with friction 1000 that get's perfect traction when it hits a floor of 0 friction. When spinning and dropped onto tthe floor the sphere should skid off. Now let's say we want to add an icy slide that the spinning sphere would slip down. It would have zero traction, fall off, land on the floor and have 100% traction and spin off. But both the floor and slide are set to zero friction, so we're wanting two different response with the same settings. I don't think two variables is enough to define the different responses. Maybe a specification per contact joint for which response to use is required? Let's say that the Collision function is called to populate the collisions array... dSpaceCollide(space, world, group) Then using dGeom1CountCollisions etc. we can go through these collisions one by one, and using something like dGeomCollisionSetSlip1(index, value) we can overwrite existing default values. Then dWorldQuickStep() through uses the new values. eg. We have our super friction ball spinning fast and landing on a super slippy inclined plane. When it hits, dSpaceCollide() uses the specified values to set Slip1 for the contact as the average of the ball and plane. Going through all the contacts individually we can look for instances where the ball has hit the plane and for each one, set Slip1 to 0. When the ball lands n the floor, again the floor is super slippy, but we leave the contact joint alone so it uses the default average. Such a system would be as flexible as any user wants it, allowing comarisons and custom calculations for responses, without slowing down the ODE process. In my case where I'm only dealing with a dozen objects I can afford a few comparisons and calculations per hit, whereas someone else could just stick with using the default responses. Hmmmm. I'll knock up a demo sim with some TYPEs to show how this might work. |
| ||
| Here's an example with a commented out routine that could deal with friction on a per-object basis. Hit 'INSERT' to add spin to the ball. The plank and floor have mu=0.0, and the sphere has 100% friction derived from my algorithm posted earlier. The idea is to be able to apply spin to the ball while it's on the plank and watch it slide down. The commented out VIRTUAL CODE shows code to select a collision and decide on the frictional value to use. I've invented a function name dGeomSetContactMu(geom, index, val) which would do this. Run this sim as it is and you see the moment you apply rotation to the ball it rolls up the slope, despite the plank having zero friction, which we don't want. Whereas it rolls on the floor when we apply rotation which we do want. If you uncomment the FRICTION CODE you'll see I've included a dGeomContactSetMu() function depending on which object is hit. This creates the correct wanted response - slides over plank of friction 0 but grips on floor of friction 0. however this is setting the object's entire mu for all collisions. Two similar spheres of high friction should grip with each other even when slipping down the slide, so changing the whole object's mu is incorrect. That's where a function to set per contact properties would open up all sorts of fun things. |
| ||
| You're welcome Barton :) Cheers for the info and demo Shifty :) I've been looking at what it would take to add per geom mean/max/min contact surface properties, it could get very messy to say the least. If this can be done via the Blitz code, it would be the better option IMO. however this is setting the object's entire mu for all collisions. Two similar spheres of high friction should grip with each other even when slipping down the slide, so changing the whole object's mu is incorrect. That's where a function to set per contact properties would open up all sorts of fun things. To solve the sphere to sphere friction problem, couldn't you just add it to the geom checklist and change their properties as needed based on what they're colliding with? Wouldn't a function in the wrapper to do this have exactly the same issues? |
| ||
| Changing the object's mu isn't going to work on a per-collision basis as I understand. This is what I'm think happens in ODE... 1) dSpaceCollide() determines all collisions and creates contact joints for each. These contacts have certain properties like mu which is given a value of the mean of the two colliding objects. 2) dWorldQuickStep() changes the position of objects based on their forces and joints affecting them. For each contact joint it calculates a force and applies it to the bodies involved in that collision. If we have a sphere of friction of 1000 hitting a surface of friction 0, dSpaceCollide() creates a contact joint contactjoint1 dSpaceCollide() contactjoint1\mu=(1000+0)/2 dWorldQuickStep() apply resistance force to geom based on contactjoint1\mu = 500 (is this the Slip1 value?) With the per-object mu changes I'm guessing this is what happens FRAME 1 dSpaceCollide() contactjoint1\mu=(1000+0)/2 set sphere geom's mu to 0 dWorldQuickStep() apply resistance force to geom based on contactjoint1\mu = 500 FRAME 2 dSpaceCollide() contactjoint1\mu=(0+0)/2 set sphere geom's mu to 0 dWorldQuickStep() apply resistance force to geom based on contactjoint1\mu = 0 We get a one frame lag between setting friction to 0 and the calculations in dWorldQuickStep() using a friction value of 0, and we also see that only one mu can apply at a time. If we have spheregeom1 and spheregeom2, both of mu = 1000, and floorgeom mu=0, with the two spheres touching each other while sat on the floor... FRAME 1 dSpaceCollide() contactjoint1\mu=(1000+0)/2 - spheregeom1+floorgeom contactjoint2\mu=(1000+0)/2 - spheregeom2+floorgeom contactjoint3\mu=(1000+1000)/2 - spheregeom1+spheregeom2 for each contact if contactjoint1 then set spheregeom1's mu to 0 if contactjoint2 then set spheregeom2's mu to 0 if contactjoint3 then set spheregeom1's and 2's mu to 1000 dWorldQuickStep() apply resistance force to spheregeom1 based on contactjoint1\mu = 500 apply resistance force to spheregeom1 based on contactjoint3\mu = 1000 apply resistance force to spheregeom2 based on contactjoint2\mu = 500 apply resistance force to spheregeom2 based on contactjoint3\mu = 1000 FRAME 2 dSpaceCollide() contactjoint1\mu=(1000+0)/2 - spheregeom1+floorgeom contactjoint2\mu=(1000+0)/2 - spheregeom2+floorgeom contactjoint3\mu=(1000+1000)/2 - spheregeom1+spheregeom2 for each contact if contactjoint1 then set spheregeom1's mu to 0 if contactjoint2 then set spheregeom2's mu to 0 if contactjoint3 then set spheregeom1's and 2's mu to 1000 dWorldQuickStep() apply resistance force to spheregeom1 based on contactjoint1\mu = 500 apply resistance force to spheregeom1 based on contactjoint3\mu = 1000 apply resistance force to spheregeom2 based on contactjoint2\mu = 500 apply resistance force to spheregeom2 based on contactjoint3\mu = 1000 Mu for each sphere would be based on the last collision. Hence no mu=0 response for the contact with the no-friction floor. If we deal with the sphere<>sphere collision before the two sphere<>floor collisions FRAME 1 dSpaceCollide() contactjoint1\mu=(1000+1000)/2 - spheregeom1+spheregeom2 contactjoint2\mu=(1000+0)/2 - spheregeom1+floorgeom contactjoint3\mu=(1000+0)/2 - spheregeom2+floorgeom for each contact if contactjoint1 then set spheregeom1's and 2's mu to 1000 if contactjoint2 then set spheregeom1's mu to 0 if contactjoint3 then set spheregeom2's mu to 0 dWorldQuickStep() apply resistance force to spheregeom1 based on contactjoint1\mu = 1000 apply resistance force to spheregeom1 based on contactjoint2\mu = 500 apply resistance force to spheregeom2 based on contactjoint1\mu = 1000 apply resistance force to spheregeom2 based on contactjoint3\mu = 500 FRAME 2 dSpaceCollide() contactjoint1\mu=(0+0)/2 - spheregeom1+spheregeom2 contactjoint2\mu=(0+0)/2 - spheregeom1+floorgeom contactjoint3\mu=(0+0)/2 - spheregeom2+floorgeom for each contact if contactjoint1 then set spheregeom1's and 2's mu to 1000 if contactjoint2 then set spheregeom1's mu to 0 if contactjoint3 then set spheregeom2's mu to 0 dWorldQuickStep() apply resistance force to spheregeom1 based on contactjoint1\mu = 0 apply resistance force to spheregeom1 based on contactjoint2\mu = 0 apply resistance force to spheregeom2 based on contactjoint1\mu = 0 apply resistance force to spheregeom2 based on contactjoint3\mu = 0 If this is right, then per object mu changes per collision aren't possible with the current functions. That's why a way to access the contact joint values prior to calling dWorldQuickStep() are needed so we can put whatever data we want in them. That's assuming that dWorldQuickStep() takes such contact joint data and processes it this way. I just wondering if there're functions for this already? As the docs say, you don't have to use ODE's collision funcitons. You can use your own. Presumably one can create one's own contact joint list and populate it with our own values. Only I guess though we can create out own list, we can't, using ODE's native functions, access the content of the contact joint list created by it's own collision functions. |
| ||
| If this is right, then per object mu changes per collision aren't possible with the current functions. That's why a way to access the contact joint values prior to calling dWorldQuickStep() are needed so we can put whatever data we want in them. That's assuming that dWorldQuickStep() takes such contact joint data and processes it this way. The dSpaceCollide() function checks all geoms for collisions and creates the contact joints between them. The changes to the contact joint values must be performed before this function is called. Unfortunately, once the contact joints are created, there is no way of accessing them or changing their properties before calling dWorldQuickStep(). The actual processing of the contact joints at that stage is way deep inside ODE, not accessible to the user. I'm not sure what to suggest, I really don't think there's a way of doing this via the wrapper tbh. |
| ||
| Okay. I'll accept this is a limitation and work round it (not that it was a desperate limitation). Though I imagine if we got really enthusiastic we could Peek and Poke memory addresses to force any changes we like! |
| ||
| Though I imagine if we got really enthusiastic we could Peek and Poke memory addresses to force any changes we like! Yikes! :O |
| ||
| VIP3R, or anyone who understands lol, I am trying to add additional parameters to my car proggy, things I've noticed in the ODE docs that state to help keep errors lower were things like:
dBodySetFiniteRotationMode (dBodyID, int mode)
This function controls the way a body's orientation is updated at each time step. The mode argument can be:
* 0: An ``infinitesimal'' orientation update is used. This is fast to compute, but it can occasionally cause inaccuracies for bodies that are rotating at high speed, especially when those bodies are joined to other bodies. This is the default for every new body that is created.
* 1: A ``finite'' orientation update is used. This is more costly to compute, but will be more accurate for high speed rotations. Note however that high speed rotations can result in many types of error in a simulation, and this mode will only fix one of those sources of error.
Yet no value I set seems to help, or at least I don't notice a different. I assume you set this at the creation process, ie - The wheel process. Trying to limit the "uberfast" rotations to a more error less rotation while still maintaining my objects forward speed. Also can you change values like friction, ie - like just the two rear wheels, during the proggy running. I'm wanting to set it where the faster you go the less traction you can thus giving way to "drating" a corver, without setting the WORLD friction and it affecting all objects at a constant rate. One last, things like: BodyAddForce(body,fx#,fy#,fz#) dBodyAddTorque(body,fx#,fy#,fz#) Can those be used also and during run time change? Thanks Topknot ;) |
| ||
| Yet no value I set seems to help, or at least I don't notice a different. Like the manual says it only fixes one known issue that causes the problem, so if you've tried it and it doesn't help then you're probably better off leaving it set to the default value. Also can you change values like friction, ie - like just the two rear wheels, during the proggy running. I'm wanting to set it where the faster you go the less traction you can thus giving way to "drating" a corver, without setting the WORLD friction and it affecting all objects at a constant rate. "drating" a corver? Hehe, I take it you mean drifting a corner :) Yeh, you can adjust the friction on each geom using dGeomContactSetMu(geom,mu#) - (mu = friction btw). You can change any of the contact settings during runtime if you like. Check the JV-ODE Function Ref for a list of all geom contact functions. You can also use the add body force and torque functions during runtime ;) |
| ||
| Alrighty VIP3R, Will give them a shot, and as for the "drafting", what you never drafted behind a car doing 100 mph, ;)...Guess that's the FLorida, Nascar influence poppin out when I really meant Drifting. Topknot ;) |
| ||
| Is is possible to detect "Which" side of a CGeom makes contact/collision..? I'd like to make a particle fx on the side of the CGeom that collides with objects. So far with the new dGeom1/2 I can register a hit but they all register the CGeom as a whole. Thanks TOpknot ;) |
| ||
| I believe the functions dGeom1/2CollisionX/Y/Z and dGeom1/2CollisionNX/NY/NZ are what you want, though never used them myself |
| ||
| Yea looked at those but they appear more like giving back the world coords of where the collision occured. So even if I hit nose only first into like a pillar, all three still register values of where the collision occured, like in the Car DetailedC, that's how he placed the "Pointer" of the collision. Looking more for detecting if it was a Front hit or Side hit on a specific Geom, ie the Car's body. Granted could backwards peddle and use lame dummy sphere objects and blitz collisions, but was hoping to keep it all in the ODE family. BTW, are the only three peeps that post in here about working stuff out you me and Vip3r..? Need more JV ODE users lol, like the Tomack forums ;) Topknot ;) |
| ||
| For spark fx etc, all you need to do is place your particle fx at the location of the collision with dGeom1/2CollisionX/Y/Z as Shifty mentioned. If you wanted to know which side of the geom you're hitting, you can work that out based on the results of the dGeom1/2CollisionNX/NY/NZ functions and the geoms current direction. If you don't know how to use the Collision NX/NY/NZ functions, you would be better off asking in the Blitz3D Programming forum, as the JV-ODE Collision NX/NY/NZ functions work in an identical manner to the Blitz3D Collision NX/NY/NZ functions. The only thing you can't do in JV-ODE is the equivalent of Blitz3D's CollisionSurface() and CollisionTriangle() functions, you would need to use Blitz collisions for those. There are plenty of JV-ODE users out there btw ;) |
| ||
| Hey, there's lots of us JV/ODE users out here. 8) |
| ||
| For particle you'd place them (like a sprite) at the collision coordinates. If you move them along the vector defined by the normal (NX,NY,NZ) then the particle will move from the collision out in straight line, perpendicular to the impact. If you add a bit of variation (NX+Rnd(-0.25,0.25),NY+Rnd(-0.25,0.25),NZ+Rnd(-0.25,0.25) the sparks will travel with a bit of variety perpendicular to the surface. As VIP3R says, for more info go check the main forum for the maths. |
| ||
| Just a little suggestion for an improvement. A couple of times now I've had wierd behaviour, and struggled with a bug hunt until noticing it's because I reference a geom object instead of a body in dBodyDisable(obj\geom). It'd be nice if a compile error was generated when the wrong object type was passed to ODE functions, if that's possible. |
| ||
| Well, you can get the triangle collided index, at least this is what i read the last time i saw the docs, but it was not an easy job... EDITED: I have looking the ode docs, and yes, it is possible through the dtricallback, but not very well documented... |
| ||
| @KuRiX: Are you referring to the CollisionTriangle() function? dTriCallback() only prevents contacts being created on certain triangles, it doesn't provide collision data. I think that's what the dTriArrayCallback() function is for, but as you said, the docs are severely limited in this area. @Shifty: That isn't possible I'm afraid, to detect the error at compile time would require modifications to the Blitz3D compiler, which I can't do for obvious reasons ;) You could write a simple code parser which could detect it though. |
| ||
| Good Points, and I ended up using just the X,Y,Z, point of collisions to locate the needed collision sparks to great effect. I was overcomplicating the problem and not realizing the CollisionX abilities, thanks ;) I may seem "thicker" in the head than most of you in fully understanding all the wonders of ODE, but my abilities are stronger in the actual media, models, textures, fx area, and thus doing all aspects of a project when you're not as advanced as others is why I keep pestering for answers. So hopefully you all understand my lack of uber knowledge in all things Blitz3d and ODE coding ;) I hope to post a WIP by next week to let you see what it is I've been tinkering with, and as my abilities expand in understanding the math and ode callbacks I'll be able to improve on it. Granted I keep getting refered to the ODE and JV Doc's, but do understand a one line definition using terms a persons not familiar with is like asking someone non-automotive to breakdown and rebuild a transmission or engine with no prior knowledge. Maybe in the future with time permitting, a more fully detailed docs can be generated, and I will contribute all that I've found out in building a car simulation/arcade style project if it helps. Topknot ;) |
| ||
| Looking forward to seeing the WIP Topknot ;) The docs are ok, what we really need is some tutorials, it would be great if you can contribute one. I find it easiest to learn from code examples than anything else, but that's me ;) |
| ||
| Yeah, you're right vip3r. And what's the utility of this function: dGeomTriMeshGetTriangle ??? |
| ||
| Hmm, I'm guessing it returns the vertice data of a specified TriMesh triangle using the index retrieved from dTriArrayCallback(). Although I could be completely wrong, the ODE docs are useless for information on these functions. |
| ||
| @Shifty: That isn't possible I'm afraid, to detect the error at compile time would require modifications to the Blitz3D compiler, which I can't do for obvious reasons ;) You could write a simple code parser which could detect it though. Oh well. Currently I use a basic neural net based code parser. It's a bit slow at learning but it gets there in the end. I'll try and feed it more data on detecting these sorts of problems and hopefully avoid them altogether at the coding stage... |
| ||
| basic neural net based code parser Hehe, you mean your 'brain' :) |
| ||
| Hey, VIP3R - I appear to have a ghost! If you run this code... It'll stop when frame = 60 and on the 5th object in a per object loop. In the debug window I list the values of all the geoms in the scene. On my computer I get floorgeom=9921864 magnetgeom=9922424 sphere1geom=9923032 sphere2geom=9923280 sphere3geom=9923800 sphere4geom=9925640 sphere5geom=9926160 sphere6geom=9926680 Those ought to be all the geoms in the program. If you step through the code about a dozen lines, you get count of 3 collisions and reach the command collision_geom=dGeom1CollisionGeom(clutter(n)\geom,n) At this point collision_geom equals, on my computer, 9925472. That's an ODE geometry that hasn't been created! I crete the plane geom, the magnet geom, and geoms for each of the spheres, and none of these geom values, listed at the beginning of the Advance_Simulation() function, match with the collisionGeom value returned from dGeom1CollisionGeom(). I've just tried a slightly different test and with two spheres resting on the floor not being attracted to the magnet, both return different values for dGeom1CollisionGeom(), even though both have only one collision and are only in contact with the floor geom (there are no geom2 collisions). What going on? How can a collision with a plane geom be returning several different geom values? STOP PRESS!!! Okay, just found what I was doing wrong and let this be a warning to you all to pay attention to whichloop control variable your reference! I was referencing a collision index 'n' when n was pointing to my object number. I should have been using 'p' which was my collision index value. For n=1 to NUM_OBJECTS For p=1 to NUM_COLLISIONS collision_geom=dGeom1CollisionGeom(clutter(n)\geom,p) Referencing a collision index beyond the scope of the number of collisions does not cause a crash, but does return an imaginary object with a similar memory address that it looks like a legitimate object, rather than what I'd expect to be garbage. That's plus one for the neural net code parser, though it took an awful lot of time to solve the problem! |
| ||
| Hehe, that's it Shifty, you keep flexing that neural net code parser and soon you'll be brighter than a 10 megawatt lightbulb ;) Let the following be another warning to you all... I stopped using single letter variables for loop control many, many moons ago for this exact reason. Ever wondered why I use 'count' etc in those demos? Much easier for the neural net code parser to detect/avoid the problem ;) |
| ||
| can one install an option in ode to adjust Physic-mode ? Modus 1: low Physic (Only axial Moving the Objects, no rotations and no Joint Contact collision check ) Modus 2: realistic Physic (with Rotating the Objects and Check Joint Contact) dSpaceCollide need much performance. if one could adjust this, it would be better. The player then shall decide what he wants. .. a other Question: Can you offer the jv-ode also for C++ ? I become use a 3D Engine for C++. and would use the jv-ode. usage of jv-ode is simpler as Original ode. :) |
| ||
| Hi Barton, Can you explain about the two modes in a bit more detail, I'm not sure I understand what you mean exactly? You should be able to use JV-ODE in C++ as it is, you just need to link the dll to your C++ project. |
| ||
| Mode 2 is normal jv-ode processing. There shall not be any changes. Mode 1 shall check only on an axial collision and move only axially the objects. This shall save performance. (because joints are not update and check on collision.) -- other Problem: I cannot start the programmes with jv ode if FRAPS runs in background. Error Message "Userlib not found". The jv-ode demos then do not work either, if running FRAPS in Background. Same Error Message "userlib not found". After closing the FRAPS , works it. No Error Message then... with GameCam in Background no problems with jv-ode. Only with FRAPS. I Use Fraps Version 2.0.0 a solution? :) why are Fraps and jv-ode.dll incompatible ? |
| ||
| I'm still not sure what you mean by 'axial' collisions? Geoms that are connected directly by joints are already excluded from collision detection in JV-ODE. Have you tried compiling your code, running the 'exe' instead and then running Fraps? Does it work when you do this? |
| ||
| The objects shall be moved only axially if they collide. I have meant this. -- if I starting first the Exe and then FRAPS, it running without problems and FRAPS work. it does not work if I start FRAPS before. "Userlib not found". But it works if I remove jv-ode from code. some customers has pointed out this fault to me. The customers wanted to make screenshots with Fraps (and view Frames). I also can confirm this. I have not noticed it before because I use Gamecam. do you also have the problem? (your examples also do not work with Fraps here) |
| ||
| hey viper. I think i understand what barton means. It would be somekind of "only basic physics". So you have basic objects that do no react to physics, like blitz3d collisions!. you move, collide, then slide, but no rotate, no contact, etc... the problem is that barton doesn't knows that ode to position the object in its place uses the contact data generated... |
| ||
| If that's what he means, why use JV-ODE at all? I want to help answer your question Barton, but I need to understand the question in the first place. Give me an explanation of what you mean, an example situation. Does Fraps work with any other DLL's in Blitz3D? I would suspect that Fraps is upsetting Blitz3D's detection of all 'non-system' userlib DLL's not just JV-ODE. |
| ||
| Well, perhaps he wants to switch between blitzmode and ode mode, but using only jv-ode for all ;) (and using blitz style collisions but with force, gravity, etc...) By the way, forcing ode to do non-rotation is more cpu intensive that don't! |
| ||
| Yes, I mean it like Kurix it thinks. :)) The players with performance problems shall have the possibility of switching over to simple Physic Mode. perhaps this brings more performance? But this probably will not be possible. Sowas then should offer original ode. --- other DLL's in Blitz3D works without Problems in combine with Fraps. Also the other freeware ODE Wrapper Dll work. Only jv-ode.dll not. :) a conflict something at both ? it seems that Fraps deletes the main directory into combination with jv-ode. ? funny problem :) |
| ||
| ??? Correct, it isn't possible. I've got no idea why Fraps is conflicting and causing 'Userlib not found' errors. It might be worth asking in the Blitz3D Programming forum, maybe someone else has experienced similar problems. I don't see how the JV-ODE.dll itself can be causing the problem. Try renaming the DLL to 'test.dll' (including the decls) and see if that makes any difference. |
| ||
| I have it renamed in "test.dll", same Result. Directory self is not deleted. But perhaps the Main-Directory Pointer ? and why with only jv-ode? this is the question :) perhaps do Fraps and the jvode use a similar variable? :) can you download the Fraps and test it ? Download: http://www.majorgeeks.com/download3934.html actual a very strange appearance. It is also the problem that many players use Fraps, also the PC magazines for Frame tests and Screenshots. if something like that then happens ... perhaps one should rename the error message "Userlib not found" in "This is a safety message! Please close Fraps or use GameCam and restart the Game..." ? :)) |
| ||
| Or mention it in the game readme/docs instead ;) What happens if you disable the on-screen 'fps' display in Fraps? |
| ||
| if I disable on-screen fps -> same result :) I have already tested all combinations. |
| ||
| The conflict is most likely to be between Fraps and Blitz3D, not Fraps and JV-ODE. There's nothing in JV-ODE to cause Blitz3D not to detect it during startup, so there's very little I can do about it. You should make a note in your game docs and tell your users that your game MUST be running prior to starting Fraps. |
| ||
| Hmm interesting, Seems Fraps does kick the ODE to MAV, I get the error that my User Lib is not found and my key is highlighted as the error line. But Fraps and Blitz3D don't crash when running a 3d app that's not tied into JV. So he does have a point. |
| ||
| The reason your key is highlighted as the error line is because that is the very first function called. Fraps is preventing Blitz3D from detecting the JV-ODE.dll, there is NOTHING in the dll that would make it invisible to Blitz3D when Fraps is running. |
| ||
| This is strange, i have used fraps with my ode wrapper with no problem... well, use other capture soft... hehe |
| ||
| @KuriX: the normal freeware ode-wrapper works without problems with Fraps. But jv-ode not. I would be interested why. both use the same library. ODE self is not the reason. This Wrapper does not work, but the other works. |
| ||
| i can't understand why... perhaps some compiling option...we don't know how fraps internally works, so this is difficult to fix... |
| ||
| If you're that interested in finding out why Fraps conflicts with Blitz3D/JV-ODE, I suggest you ask the creators of Fraps. Fraps is affecting Blitz3D's ability to detect JV-ODE on startup, there could be a multitude of reasons why. |
| ||
| can you ask the other ODE-Wrapper Developer, how he initialized the ode ? Its ode initializes works, perhaps it can help ? Fraps works with every game, why it should be an exception at mine. And a another Appz also could cause the same fault. very risky ... |
| ||
| Barton, this is the LAST TIME I'm going to explain this to you, so listen very carefully... There is NO initialisation process in ODE. Fraps does NOT work with all software, it conflicts with other software too. Fraps is preventing Blitz3D from detecting the JV-ODE.dll on startup. ODE/JV-ODE does NOT produce the 'Userlib not found' error, Blitz3D does. ODE/JV-ODE is NOT the problem here. The ONLY major difference between JV-ODE and the other ODE wrappers is the compiler used to create it. JV-ODE uses MinGW, others use VC++. I understand your concern, but I've told you several times now that the wrapper is not at fault here. I've always done my best to help JV-ODE users with ANY problems and I take them ALL very seriously! If I thought for one second that JV-ODE had a 'very risky' problem, it would be dealt with immediately. But the fact is, it HASN'T. Geez :/ |
| ||
| ok, thank you for the Explanation. |
| ||
| Barton, what path is B3d installed on? |
| ||
| C:\Program Files\Blitz3D... this plays no rolls, because the created exe files either do not work. |
| ||
| just bought it wanted to say thanks for writing this! very fast and stable.. now the project i'm working on can go forward.. definitely recomend buying mike |
| ||
| Thanks Mike, welcome aboard :) |
| ||
| Right, I've got some news for everyone... In case you didn't know, I despise the MinGW compiler with a passion! I've been tinkering away for the last few days, converting JV-ODE to compile with Visual Studio 8 instead. Things are looking very promising so far, the new VS8 JV-ODE.dll is optimized MUCH better than with MinGW. Its size is down to 440KB which is a lot better and may also improve the speed of JV-ODE. Hopefully, using a different compiler may also reduce the possibility of the Fraps conflict, but I can't guarantee that for sure. There is one bug I need to squish (from the conversion process), then it should be ready for testing and ultimately release. I'll keep you up to date on this :) |
| ||
| this is good news! am very curious about the result. :) |
| ||
| Update: Ok, squished the bug which the new compiler was complaining about. I've tested the new demo version of the wrapper and everything looks good. I need to do some more testing with the full version, then it should be ok to release ;) More soon... |
| ||
| Awesome, work VIP3R! Outstanding customer service and support. This wrapper just gets better, and better. |
| ||
| yeah thanks for your continuing work on this vip3r! ode gave our game another dimension of realism, no chance for tokamak! cant wait to try the new version :) |
| ||
| Ouch, I ran into serious problems with missing C runtime libraries with the new JV-ODE DLL's. The good news is I've managed to fix those problems now, just a bit more testing to do and it should be ok to release (couple of days max). :) |
| ||
| I have a very newbie question, so I'll apologize in advance. I need to have a 'physicsed' cube for the player. So when you press the cursor keys, the cube moves around normally, allowing it to bump into things and what-not. I don't want to add force or velocities the the cube when the player presses the keys because it makes the cube 'slide' even after the key is released and the forces accumulate, giving the cube acceleration, when I need it to stick at a set speed. I'm lost in how to accomplish this. I've even tried setting the position of the objects\body to the position of a controllable pivot entity, but that screwed up the collisions with other objects horribly. So, im stumped. Any help would be much appreciated. |
| ||
| "Use the Force, Luke" 8) Apply force, clamp linear or angular velocities, and when the key is released set linear and angular velocities to zero. |
| ||
| Hi Dripht, You may find it easier to create a sphere for the player instead. Check out Psychic Parrots demo that's posted in JV-ODE Thread 3, the demo shows a sphere with controlled velocity. When you're happy with the sphere setup, you can attach a cube (if needed) to the sphere using a joint to provide the sphere with cubed geometry. If you're still stuck, let me know ;) Update: JV-ODE V1.09 will be released shortly... |
| ||
| JV-ODE Physics Wrapper V1.09 Released Please check your inbox :) JV-ODE Version 1.09 has now been released. The new version features a brand new DLL compiled using Visual Studio 8, with vastly improved optimization and improved compatibility. Anyone who experienced runtime errors with earlier versions of the wrapper may find the new version remedies any problems caused by DLL conflicts. Don't forget to update your 'JV-ODE.decls' file! Please let me know if you experience any problems with the new wrapper. Cheers :) |
| ||
| Thanks for the new Version! :) I have tested it! 2 news. One good, one bad. the god news: Fraps work now ! :)) the bad news: my game freezes after some Time,if many objects collide. (must after restart my Windows)Only in ode V1.09. After install the V1.08 works again. what can be this? I Use only Cube Objects, Static Objects, Geoms, Mass , dBodyAddForce ,dBodyGetLinear, dBodyGetAngular, AngularDamp, dGeomSetRotation , dGeomSetPosition... |
| ||
| same here...mine freezes after a few seconds.. the previous version didn't freeze at all with a lot of testing so it must be something with the new version.. no complaints though..this is too good to complain.so i'll just use the previous version..:) |
| ||
| No such problems here. My program seems to work okay, and I ran the JV-ODE Mixed Objects example (adding random rotation to cylinders to overcome the end-collision bug in ODE) for a couple of minutes without any freezing. I was very impressed how many objects were colliding actually and yet the frame-rate remained smooth. I also kept an idea on the Performance Manager's memory usage, and there wasn't any memory leak going on either. Can you post example code that crashes on your machine? |
| ||
| Good to hear it's fixed the Fraps issue :) Hmm, I'll look into the freeze problem, I didn't get any problems here during testing. How long before it freezes, can you give me an estimated time in minutes? Can you post some example code that freezes please? I checked to make sure there weren't any memory leaks during testing. I wonder if it's the stack. @mike950: What are your machines specs? |
| ||
| hey vip3r ..i'm on a somewhat old laptop dell inspiron 8500.. but later today i'll try it on a completely different machine. i can try to strip out code until it doesn't freeze.. |
| ||
| it happens in different intervals. The JV-ode Examples works without freezes. But my Game use many Physic objects with details. A Example to create is not possible, it is a closed system. I will try to delimit the problem. but I think the new version works more constantly. :)) |
| ||
| Ok, thanks. It will really help if I can recreate the problem here with an example if possible. If I can't recreate the problem here, I'll need to send a few test DLL's to users getting the freeze problems. |
| ||
| Don't worry about the example folks, I've managed to recreate the problem here. @Shifty: Can you run the 'CarDemo-TriMesh-CCylinder.bb' demo and change the ccylinder amount from 20 to 120 (or higher), you should see the freeze then. Let me know if you do. Ok, now that I can see the problem, I'll get straight onto it. Sorry about this everyone. |
| ||
| yes, i have tested the 'CarDemo-TriMesh-CCylinder.bb' with Clinders > 120 and after some Time freezes here. it appears if many objects were made. I also have noticed that the frames fall more strongly if one makes new objects. the old version has 2 frames more with same Objects. Is the Bug a Memory leek Problem ? |
| ||
| The car demo works fine for me. Simulation time was averaging about 6. I then tried v1.08 and simulation time was nearer 4. Not an extensive performance test, but there was a difference that shows the two libraries run at different rates. Perhaps the bug is slowing it down? A fuller comparison ought to be made when a fixed 1.09 is released. |
| ||
| Thanks for the info Shifty, I'll run some more tests side-by-side to see if I can squeeze some more speed out of V1.09 ;) |
| ||
| Is there a way to combine geometries? I was using a concave mesh for my ground, a circular arena with encompassing wall, but it had accuracy issues and penetrations. I've replaced it with a plane that works well, but lacks the wall. Is there any way to combine the floor and wall into a single GEOM object? Or do I need separate geom entities? |
| ||
| Just downloaded the demo from the Blitz mainpage. Moved the DLL & decls to userlibs, restarted Blitz and got this error: Compiler environment error: Error in userlib 'JV-ODE.decls' - duplicate identifier. |
| ||
| @Shifty: Separate would probably be best. You can combine them in a mesh editor then load it as a single mesh. @Dustin: Hmm, never heard of that error before. I'll look into it, thanks. |
| ||
| dustin: maybe you got the old demo version of the wrapper and its still lying around in your userlibs folder? check, that no "ode.decls" is left (just delete it). got the same "problem", after i buyed the full version :) |
| ||
| Ojay could be right Dustin. Make sure you don't have two different sets of the 'JV-ODE.decls' files. I've double checked, there aren't any duplicate identifiers in the decls files. They wouldn't work for anyone if that were the case. About the freeze issue with V1.09... I can only get the freeze to happen when Capped Cylinders and TriMeshes are used together. The earlier JV-ODE versions compiled with MinGW had some problems with this combination too (potential memory leaks). This leads me to believe that there could be a fault in the ODE code somewhere that the new compiler may have made more prominent. Can anyone confirm freezes with any simulations that -don't- contain Capped Cylinders and TriMeshes used together? @Shifty: I've managed to speed up the new DLL quite significantly using different compiler options. I haven't done any precise timing to compare, but it looks faster than previous versions of the wrapper (or at the very least, as fast). |
| ||
| no capped cylinders here.. trimesh boxes and spheres freezes after 3 secs |
| ||
| Can you send me some code that shows the problem please mike950? |
| ||
| sure.... i'll email ya the link when its ready.. |
| ||
| @VIPR: I use no Capped Cylinders & no TriMeshes, and have the freezes. Freezes after collisions of the Player with many Physic objects. Simple Static Objects with Simple Cube Geoms. (with Mass) |
| ||
| Ah! Mike's example has given a big clue as to what is wrong and it's nothing to do with ccylinders, cubes, spheres, collisions, mass or TriMeshes :) It looks like the problem occurs when a geoms position passes from a +ve float value to a -ve float value. Mike, can you confirm something for me. In your demo, when it starts, instead of driving forwards - drive backwards (don't cross the finish line!). You should be able to stay behind the finish line without it freezing. Then when you're ready, drive -slowly- towards and then over the finish line. When the X position of the car is between +8 and -8 the wrapper should freeze. Does this happen on your machine? |
| ||
| oh man that would be great if my demo leads to the fix.. i'll perform those tests now! mike |
| ||
| hmmm I use also coverted Floats to Int and set the Postions of geoms X & Z & Y always + Coordinates here my Comando Line. dGeomSetPosition(ode\geom,Int(dGeomGetPositionX#(ode\geom2)),Int(Y#),Int(dGeomGetPositionZ#(ode\geom2))) I do not think that it only is due to it. |
| ||
| that seems to be it! i can drive around for a long time until i cross the line.. thats weird! |
| ||
| Yep, that's the problem. The new DLL must be trying to pass a double precision float to Blitz3D which is causing it to lock up (Blitz is single precision only). The only time it would go outside of single precision range is when it rolls over to a negative value, hence the cross line in the demo (CrossLineXPosition = 0). It looks like the VS8 compiler treats all floats as double precision by default, instead of single precision like MinGW. Great stuff, now I know what to look for, hopefully it shouldn't be too much trouble to fix :) Thanks for your help Mike and Barton :) |
| ||
| hey my pleasure!.. great work in figuring that out so quick! mike |
| ||
| concerns that also floats, the internally processes of the ode? (contacts,Angular etc..) or only floats in connection with geoms ? because my geoms have always + Coordinates as Position. |
| ||
| Well - I finally downloaded the demo - great work! But, what's even better - my kids (ages 11 and 7) have been playing with that ragdoll demo all day - these kids are serious gamers - (well, mostly on GameCube) - but they can't get enough of this. Sometimes I think the simplest games are the best. |
| ||
| @Barton: Any floats that are passed from JV-ODE to Blitz will affect it (dGeomGetPositionX, dGeomGetPositionY, dGeomGetPositionZ all pass floats - as do the pitch, roll and yaw functions). Not just the position and rotation, but ALL floats could cause a problem when passed from JV-ODE to Blitz (not internally). Great to hear you like the demos sampyxis, thanks! |
| ||
| Thank you for the explanation. If the problem is defined now, then it will not be a problem for Vip3r to fix it. :)) -- My Kids (ages 8 & 5) also likes to play the Car-Demo :)) |
| ||
| > check, that no "ode.decls" is left (just delete it). Hey, you guys were close. I didn't have on old JV-ODE version. But I *DO* have KODE files in there. Apparently they can't live in harmony. I bumped out my KODE files from the userlib and then everything fired up nicely. You might want to point that out in your Demo readme file. |
| ||
| Well, you can't have have two or more different decls files with the same functions inside. So if there is any function with the same name in kode and jv-ode, then there it is the problem... Come on Viper, you can do it! There must be a compiler option to use just floats. And be sure that when compiling ode.lib you use the single precision + trimesh.bat and that the config file is created correctly. And check that you are compiling a release version, not a debug version. Cheers, KuRiX. |
| ||
| There isn't a compiler option for using single precision only. After doing some more testing, I'm not so sure the floats are the problem after all. There's something very wierd going on, it reminds me of the TriMesh collision problems a while ago. In Mike's demo, everything is fine as long as you don't drive over a certain area (the racetrack start/finish line), but once you drive over it... the freeze occurs. Although if you get enough speed up, you can cross it without it freezing. Barton, can you try to produce a small demo based on your code that shows the problem. It could really help pinpoint the exact problem here. |
| ||
| Well, i had this problem in the next situations: - Trimesh containing non geom objects (splines, lines, beziers, etc...) - Too much force on any object any time Check if sizeof(float) in vc8 is 4. If it is 4, then, this is not the problem. Although incorrect values, not hang should occur. Check the trimesh, because as i told you, non triangle objects can freeze ode (i had this problem with kode too!!!) |
| ||
| Hi Kuri, I'm not sure what objects are used in Mike's mesh, as I didn't create it. But the problem also appears in the JV-ODE TriMesh/CCylinder example and that only contains triangles. Barton, you say your example freezes without any TriMeshes being used. I need to see it if possible, it might be very important. |
| ||
| only triangles in the mesh.. so thats not the problem.. |
| ||
| Confirm that the problem occurs with no trimesh too, because as viper says, it is really important to know... |
| ||
| Ok, found the problem at last! It's definitely caused when recompiling the ODE and OPCODE libraries in VS8. The OPCODE library is probably the one that's screwing up, that's the same one that caused all of the TriMesh problems in the early builds of JV-ODE. I can compile V1.09 in VS8 using the prebuilt ODE binary and it works fine (no freezing issues), but this means we would lose the latest CVS code updates. So I'm going to see if I can get the latest CVS builds to compile properly before resorting to the prebuilt binary. More soon... |
| ||
| Do you want me to recompile the latest cvs in vc6 for you? |
| ||
| Cheers for the offer Kuri, please check your inbox ;) |
| ||
| Nevermind Kuri, I've found that the source of the memory leak with Capped Cylinders and TriMesh is IN the latest CVS code. Using the prebuilt binary doesn't give any memory leak, so it would be better to use that instead. I'm going to build the new V1.09 update containing the fixes now. The new DLL will also be a little smaller. As soon as it's ready I'll send out the update email to everyone ;) |
| ||
| It's nice to see people helping each other out. I've got some more time over the holidays so I'm looking forward to trying out the updated DLL. Be sweet if it's smaller and faster than V1.08. Thanks VIP3R |
| ||
| It almost is not possible to make an example. This is the problem, my game has an engine of its own and the physics objects are loaded from Files. This can take very much time. Game Size: 840 MB ! I can mail the ode-update Function to you ? |
| ||
| JV-ODE V1.09 Update Re-Released! Please check your inbox :) *** IMPORTANT *** There were some problems with the initial JV-ODE V1.09 release, please re-download the JV-ODE V1.09 update and replace all of your existing JV-ODE V1.09 files. The new update includes: Fixed freezing / lock-up issue Fixed dGeomTriMeshDataDestroy() issue Fixed potential Capped Cylinder / TriMesh memory leak Please let me know if you experience any problems with the new update. Thanks :) |
| ||
| no more freezing! :) hey just wanted to say really appreciate the hard work to get it working. mike |
| ||
| yeaahh ! it works ! no freezing, more liquidly of Physic , constant frames, fraps work :) ... I think, it is a very great work of you Vip3R !! Hard work! Congratulations :)) Best Service & best Support !! I test still further. if there should be problems, I will write it here. it runs very fine now. |
| ||
| Congratulation, one more for Viper! Viper 2 - Wrapper 0 ! |
| ||
| Excellent, I'm really pleased to hear it's working well now :) Thanks for the help and support fellas, I appreciate it ;) |
| ||
| what comes as next ? new compiled Version in Assembler ? :))) |
| ||
| thanks for your support viper! now, that this has been cleared out, could you PLEASE start a new thread? :) (i still don't understand, why this board doesn't support pages...) |
| ||
| You're welcome :) I'll start a new thread later today ;) |
| ||
| THREAD 4 IS ABOUT TO CLOSE Please continue on the new thread located here Thanks :) |
   |