ZGameEditor forum

hi,
i'm working on a first-person game, moving the camera around, and want a 3d model to stay inside the view (like the gun in a fps). i have already positioned it correctly using kjell's matrix library, but i have trouble rotating it right. my best guess is that i can use an arctan function and the view direction vector to get the local angles, but i do not really know which arguments arctan2() requires. could you give me a hint on the above?
thanks.

Hi diki! My advice is to set the transform inside the "OnRender" component to match the angles used in the camera component. This should made the trick. And if the gun is directed oddly (EG: to the right of the player), you can modify the mesh with a MeshTransform when you are creating it. I might post an example later maybe (requires new beta I think)

Here it is:
Some advices:
-what I've done should work but I had no time to use the matrix library by kjell so the gun here is placed at (0,0,0) (the same point of the camera).
-when you create the gun it must ba facing "away from the camera" (like I did in this example) before you put it into the model OnRender.
-The pivot (the point that won't be not rotated) is @ (0,0,0) of the model so be sure to translate it properly before using it
-The two different "TransformGroup" are needed, because there is something I would call "not-coherent way in which the camera is transformed in respect to the other models or components". It looks like for the camera it is "transform x then y" and for the other ones it is instead "transform y then x". I might be wrong, however this example just works
So if you can get this in your project and make it work, tell us!
Bye bye!

Hi guys,

Good advice Francesco .. as long as the gun doesn't need to collide with any other meshes I'd use RenderTransform Components as well. However ( thinking ahead a little ), you probably still need to do the calculations when you want to shoot. I've posted the required calculation some time ago here.

@diki: Using the Matrix Library to do FPS controls is usually overkill, check out jph's Open Source FPS to find out how you can get it right with a simple sin / cos.

@kattle87: Caching one of the vertex dimensions and switching it with another using a MeshExpression is just as easy and probably faster. For example ..
K

hey guys,
thanks for your advice! chaining RenderTransforms is a very elegant solution to get around the incoherent transformations of camera vs object. i completely forgot about jph's nice example shooter, too; sin/cos is less engaging than matrix transformations, for sure ;)
i attached my current progress, which is really not much. depending on the type of gameplay i might invoke, i'll probably need to refactor it a bit, but at least there are no gaping incongruencies for now.

very nice looks great, a tad lonely in there., loven' the gun rattle animation when fireing, aiming will be spray like?
I will have to look into this matrix code soon,. I do plan to get back to my full 3d ideas, but I am still workin' on some simpler 2d games,. and many experiments,. old skool arcadia in my first love.

@jph: i'll have to adjust the animation a bit, this was just quick&dirty :) aiming would actually be rather precise, i just want explicit visual cues - no need to be too realistic. but i'm currently trying to figure out how to best implement shooting - either with actual bullet objects or custom collisions.

@kjell: did your post just disappear?

Hi diki,

No I deleted it myself since it was rather off-topic .. and I figured you had read it by now

Feel free to start a thread on how to prepare your meshes for export to ZGE in Max / Maya / Softimage / ? though in case you need help.

K

@Jph: As long as I can tell you, no need to use matrix stuff right now, even for 3D. But yes we need a Mesh VS Mesh collision and Mesh vs Ray collision, or you do need matrix library for some stuff.
We also might want to add some stuff like bounding boxes, I already got some ideas and ZERO TIME

Hey,

Doing any kind of Mesh Collision without a initial AABB pass is a absolute performance killer. Even with for example Line VS OOBB it pays to multiply the line's matrix with the objects' rotation so you can do a AA based test instead.

Here is a demonstration of this initial pass ( the mesh is generated using a boolean operator stack ).

@diki : Sorry for hijacking your thread afterall

K

I agree! Infact, that's the idea:
if we are going to add mesh VS mesh collision, you will still be able to set 3 variables and they will be used for AABB.
Now we just need to recycle PAPPE's collision code from Bero. I wonder where he is now

kjell: constructive derailing is always welcome :)