choppy collision detection

[keless]

I put together a little demo that I wrote in about 2 days: the faerie running
around inside of the room, with a lazy camera.

Unfortunately, her collision detection makes her movements jittery (and thus makes the camera jittery as well).

you can get the playable binary here: (700kb)
http://www.skyesurfer.net/keless/IrrLic ... o_v1.0.zip

Im just using createCollisionResponseAnimator() for the collision detection, and node->setPosition() to move it.

does anyone know of a better way to do this that doesnt result in jitter?

[keless]

Okay, so I found out that the CollisionAnimator only does its checks in OnPOSTRender -- AFTER rendering the first movement.

So, here is a frame by frame of why this is bad:

FRAME 1:
A) user input loop detects 'move forward', sets node ->position( newPosition )
B) node is rendered at this position whether or not its colliding with something
C) after render, the node is moved to a non-colliding position

FRAME 2:
A) the user input loop is not called (i only poll it every few frames)
B) node is rendered at non-colliding position
C) after render, node is still in non-colliding position

....

FRAME X:
A) user input loop detects 'move forward', sets node ->position( newPosition )
B) node is rendered at this position whether or not its colliding with something
C) after render, the node is moved to a non-colliding position



So, even if I did check the input every frame, it seems the object would always be one step into whatever it was bumping against as long as they were moving forward.

The lesson is, 'movement' and 'collision detection + response' have to happen in the same render frame, and in that order. since ISceneNode::setPosition() directly modifies the node's position, it makes sense to move collision code to onPreRender() instead of having to store the new position and apply it during onPostRender.

Im still hoping I'm just doing it wrong, but no one has replied with the 'right' way yet, so...

[Byron]

I dont have a problem with my collision response being choppy using

Code: Select all

scene::ISceneNodeAnimatorCollisionResponse* modelCollider = 
	smgr->createCollisionResponseAnimator( ... ...

Thats how I do my collision detection for the alien when he runs around
you can check it out here:

http://www.jodzilla.com/AI_Tool.zip

You can control the alien with w, a, s, d and space to fire

[keless]

( my computer is doing that thing where it says it loaded in the textures, but the models and level arent textured. though i did see the 'shot' texture, i think )

anyhow, this does look good, and its just off of the IrrLicht collision response animator?

is it possible to see your code, or else, to send you my own?

[Byron]

I think the problem might be your movement code. Mine had a similar choppy movement. Do you make your own OnEvent for the faerie and put that in you main event handler? Like how boogle did the movement in his 2nd version of the third person camera.

I did all the collision detection with irrlicht except the bullet collision, which I wrote a short routine to check, buts it is very inefficient right now, checks every frame and there is another couple of optimizations I could of done but there is only two people who can fire, so there wont be a too many bullits to check so I didnt bother.

I really like the lazy camera, definately a cool idea

Byron

[keless]

no i dont. I just create her, add an animator and let her go.

in my main class's onEvent, if a key is pressed, i set her position forward or rotate her. (though, id prefer setting a velocity vector of some kind to directly manipulating her position)

Ill check out boog's 2nd version cam

[keless]

okay, so, instead of directly calling setPosition() to move his models, Boogle set up a custom animator which does so (and updates the model's animation at the same time).

technically, the animator also calls setPosition() so I dont know why it should be different, but it works, so I'm stealing it

Im creating my own version of his CSceneNode3PPlayerAnimator, which isnt tied to a camera. I call it: CSceneNodeAvatarAnimator. Basically, its exactly the same, minus the camera dependancy (rotations are in relation to its own forward vector, not the camera's).

For my purposes, it'll need to utilize 'attack' and 'jump' animations as well, so I may add those soon.

Anyhow, thanks Boogle and Byron. No more jitters. (I need some more Coke now!)

Its important to note that if you attach the PlayerAnim AFTER the collisionAnim, it DOES jitter when hitting a wall, even in Boogle's code. (Though not as wildly, since his 'forward' is split up into rendered time segments and are smaller). You need to make sure you add the PlayerAnim before CollisionAnim because thats the order they will be applied in onPostRender

[buhatkj]

i didnt even write an animator, but i had the same idea...
i just have a pair of bools in my player class tha switches the movement on or off(set by the event receiver, ON on keydown, OFF on keyup), and before i call the drawall i call the movement function (if movement is switched on it moves him), and move the player a distance based on the current framerate(irrlicht timers). after the draw, the onPostRender does the collision for me of course.

now i'm no expert, but it would make more sense to me if collision was done Pre-render, rather than post-render. i would figure you would want to draw the character at their ultimate position, AFTER both movement AND collision. perhaps it is possible to modify that in the irrlicht source and see if it works/makes sense....

might try that....

and as to why the animator works better, is it called pre or post render? might be the diff....
-Ted

[keless]

i think the reason has something to do with how I was doing it before:
adding the full movement in one renderframe (in my 'update' function, which only happens every few frames).

the animator method, and fmorg's method, both only apply a portion of forward movement with respect to time elapsed between frames.

[Guest]

hello,
can you give example of how to use the 3rd person camera ?
thanks