Movement

Okay. I have been exploring all of the movement types that have been integrated into blender: Force, DLoc and LinV motion. But I have found all of these problems with them.

Force: Starts out rather slow and the longer you go the faster you go. This has been my experience with that

DLoc: Has the tendency to move through geometry.

LinV: When coming off of a hill, you just keep going at the same hight as the top of the hill when the hill stops.

Question A: Is there any other settings that I can access to make these settings a bit more bearable?

Qustion B: Which one is the best?

~Le Main Rouge

Force: Yeah, that’s the point. You can’t make a car go from 0 to 60 instantly, can you?

DLoc: This moves the object without the object existing in the intervening space. Essentially teleportation. Obviously, works better in smaller steps.

LinV: Its gravity defiance could be a glitch, but I think it has to do with the difference between “set” and “add”: if you set velocity to (10,0,0), then there’s no z-movement, right? I still think it’s a glitch.

Answer A: Not really.

Answer B: It depends on what you’re trying to do. Slow-moving characters do well with DLoc (walking people have very little acceleration, so Force isn’t good). Force is good for vehicles although it’s a little hard to tweak. LinV I’ve never found a good use for.

Something that you can do is a python code that changes the linV in time, that way you get a very controlled acceleration, but you have to be carefull, may get nasty results done wrongly.
http://cloud.gl.googlepages.com/acoupleofthings
Here I got a mid 90’s like racing simulator, maybe with lots of bugs, but managed to control acceleration and some slidding issues.

Thanks peeps.

Toomai: Good Point. I’ve never gotten a car to do that, but I’m still workin on it ;).
Cloud_GL: I’ll give it a try, I’m not much on scripts, but I need to get rid of that bad habit.

in this next session, I am going to ask people what they use in their games.

PlantPerson: What movement did you use in “Into The Titan?”

Rusty246: What movement did you use in you RPG?

Anyonelse: What movement did you use in the various game projects that you’ve been a part of?

Dloc, Drot

Anyonelse: What movement did you use in the various game projects that you’ve been a part of?
As far as I’ve heard, using Dloc isn’t very good idea because it isn’t physical, so avoiding it would be best, and if the material’s friction wouldt work the annoying sliding problem of linV wouldn’t be present, I think.
About linV’s gravity-defiance problem, simple use the Touch sensor so it only moves while on the floor, it improves things a lot (unless you want something that flies of course :D).

No thats silly, I use it all the time, lol. But I seldom use dynamic. It depends on the model, and what it is used for.

Actually I never use dynamic, lol.

Cloud_GL: Yes I’ve tried that, but things get nasty when you use the touch sensor and are going down a sloped object.

DLoc doesn’t always go through things, only when the thing you are moving is going somewhat fast. I think it is good for things that are walking, but when you go to run sequence… Eew.

Also, this is more of a physics question than a movement question, is it possible for Dynamic Object A to collide into Dynamic Object B and Not Move It and have Dynamic Object collide into Dynamic Object A without moving it?

You could always increase the object’s mass. It’ll increase its inertia (that is, make it harder to change what it’s doing including being stopped).

I’ve used Dloc for mine as the LinV floating thing is really bothersome. I tried to put a small LinV downward with my forward to keep it on the ground but the character would stutter and jerk when moving.

hmm, ok thats a different question, lol. Thought you just wanted to know what we all used.

You could do a little work around, with an invisible ghost plane attached to each. And set it for collision and send a message, then you wouldnt bounce?

I think.

umm, if you want the player to not float when using linV, make another sensor for collision, and floor and connect it to the same AND controller as all your movements you intend to be only possible when touching the ground.

Give your floor mesh a property named “floor”…(same with every object you want them to be able to walk on)

now it cannot float anymore… it has to be touching the floor to move .
(You can use a ray on the -Z too if you want to save some CPU power.it is just harder to set up than a collision)
LinV is how I do most of my ground movements… Dloc will make so you will fall thou walls and floors. Force will accelerates until it is going too fast, and also blast through walls and floors.

The LinV float thing is not a bug. Bullet physics does not have true gravity, Gravity is simply a constant force of -9.8 (or whatever you have it set to) on the global Z-axis. When you use LinV in “set” mode instead of “add” mode, you are replacing whatever gravity induced downward velocity the object has with your (global) LinV Z-axis settings (or the calculated global Z velocity based on the local axes of the object, if you are using LinV in local mode).

Here’s my solution for the floating problem: Use a collision sensor set to Inverse mode (it will fire when the object is not colliding with anything). Use a Python script to set the values of the Motion actuator based on user input and collisions. If the Inverse collision is firing pulses (“if myCollisionSensor.isPositive()”), then set the LinV for the Z-axis to -9.8. Otherwise, set it to 0 (it gets jumpy if it’s always set to -9.8).

Personally, I think that LinV is a better solution than dLoc, because it works based on physics calculated motion, not discreet steps in Blender Unit values. Hence, LinV will not give you the (very un-professional) falling through the ground and etc problems that dLoc produces.