Posted by philjord on Aug 02, 2022; 10:34pm
URL: https://forum.jogamp.org/how-to-transform-objects-not-using-Transform3D-tp4041515p4041806.html

Ok great stuff, your split code works.

I notice in the key listener you've added empty updaters for all the triangle geometries, however as all the geometries use different parts of teh exact same float array of coordinate points, we only need to call an update to that one shared set of float coords once. So we shouldn't need to do this, however the Java3D scene graph is once again trying to optimize and has decided the other geoms are not "dirty" so it doesn't resend the data to the 3D driver. I have however moved the "dirtying calls" into the single flush to make it tidier.

I've also for clarity put in a bit more output for the transformation variables in use.

At this point I'd note that the "zoom" call you are making are actually scaling calls, so the code as it is now literally makes the cube bigger or smaller. For an actual zoom call we would push the camera itself backwards and forwards, so I've put it a comment on how the zoom method could do that to the view platform (which is the Java3D camera). Note however that what we are doing is actually called  a "Dolly Shot", moving the camera forward and back, a real zoom in a movie would be done by changing the lens position, which can also be done in 3D by altering the field of view, and it does lots of interesting things to the way the scene looks, but is not important here.
notusingtransform3D.java

I'm a but pressed for time so I'm just going to describe concept and give URLs rather than put example code in place.

Your work on front facing is good,
concept
https://www.khronos.org/opengl/wiki/Face_Culling

complex maths
https://computergraphics.stackexchange.com/questions/9537/how-does-graphics-api-like-opengl-determine-which-triangle-is-back-face-to-cull
its about the determinant, notice that it's nearly about the dot product but not quite. You can go with dot product for now, but be aware.


So your front facing  list should be good to go.

The Normal refs you are looking into are in fact for doing something much more interesting than determining the facing of a triangle
Triangles are flat, so the normal from any coordinate is exactly the same, perpendicular to the face.

However is most rendering we actually want our triangle to be a bit curved seeming, so that a lot of them all seem like they are a smoothly curved surface, or possibly mostly smooth with some creases here and there, the use case being up to the artist who draws the 3d object.

So when doing lighting for a pair of adjacent triangle we might want to set the normal to the average of each, so that the phong shading calculation will average or interpolate between them, so there is no noticeable sharp edge.


In fact in a real engine we want every single pixel to be able to point in a different direction, so light can bounce off in any crazy way the artist wants.
https://cgcookie.com/posts/normal-vs-displacement-mapping-why-games-use-normals

Long story short, for today don't think about the per vertex normal, it's for lighting interpolation, not our uses.


>>I also did experiment with GeometryInfo class, but this led me nowhere.
GeomteryInfo is a separate system for generating GeometryArray out of other utilities, it just creates the Geometry then it is not used after that.



>>I suppose that display order is just a matter of sorting ff triangles in Z order, true?
Exactly perfect.


One final note to make life more complex for you, notice that the geometry gets transformed "up the scene graph" until you arrive at a fully transform geometry, this is referred to a virtual world coordinates, some geometry shape plus any positioning elements etc.

If a light existed in the scene it would have a virtual world coordinate (sometime called model coord) and we could compare the position of these 2 object for lighting calcs.

But in addition to these there is also a position for the camera, which is also used in light calcs (specular highlights)

Finally there is a transform required to make the mdoel as seen from the camera into a flat 2-D location on screen

So the rendering engine always wants 3 transforms set 1/ model 2/ view 3/ screen

In a 3D API set by  
gl.glMatrixMode(GL2.GL_MODELVIEW);
and
gl.glMatrixMode(GL2.GL_PROJECTION);

These transforms are simply matrix applied to your coords to figure out where they are, and use the results to do lighting calcs.