Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Author
Message
Lucy
17
Years of Service
User Offline
Joined: 19th Apr 2007
Location: Roanoke, VA USA
Posted: 22nd Aug 2007 12:05
I'm trying to get brakes to work on a vehicle but can't quite figure it out.

In the real world, one simply restrains the wheels from rotating. Restraining the wheels on DarkPhysics seems to have no effect since the locomotion doesn't come from the wheels but rather from the magic smoke. The wheels are just ornaments.

One's first instinct is just to throw the magic smoke motor in reverse and have that stop it. However, there are a few problems.

1: the vehicle takes as long or longer to stop as it took to get going
2: the vehicle begins moving backwards after "stopping"
3: if the vehicle is currently not moving and something starts pushing it (gravity from sitting on a hill or ramp for instance), throwing the engine into reverse is totally inappropriate since the engine's not responsible.

So, how do we stop those wheels from turning and the car from moving? There must be some sort of way to tell the car "Ok, you are resistant to moving along your local X axis, but only so long as your wheels are on the ground". A car flipped upside down with momentum to make it slide forward really should not be able to apply brakes.

Nothing I say is intended to be rude. My autism means that I do not know what is rude and what isn't rude. I apologize if I seem rude. It is not my intention.
Lucy
17
Years of Service
User Offline
Joined: 19th Apr 2007
Location: Roanoke, VA USA
Posted: 23rd Aug 2007 14:10
After some experiementing, it seems that phy set rigid body linear damping can work for braking, but it works even when you're in the air. If we could figure out a way to check to make sure the vehicle is in contact with a drivable surface, preferably if the wheels are.

Nothing I say is intended to be rude. My autism means that I do not know what is rude and what isn't rude. I apologize if I seem rude. It is not my intention.
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 23rd Aug 2007 15:48
You could put invisible guide shapes under the wheels to see if the wheels are touching the ground and then just put your brake script in an IF statement.
Lucy
17
Years of Service
User Offline
Joined: 19th Apr 2007
Location: Roanoke, VA USA
Posted: 24th Aug 2007 04:06
I thought about doing that, but the question becomes "how do I check for contact with a surface?"

Nothing I say is intended to be rude. My autism means that I do not know what is rude and what isn't rude. I apologize if I seem rude. It is not my intention.
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 24th Aug 2007 07:03 Edited at: 24th Aug 2007 07:04
Sparky's collision DLL...?

