Rotating camera 180º around Y?

There we go!



rotation.fromAngleAxis(-FastMath.HALF_PI, Vector3f.UNIT_X);

cam.setRotation(rotation);



Fixed the Up/Down inversion!

1 Like

You will find the world looks very stale like that (for example you don’t really see much of the walls etc). In fact most of what people will see are things that can’t actually be seen (for example the tops of walls…which in the case of buildings normally have roofs on them). By looking at an angle you see the walls/windows/doors/alcove with a gargoyle in it/whatever.



I really think you will be better off using a simple chase cam (or one that stays at a certain offset from the main character).



For example a cam which every frame moves itself to being at 0, 20, 20 from the main character and then does a lookAt at him will give you a fixed 45 degree view. You can then adjust the angle as needed from there.

Ok, another misconception I had is that the camera was rotating OVER the origin of the rootNode… big mistake… I’ll get there eventually!

Sorry, didn’t see your post!

The game’s gonna be 2D sprites on 2D terrain. A single layer or several of x.z plane, with everything textured onto it

Something sort of like See a Screenshot of Exile II: Crystal Souls

But with some twists

I don’t even know why I got so fixed on having the field plane as x.z… easier to have it as x.y and also cleaner for coordinates, and I can use the default camera and do it in 2 lines… zzz… thanks for the help everyone!

Hmm, if the game really is completely 2d then you may be better off using one of the 2d game libraries?

This is the first engine I’ve ever used, I only have very little c experience, and enough java to understand concepts and how to use everything (I guess?), and I was told of this one… surely using a “revolutionary” (probably another wrong idea I have of it?) 3d engine would be faster then just straight out using a 2d engine?

But like I said, with some twists… there’ll be lots of nifty things I plan on, so using something completely 2d would not suffice :stuck_out_tongue:

It’s a matter of using the right tool for the job, if you have a use for 3d then JME3 is a good choice. If you are just doing 2d though then there are 2d game libraries out there (although I haven’t used any of them so I can’t recommend one). They would be faster and simpler for pure-2d work as that is what they are designed for and you avoid the complications of 3d.

Yeah but like I planned from the beginning, making it simply fixed on x.y plane or whichevert is I use makes everything easy, the 3rd coord in everything is just ignored :slight_smile:

I had the idea of perhaps making the field “floating”, where I’d have things be slightly on top of each other projecting shadows on the field, I have an idea of how it might be and I think it’s a cool effect that I’d never seen done.

One of the twists I have in mind envolves an alternative dimensions kind of thing where I’ll def. need 3D

Well to shorten everything up, it might make things slightly more complicated to use a 3D engine, I believe you, it’s logical, (besides being the first engine I’ve ever used, it’s pretty simply and I think well organized, not sure if the others are as easy as this one to comprehend?), BUT it gives me a world’s flexibility!

1 Like

So long as you are going into it with your eyes open it’s all good :slight_smile:

Thanks for the insight though :wink:

1 Like

Hey,

i have the exact same problem.



I have no problems with rotating a mesh with quaternions.

It’s a different story with the camera. It gets all messed up.



How do I rotate the camera so it’s looking down while keeping the right orientation ( up is z- and left is x-)



edit:

ok, i’ve managed to get it to work with

DelegateOfMain.getCam().lookAt(characterPosition, Vector3f.ZERO);

}



but I still would like to know how to achieve the same thing with quaternions :slight_smile:

thanks !

So it wasn’t just me being a complete idiot? I feel slightly better about my “skills” now :slight_smile:

What the hell does using a so called “up vector” with the origin do >_<



(I actually could not comprehend what the heck the “up vector” is supposed to influence since the results I did with many test never made any sense to me)

perhaps this will help you understand up vectors:



Nate Robins - OpenGL - Tutors



check out the Projection and lightposition executable. Although it uses OpenGL it still uses the lookAt function, you can change the up vectors and see the result.



It also has some other awesome stuff in it, which can help you understand other stuff like frustums, clipping planes etc… by being able to see changes dynamically.



This pic may help also

As the picture above shows, if your camera is looking DOWN the Y axis, your UP vector becomes either Z or X, depending on its orientation.



Also, by default models will face towards +Z, not -Z as shown above unless you manually change that.

And if you just want to look down 90 degrees… lookAt() is the worst way to do it when it’s easily done with a new Quaternion().fromAngles(FastMath.HALF_PI, 0,0);

pspeed —> not working for me. I still need to rotate in Y axis in 180 degrees.

If you define a rotation via vectors you need two of them. LookAt uses a direction and an up vector. The direction vector is “forward” and the up vector is “up”. If you only know the direction that a space craft is pointing at then you still do not know how its rotated. If you know where the up-direction of the spacecraft is as well then you know the rotation of the craft 100%. Up and direction vector are always perpendicular and always have to be when you use lookAt(), so using a generic Vector3f.UNIT_ vector is almost always wrong. And using a zero one definitely is.

@michalciurus said:
pspeed ---> not working for me. I still need to rotate in Y axis in 180 degrees.


Check your model's axis in whatever 3D software you use. I've seen that happening. If its forward axis is not pointing to +Z then you will probably get something like what you're experimenting.