problem with demo car slowing down

i posted a thread
http://www.ogre3d.org/phpBB2addons/view ... highlight= because my car gets to a good speed then slows down. no-one answered my thread (apart from hexidave, but this was a on a different matter, thanks hexidave), and i think this was because i did not explain it very well, or give enough details/code.

well you can reproduce the problem using demo 5. replace the terrian with a box.mesh, and scale it 600, 0, 600 to make it nice and big, and flat. give the vehicle a direct 6000 torque by doing

if (mInputDevice->isKeyDown(Ogre::KC_W))
torque += 6000.0;

then get the speed of the vehicle (in km/h) using m_chassis->getVelocity().length() * 3.6, and append it to an overlay. keep your finger on 'W' and the car will go forward. i can get the vehicle upto about 90km/h, and it will stay like this for quite a while, then, for no apparant reason, it will slow down, even though your finger is still on 'W'. if you take your finger off 'W', and then put it straight back on, it still never increases speed.

i found a forum thread where someone had the same problem, and was told to make a gearbox/torque curve. but, in my actual project, i am not applying direct torque, i am using a gearbox and torque curve, freshly stolen from stunt playground. yet i still have this same problem.

if someone could explain to me why the vehicle slows down after a while when applying direct torque (like in the demo 5 example above), then i can use this to troubleshoot my actual problem.

i really appreciate any answers.

if you are reading this and you do not know the answer, then would you at least confirm that i am not going crazy and see if you can repeat the problem?

in demo 5, just get the speed of the vehicle as i mention above and keep going straight forward. doesthe vehicle get to a good speed and then suddenly slow down?

maybe its my machine

does anybody please know the answer ?

im absolutely stuck until i can get passed this car-slowing-down problem.

i just need to know why it happens when i apply the torque directly??

torque += 6000.0;

Are you really increasing the torque this much every frame?

If you do, the torque you apply to the wheel after a couple of seconds would be sky high and way from a realistic value which in the end would probably cause the simulation to act weird. In real life the tire would probably been blown to pieces unless the axle would break or melt first.

Try applying a fixed torque to the wheel and see if this cause a more stable behaviour.

no, actually at the start of frameStarted, torque is set to 0.0, and then when you hit W it adds 6000. so it will always be 6000.

+= in this case is exactly the same as =.

somebody must have come accross this problem before, i dont think my question is strange, and there are no answers to it on the forum (ogrenewt and newton).

well, the reason to deom 5 car slowing down is different to the reason the car in my project slows down. the demo 5 car was slowing down because it was loosing traction. my car is not loosing traction but still slows down.

anyway, there is a fresh problem with the vehicle class. if you get the car upto a decent speed (like over 160km/h), the wheels become more and more detached from the car as the speed increases. i found this out because i attached mCamera to the side of the car to monitor the car from a side-on view as it accelerated. either the wheels shift back, or the chassis shifts forward. but from the 3rd person camera view (ie with the camera behind the car this time), the wheels slowly come through the wheel arches. this isnt my dodgy app, this is demo 5 i am talking about.

possible bug here? or a reason why this happens?

because of the way the tires are getting updated. I believe I fixed this in Stunt Playground by creating the wheel update callback in the vehicle class...

have a look through the code, and see where I update the visual objects for the tires in SP.

cool, ill have a look at this.

thanks for letting me know.

hurrah!

i think i now know why my car keeps spazzing out on me for no reason.

can someone please explain this to me:

1 - in demo 5, change the simple_terrain.mesh for a box.mesh, and scale it 6000, 0, 6000 to make it big and flat.
2 - now hit F3 and you will see the collisision object. you will see the white lines, and you will also see where they meet in the middle of the 'terrain'.
3 - now, drive over this middle bit of the terrian, where these lines meet.
4 - voila! the car spazzes out! it looks like it is driving over lumps - but the terrain is completely flat!


this is what has been happening to my car. i have been setting my car's starting position at 0,0,0 and it has been landing directly where the collison lines meet, and has been bouncing around like a mad thing.