(My FPS uses Sparky's if you need an example. I can send it to you if you want.)
Lucy
17
Years of Service
User Offline
Joined: 19th Apr 2007
Location: Roanoke, VA USA
Posted: 24th Aug 2007 07:14
Sure, as long as the example is well commented. I've tried using sparky's before and couldn't get the hang of it.

Nothing I say is intended to be rude. My autism means that I do not know what is rude and what isn't rude. I apologize if I seem rude. It is not my intention.
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 24th Aug 2007 07:24 Edited at: 24th Aug 2007 07:33
Ok, well my example is for sliding collision but you can just take the collision out lol. Lemme comment it, I'll edit this post in a sec...

EDIT:

Here's the function I use to calculate sliding collision and reposition the object. I got most of it from someone else on here... can't remember who but they get credit.



So, in my game loop, before the movement controls I recorded oldX,y,and z. After them they were recorded as X,Y,and Z. Those are used when calling the function, where is pretty obvious. The radius is the radius of the collision sphere... so whatever you want. Dyn is your player object, or in your case, your guide cubes, and Obj is the level object.

And instead of the

position object Dyn, cx#, cy#, cz#

line, just put whatever you want to happen on the collision.

Hope it helps.
Lucy
17
Years of Service
User Offline
Joined: 19th Apr 2007
Location: Roanoke, VA USA
Posted: 24th Aug 2007 08:04 Edited at: 24th Aug 2007 08:47
And this can work in conjunction with DP?

Also, this code doesn't seem to be too obvious how to use it on terrain... What are the two sets of XYZ coordinates for?

Nothing I say is intended to be rude. My autism means that I do not know what is rude and what isn't rude. I apologize if I seem rude. It is not my intention.
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 25th Aug 2007 00:33 Edited at: 25th Aug 2007 00:37
Yeah, doesn't interfere with DP.

The x-z1 are the points you record before the movement. The x-z2 are after the movement. Take a look at my game loop:



Notice how before the WASD controls I have oldx-z and after I have x-z? Then you just call them when calling the slidingcollision() function.

Oh, and to use it on terrain, just type the terrain object number for OBJ in the function... like this:



That's where I called it, which is also in the loop. See, I have my old x-z, the new x-z, and then the radius of the collision sphere, then the playerobject and levelobject, which you replace with your object numbers unless you are using a system like mine.
Lucy
17
Years of Service
User Offline
Joined: 19th Apr 2007
Location: Roanoke, VA USA
Posted: 25th Aug 2007 02:35 Edited at: 25th Aug 2007 03:50
Thanks a bunch.

One thing I'm still wondering though is how I'm supposed to do this since DarkPhysics pretty much handles the actual movement itself... Do I do it retroactively? Last actually feed the "current position" the previous position and feed the "desired position" the real current position, then if there is no collision, have it be unable to engage the turning ability, braking ability, etc?

Nothing I say is intended to be rude. My autism means that I do not know what is rude and what isn't rude. I apologize if I seem rude. It is not my intention.
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 12th Sep 2007 04:32
Well Sparky's is really only for collisions and detecting them, the rest can be handed off to DP or DBP.
NeX the Fairly Fast Ferret
19
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 12th Sep 2007 18:30
So, an expensive physics extension that requires an even more expensive physics card to function properly is lacking the functionality to create brakes without the use of a seperate DLL?

Disappointing.

I suppose you could make an actual virtual brake pad with high friction, though.


Since the other one was scaring you guys so much...
Agent Dink
20
Years of Service
User Offline
Joined: 30th Mar 2004
Location:
Posted: 14th Sep 2007 17:27
Quote: "So, an expensive physics extension"


Umm... it's not very expensive. Actually licensing the PhysX engine I imagine is FAR more expensive. We get "full" control over it with DBP commands... The only problem is that we haven't seen an update in awhile. I hope this convention settles some stuff when some of you guys can go and yell at the TGC developers.

Lucy
17
Years of Service
User Offline
Joined: 19th Apr 2007
Location: Roanoke, VA USA
Posted: 21st Sep 2007 01:08
Quote: "So, an expensive physics extension that requires an even more expensive physics card to function properly is lacking the functionality to create brakes without the use of a seperate DLL?

Disappointing."


The only disappointment here is your assumption that you need a PhysX card to run DarkPhysics.

Let me say this as simply as possible so there are no misunderstandings:

AGEIA PhysX is a software physics engine. There are hardware accellerators that make it faster but the only thing you need the card for is fluid mesh generation. DarkPhysics in pure software mode is faster than the NG physics dll.

Nothing I say is intended to be rude. My autism means that I do not know what is rude and what isn't rude. I apologize if I seem rude. It is not my intention.
NeX the Fairly Fast Ferret
19
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 21st Sep 2007 20:44
Well, by "function properly", I mean ALL the features. I am not assuming that you need a card to run the physics program. I know you don't. But quite a few features require the card, and I've seen one or two games pull off quite comparable effects without PhysX. It is my opinion that the limitiations for when a card is not present were only inserted for the purpose of giving people a reason to want one. Fluids are 3D metaballs. It's quite obvious if the fluid spreads out enough.


Since the other one was scaring you guys so much...
Lucy
17
Years of Service
User Offline
Joined: 19th Apr 2007
Location: Roanoke, VA USA
Posted: 25th Sep 2007 03:43
Well yeah, but metaballs are notorious for being slow in software. Frankly, I can live without fluid dynamics. Also, supposedly with the latest drivers and latest update to DarkPhysics, you can run the fluid mesh generation with software only. Although it's slow when you get a decent number of metaballs fluid particles going because of the slow nature of metaballs.

Nothing I say is intended to be rude. My autism means that I do not know what is rude and what isn't rude. I apologize if I seem rude. It is not my intention.

Login to post a reply

Server time is: 2024-09-08 00:46:14
Your offset time is: 2024-09-08 00:46:14