I would like to do some 2D (ok, I’ve read all that stuff about using other engine instead of JME3 for that, leave it :)), and I set the ortho projection. However, it happens that the coordinates at which objects are rendered and sized, have nothing in common with traditional 2D screen coordinagtes. This is understandible, because ortho simply removes perspective, leaving everything else as it was with 3D. The question is - is there any way to set up the view or camera so that positioning and scaling works like on a real 2D screen? Like if i have a 1920x1080 screen, and I want a quad, placed on 1900x1060 and sized 20x20 to fit exactly in the lower right corner of the screen and look like a 20x20 rect?
I could make a helper class to transform screen coordinates in 3D but that looks like a bit of overkill if there is a possibility to make it, changing projection settings.
Why not just use the guiNode which is already setup this way?
Hmm, you are right. I have researched it and it is a little strange node because: 1) it still has the Y axis up (not deadly) and 2) I was unable to get collision results of cursor with anything placed under this node. I can go the manual way, since it is plain 2D, but maybe I am doing something wrong and there is a way to get collision results with cursor ray? My assumption is that there is some other camera for GUI, maybe I should use it for ray calculation?
- why is that a problem?
- just test the x,y coordinates, even if it worked, ray-casting the guiNode is overkill
- No big problem, just all my life it was the positive down, here it is simply opposite. No problem, just need thinking in opposite vertical direction. Well, anyway, I can write an adaptor that automatically converts the coords. From any angle you look, just some additional job to do. No big deal, however.
- Yes, I am now doing just this, testing the coords. It works. For rectangles and circles. But, I still would prefer the raycasting. Because it is automatic. It automatically works for any kind of complex shapes. And not only it detects if the shape is being hit, but it also gives the coords! And it is fast enough to work with any sensible amount of gui elements on modern machines. My application is heavily based on cursor picks, and I have the 3D picking implemented perfectly already. So why need extracode - one for plain 3D objects, attached to the rootNode, and the other code for 2D objects attached to the guiNode? If they are really same? I see your point, but in this situation, ray-casting is profitable. I strongly do not wish to lose uniformity of approach for 3D and 2D objects.
I have tried the ray-casting with the camera that I get by calling SimpleApplication.getGuiViewPort().getCamera() - it does not work.
Hmmm… I do collisions on the guiNode all the time.
Really strange. I am using the approach described here:
hxxp://vvv.hub.jmonkeyengine.org/wiki/doku.php/jme3:advanced:mouse_picking
It works for everything attached to the rootNode, but for nothing attached to the guiNode. I have tried with the usual camera and with the guiViewPort camera - nither works.
You must be doing something differently?
How are you constructing the ray for your ortho intersects?
Here’s how I do it:
[java]
Ray mouseRay = new Ray( new Vector3f( cursor.x, cursor.y, 1000 ), new Vector3f( 0, 0, -1 ) );
CollisionResults results = new CollisionResults();
int count = guiNode.collideWith( mouseRay, results );
[/java]
Sorry for answering so long, I had very little time, and also I wanted to make a more thorough research of the problem. It happens that your code works fine!!! I was using this very code from the tutorial that I have mentioned:
[java]
val click3d = cam.getWorldCoordinates(Vector2f(cursor.x, cursor.y), 0).clone
val dir = cam.getWorldCoordinates(Vector2f(cursor.x, cursor.y), 1f).subtractLocal(click3d).normalizeLocal
new Ray(click3d, dir)
[/java]
strange that this code does not work. As far as I understand it, it has to work.