so, what is hapening here? where are these lumps in the middle of the terrain coming from? is it because i am scaling a mesh so large?


[edit]
it doesnt just happen in the middle actually - drive over any of the white lines and the car bounces over them
[/edit]

i would still really like to know the reason for the above question.

this does not happen just with box.mesh. i have used my own mesh (exported from freeworld3d terrain designer) AND Stunt Playgrounds track.mesh.


if you scale a terrain, and press F3 you can see lots of white collision lines. some of these lines are solid, and these are OK. however, some are dotted, and if you drive over these lines, its as if there is a rock or something, and the car bounces over them.

at slow speeds this just makes the car bobble over the lines. at fast speeds, the car simply flips over, and is rendered useless.

without pressing F3 you cannot see these lines, and hence it looks like the car is bobbling over invisible rocks.

so either you cannot scale terrains, or there is a workaround.

(setNormaliseNormals makes no diffeence here)

i would still really like to know the reason for the above question.

this does not happen just with box.mesh. i have used my own mesh (exported from freeworld3d terrain designer) AND Stunt Playgrounds track.mesh.


if you scale a terrain, and press F3 you can see lots of white collision lines. some of these lines are solid, and these are OK. however, some are dotted, and if you drive over these lines, its as if there is a rock or something, and the car bounces over them.

at slow speeds this just makes the car bobble over the lines. at fast speeds, the car simply flips over, and is rendered useless.

without pressing F3 you cannot see these lines, and hence it looks like the car is bobbling over invisible rocks.

so either you cannot scale terrains, or there is a workaround.

(setNormaliseNormals makes no diffeence here)

were you able to find a solution to this problem???

yes - do you have the same problem?

its a bug with newton.

yes - do you have the same problem?

its a bug with newton.

Hi..

The problem I'm having is that :

I've a track and I'm using TreeCollisionSceneParser to create a collision object for it.
You can see that I'm using a compound collsion object for my skater player.
Now whenever I'm skating at high speeds upwards of 150 units, almost for sure, whnever the player will skate over these "line of contacts" in the track, they act as BUMPS.. like the line was more like a foot thick wall sticking out of the track.
Sometimes even while skating at low speeds this probelm occurs. It's just that the chances of it increases with increase in speed.
Lastly, I'm using a scaled track now with setNormalisedNormal set to true. I tried using a Track that was scaled in Maya and then exported to OGRE. That really didn't work.



Lastly the problem only OCCURS if I hit these lines (almost) perpendicularly..

If your problem was anything similiar.. plaese let me know the solution.. my game is scheduled for Demo in three days.. and this is a FREAKIN PAIN in the ASS..

regards

nik

yep, this is the newton bug.

there's nothing you can do about it either, which, agreed, is a pain in the ass. i posted a thread on the newton forum and the author of newton answer me, confirming it was a bug. at the time i was pleased, just because he answered me (i was going mad trying to figure out the problem). i sent him a PM last week but he ignored me. presumabley he is busy with work or something. but my project is my final year project at uni so i am in the same pikkle as you for sure.

by looking at your image, i can see that you are optimizing the poly count. this causes the problem quite severely. try NOT optimizing. the poly count is much higher (causing higher fps) but the problem is not apparant (although it still is there, because if you use tire->isAirBorne(), you can see that every time the wheels go over the lines, they become air borne).

yep, this is the newton bug.

there's nothing you can do about it either, which, agreed, is a pain in the ass. i posted a thread on the newton forum and the author of newton answer me, confirming it was a bug. at the time i was pleased, just because he answered me (i was going mad trying to figure out the problem). i sent him a PM last week but he ignored me. presumabley he is busy with work or something. but my project is my final year project at uni so i am in the same pikkle as you for sure.

by looking at your image, i can see that you are optimizing the poly count. this causes the problem quite severely. try NOT optimizing. the poly count is much higher (causing higher fps) but the problem is not apparant (although it still is there, because if you use tire->isAirBorne(), you can see that every time the wheels go over the lines, they become air borne).

