Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[advanced_set]

Hello!

In my application (for which basically I intend to use GIS data), most objects are already in a 'world', so in theory my model matrix could be the identity. Everything is measured in meters, and I would definitively prefer to keep that way to play with the models / data.

Initially I thought I could place a camera over a city (much bigger box) and that the projection would take care of transforming 'world'  coordinates (arbitrary 'box') to device coordinates (-1,-1,-1)  to (1,1,1) 'box'. But now I wonder if the 'world' in opengl tutorials only refer to rearranging objects in relation to each other.

For now, I need to create an extra step 'WW' (real world to device world) before using  view and transformation matrices: T * V * WW * M * V
(in my case, a model matrix would be required only to moving objects)

Do the 'cameras' in JOML (perspective, ortho) are bound to a (-1,-1,-1) to (1, 1, 1) 'box'? In other words, do I have to scale my real world in the model matrix before using view and transformation matrices?

 I would prefer to embed the WW step in the transformation matrix and work with my 'real' world up to the view step if this is possible (I am having a hard time to move from 2D to 3D, I still can't visualise all the maths)

other thing I couldn't still figure out is whether or not the transformation matrix fixes the aspect ratio and what do we need to update when the GLFW window is resized.

--

minor questions / comments:

1. great library! but I saw that some parts are patented. Do this contaminates the entire library or one just need to avoid using a few methods for a commercial application?

[Kai]

If you keep your units consistent (for example everything in meters), then you can work with those units everywhere, including the projection, the camera/view/eye and the model matrices.
The near/far planes in the projection matrix then becomes distances measured in meters, the position of the camera/lookAt() becomes meters, your model matrix translation becomes meters, etc.
So, if you work with one unit of scale consistently everywhere, you should have no problems.

For working examples, do have a look at the joml-lwjgl3-demos repository. It tries not to focus so much on OpenGL (as the lwjgl3-demos do) but on the matrix/vector stuff.

About aspect ratio: If you use Matrix4f.perspective() (which is just GLU's gluPerspective()) then it has the "aspect ratio" as the second parameter and you can deal with that this way. Just use (float)windowWidth/windowHeight as argument.

About the patented code: Yes, you should be fine so long as you don't use it. However, it might become difficult to prove/argue that, should there be really any confrontations (which I doubt). Therefore, it is going to be removed in the upcoming 1.8.7 maintenance release and all following releases.

[advanced_set]

Thanks! I am already exploring the demos.

Just a note: some of them, ig. PolygonDrawer, as well as some of lwjgl demos, ig. SpaceGame, are not working properly on retina displays.

It seems glfwCursorPosCallback is sending window coordinates, not framebuffer coordinates for hi-DPI displays. So, mouse actions are 'scaled down' to the upper-left corner of the window.

although, there seems to be some care to retrieve the correct framebuffer size in some parts of the source code, it seems that all callbacks need some code to convert window to framebuffer coordinates? Perhaps, a simple scale factor would do? (set to 1 for normal displays?)

[Kai]

Thanks for the info with the retina display. I've pushed a (supposedly) fix for the lwjgl3-demos demos. Could you probably try it and see if this issue is fixed?

[advanced_set]

The SpaceGame (the one I spotted the bug) is working properly now.