hi

my game is due on 12th Dec and YES, i found myself in troubled waters over this problem.. However, my experience has been different in some aspects..

First of all, it's low polygon to actually alleviate the problem and not intensify it. From what I found, was that more complex the track's Newton body is, higher were my chances of getting hit by tht bug
Secondly, as corners are usually more poly than the rest of the track (coz of more polygons to create a turn), if I increased on the SMOOTHNESS on the track, it will exponentially increase the poly count on the corners as compare to the rest of the track. Then when the Newton body for the corners were created, they looked like WEBS. And I would run into the problem of slowing down drastically whenever I would try and skate through any of the webs.
Basically I identified two problems:-
1) Slowing down over cris-crossing WEB like collision lines.
2) bumping off collision lines that came perpendicular to my velocity direction.

The GOOD news though is:-
1) got rid off the WEB problem by using low poly track, though that made the corners SHARP.. it resulted in better behaviour when the player would bank along walls of the track..
2) got rid off the BUG.. by using Capsule bodies to simulate the wheels of the player body. Capsule offered more area of direct contact with the track surface and allowed for far greater speeds while going over those PERPENDICULAR collsion lines. think of it using a tank wheel to move over a speed breaker.. U think the tanks wheel would feel the bump??

I hope I'm able to put my points across.. Because after knowing high poly are supposed to be better working and now tht I'm not having any of the bump issues I'm gonna go back tweak the poly count on the track and try again..

Thanks for your insight..

regards
nik

. try NOT optimizing. the poly count is much higher (causing higher fps) but the problem is not apparant (although it still is there, because if you use tire->isAirBorne(), you can see that every time the wheels go over the lines, they become air borne).

and I'm using a compound collision , so I cann't use the isAirBorne().. they are all just tiny spheres to better simulate skating motions..

and I'm using a compound collision , so I cann't use the isAirBorne().. they are all just tiny spheres to better simulate skating motions..

first, i should tell you that i am using the newton vehicle joint, hence my suggesting the isAirBorne function...

but, according to the author of newton, the problem is with any round object (so my wheels or your sphears).

anyway...


From what I found, was that more complex the track's Newton body is, higher were my chances of getting hit by tht bug


hmm, im not sure i understand. im not talking about the complexity of the track, im talking about whether the mesh has been optimized or not. you can have a completely flat 128x128 terrain, or a hilly 128x128 terrain - if you do not optimize, the poly count will be the same. for example, my terrain is pretty complex (hills and such), but the 'road' is flat all the way round.

heres my terrain not optimzed:


and with it optimzed:


so, when you say the problem is worse when your terrian is not optimized, do your white lines look like mine? ie loads of small ones? could you post an image of what your terrain looks like not optimized?

[edit] how do you post images? i thought was how you did it??? [/edit]

Wow..
How did you get rid of the cris-crossing lines on your ground??

from:-


to:-


And yes, I think our ideas of optimized meshes were different but same for the unoptimized one!


As you can see the area in black is where my track is curving and te newton body is like a WEB .. thts my idea of unoptimized track.. And in the red area you can see a straightway in the track and the lines are well seperated. Though after seeing pics you posted of OPTIMIZED terrain, I think even this is unoptimized.

To post pics I use imageshack.us and get the url for the thumbnail and just remove ".th" from it .. for e.g http://abc.xyx/image.th.jpg to "[img=""http://abc.xyx/image.jpg"" alt=""]" in the forum post without the quotes..


regards
nikhil
P.S - how to optimize??

right, let me clear somethings up. optimizing is when newton calculates which parts of the terrain (or any node for that matter) are flat, and reduces the poly count. so for hills and things like your corner, not alot of optimizing will be done because there is more detail. but for flat parts of the terrain like my road, there is not alot of detail and so not alot of polygons are needed, hence this part is optimzed quite alot. optimzing is done per mesh, not per bit-of-a-mesh. you just tell newton whether you want the mesh optimzed or not, and newton does the calculations. all i have done in my 2 images are optimize for one, and not optimize for the other!

you are using TreeCollisionSceneParser, correct? well, this takes a parent sceneNode, and all of its children (ie sub meshes) and makes one giant newton tree collision from it. however, there is also simply the TreeCollsion, which just takes one sceneNode and makes a newton tree collision from it. if your terrain is just one mesh, you don't need the SceneParser.

anyway, if i remember correctly, the SceneParser takes just one argument (mWorld - please correct me if i am wrong). the normal TreeCollision takes 3, the last argument is 'true' or 'false' depending on whether or not you want to optimize. there must be some function of the TreeCollisionSceneParser that calls setOptimize(true) or something.

this what my code looks like, to create my terrain newton body:


//create a collision object for the terrain
OgreNewt::CollisionPrimitives::TreeCollision* col = new OgreNewt::CollisionPrimitives::TreeCollision(mWorld, floornode, true);
OgreNewt::Body* bod = new OgreNewt::Body(mWorld, col);
delete col;
bod->attachToNode(floornode);
bod->setPositionOrientation( Ogre::Vector3(0, 0, 0), Ogre::Quaternion::IDENTITY );


so the criss-cross lines that you mention are just the result of not optimizing. doing this eliminates the bug.

the reason i thought your track was optimized was because you do not have these criss-cross lines, you have long lines, all inconsistent in length. but maybe i am wrong!

2 things i would suggest: 1- if your track is simply one mesh, you do not need the SceneParser. Just use the TreeCollision like my code snippit above and change the value the 3rd argument and note the differences (so true being optimized and false not optimzed). 2 - if you really do need the sceneParser, then look for a function that calls setOptimize() or something like that.

there you go, its the second argument to parseScene


parseScene(node, true);


or


parseScene(node, false);


there you go, its the second argument to parseScene


parseScene(node, true);


or


parseScene(node, false);


THTS awesome.. I'll try tht and let you know.. This can be a last minute wonder for us, may be I can as well use a High Poly MESH for my track also so it looks smoother and a professional job..

I took this Game Proj class without any prior exposure to 3d Graphics / game prog / physics binding etc. And as our game was ambitious I just held onto the first solution I could find and never looked back coz of time constraints..



good luck with your proj..

regards
nikhil

Hi..

I did wht u said.. I was already calling the parseScene with optimize set to true.
so I went ahead and changed SceneParser to just TreeCollsion and it actuall returned better results than SceneParser though I was calling optimize on both on them.

But there are still few cris-crossing lines, though they are few and far in between. I'm just curious if it could get rid of them on most places why not everywhere..



regards

nikhil

so I went ahead and changed SceneParser to just TreeCollsion and it actually returned better results than SceneParser though I was calling optimize on both on them.


i am trying to tell you that you do NOT want to optimize! i can tell from your last 2 images that you are optimizing. set the argument to FALSE!!!!

this what my code looks like, to create my terrain newton body:


//create a collision object for the terrain
OgreNewt::CollisionPrimitives::TreeCollision* col = new OgreNewt::CollisionPrimitives::TreeCollision(mWorld, floornode, true);
OgreNewt::Body* bod = new OgreNewt::Body(mWorld, col);
delete col;
bod->attachToNode(floornode);
bod->setPositionOrientation( Ogre::Vector3(0, 0, 0), Ogre::Quaternion::IDENTITY );


so the criss-cross lines that you mention are just the result of not optimizing. doing this eliminates the bug.

the reason i thought your track was optimized was because you do not have these criss-cross lines, you have long lines, all inconsistent in length. but maybe i am wrong!

2 things i would suggest: 1- if your track is simply one mesh, you do not need the SceneParser. Just use the TreeCollision like my code snippit above and change the value the 3rd argument and note the differences (so true being optimized and false not optimzed).

Hi dont really understand, you yourself are setting OPTIMIZATION to true and telling me to set it to false.. With optimization set to false, I get more Newton lines and it hurts my game a lot..

Hi dont really understand, you yourself are setting OPTIMIZATION to true and telling me to set it to false.. With optimization set to false, I get more Newton lines and it hurts my game a lot..

yes that is confusing isnt it?

my bad, i actually told you to switch optimiation off but in the code i switch it on. i dont know why i did that.

yes, switching optimization OFF gives you lots more lines because...well, because the mesh is not being optimized! but for me, this is the only way to stop the bug of the my car's wheels going over a line and looking like it has hit an invisible rock.

i was reading through some newton forum threads and found one person who used newton version 1.50 and the problem was fine, but in newton 1.53 (like we are using) he too had the bug. so it seems like the answer is to use newton 1.50 if you can get your hands on it! or wait for the next version of newton, but i have no idea when that will be.

btw, you said your project deadline was december - was this a uni project and how did it go?

Hi..

yeah it was a uni project and it went great for a project completed in one sem.. though we had the physics bug, it didn't show up that much on demo day..

And I did try switching optimization to OFF, no help.. still sux BAD.. well, wht my concern is that we are going to work on the game for one more sem. And I cann't jeopardise whole sem worth of work on the assumption tht Julio will release a patch. From wht I've read from the forums he's nt willing listen to peoples request for releasing a patch. This is highly discouraging for me and I have decided to give PhysX a shot and work on it for the coming two weeks..

As for 1.50, couldnt find a link to it..

From wht I've read from the forums he's nt willing listen to peoples request for releasing a patch.


the problem is, i have read other threads where he has sent the latest version to a few select people with this problem. i would love to get my hands on it. the irony is though, when it does get released i would have finshed my project anyway! i sent him a PM but he did not reply.

what we have to remember though, is that both newton (and ogrenewt) are free and he does this in his spare time in addition to his 9-5 job. im sure there are other phsx libraries bug-free that you have to pay for...


As for 1.50, couldnt find a link to it..


no its taken off newton's web site. i was considering posting a thread requesting it though, but like you, my demo is due soon...

ah well, best of luck.

[edit]
i would love to have a demo of your game btw. mine will be done soon and ill post it for download - both an optimized version and a non-optimized version so you can experience the difference!
[/edit]

[edit2]
walaber has just finished StuntPlayground2. i asked him if he was using Newtno 1.53 and if so, how the hell was he NOT getting the bug that we have? its here if you want to watch it: http://newtondynamics.com/forum/viewtop ... highlight=
[/edit2]

Hmm.. well good luck to u to for ur project.. Only if Julio/Walaber step in to help you (and me) with the bug fix, life would be easier..

My game.. I could post it, but it plays bad coz of the bug (and the fact that we actually used setOmega to turn instead of torque) and would require a PS2 controller attached to the PC.. and then I'll have to make a readme explaining the control scheme.. LOL

anywyas. will do in a couple of days..

regards

Hey

So I did finally release the game.. Look for a post titled Motorball Alpha in the Showcase forums.. Hows your game looking.. ??

nik

hey guys. have you tried running your app with the newton.dll I included with Stunt Playground 2.0? I can't remember what version I used, but the "catching edges of polygons" bug was greatly reduced in that version.

sorry I haven't been around on the forums much... real world work is extremely busy lately.

have you tried running your app with the newton.dll I included with Stunt Playground 2.0? I can't remember what version I used, but the "catching edges of polygons" bug was greatly reduced in that version.


thanks walaber, i tried, but no joy. oh well.

hey guys. have you tried running your app with the newton.dll I included with Stunt Playground 2.0? I can't remember what version I used, but the "catching edges of polygons" bug was greatly reduced in that version.

sorry I haven't been around on the forums much... real world work is extremely busy lately.

Yo.. will try and let u know for sure..

I tried, no lukk here either.. I replaced the Newton.dll. I was expecting it to crash though, as I didn't rebuild it, for some reasons it didn't crash and didn't make any difference..