I'm developing a simple rendering engine as a pet project.
So far I'm able to load geometry data from Wavefront .obj files and render them onscreen separately. I know that vertex coordinates stored in these files are defined in Model space and to place them correctly in the scene I need to apply Model-to-world transform matrix to each vertex position (am I even correct here?).
But how do I define those matrices for each object? Do i need to develop a separate tool for scene composition, in which I will move objects around and the "tool" will calculate appropriate Model-to-world matrices based on translations, rotations an so on?
I would look into the "Scene Graph" data structure. It's essentially a tree, where nodes (may) define their transformations relative to their parent. Think of it this way. Each of your fingers moves relative to your hand. Moving your hand, rotating or scaling it also involves doing the same transformation on your fingers.
It is therefore beneficial to base all these relative transformations on one another as relative ones, and combine trhem to determine the overall transformation of each individual part of your model. As such you don't just define the direct model to view transformation, but rather a transformation from each part to its parent.
This saves having to define a whole bunch of transformations yourself, which are in the vast majority of cases similarly in the way I described anyway. As such you save yourself a lot of work by representing your models/scene in this manner.
Each of these relative transformations is usually a 4x4 affine transformation matrix. Combining these is just a matter of multiplying them together to obtain the combination of all of them.
A description of Scene Graphs
In order to animate objects within a scene graph, you need to specify transformations relative to their parent in the tree. For instance, spinning wheels of a car need to rotate relative to the car's chassis. These transformations largely depend on what kind of animations you'd like to show.
So I guess the answer to your question is "mostly yes". You do need to define transformations for every single object in your scene if things are going to look good. However, orgasnising the scene into a tree structure makes this process a lot easier to handle.
Regarding the creation of those matrices what you have to do is to export a scene from an authoring package.
That software can be the same you used to model the objects in the first place, Maya, Lightwave...
Right now you have your objects independent of each other.
So, using the package of your choice, either find a file format allowing you to export a scene you would have made by positioning each of your meshes where you want them, like FBX or GLTF or make your own.
Either way there is a scene structure, containing models, transforms, lights, cameras, everything you want in your engine.
After that you have to parse that structure.
You'll find here some explanations regarding how you could architect that:
https://nlguillemot.wordpress.com/2016/11/18/opengl-renderer-design/
Good luck,
Related
I know OpenGL only slight and all this docs and tutorials are damn hard to read so i do not helps.. I got some vision though how it could work and only would like some clarification or validation of my vision
I assume 3D world is build from 3d meshes, each mesh may be hold in some array or few arrays (storing the geometry for that mesh).. I assume also that some meshes may be sorta like cloned and used more than once on the scene.. So in my wision i got say 50 meshes but some of them are used more than once... Lets say those clones i would name as a instance of a mesh (each mesh may have 0 instances, 1 instance or more instances)
Is this vision okay? Some more may be added?
I understand that each instance should have its own position and orientation, so do we have some array of instances each element containing one pos-oriantation matrix? or thiose matrices only existing in the code branches (you know what i mean, i set such matrix then send a mesh then modify this position matrix then send the mesh again till all instances are sent) ?
Do this exhaust the geomety (non-shader) part of the things?
(then shaders part come which i also not quite understand, there is a tremendous amount of hoax on shaders where this geometry part seem more important to me, well whatever)
Can someone validate the vision i spread here?
So you have a model which will contain one or more meshes, a mesh that will contain one or more groups, and a group that will contain vertex data.
There is only a small difference between a model and a mesh such as a model will contain other data such as texture which will be used by a mesh (or meshes).
A mesh will also contain data on how to draw the groups such as a matrix.
A group is a part of the mesh which is generally used to move a part of the model using sub matrices. Take a look at "skeletal animation".
So as traditional fixed pipelines suggest you will usually have a stack of matrices which can be pushed and popped to define somewhat "sub-positions". Imaging having a model representing a dragon. The model would most likely consist of a single mesh, a texture and maybe some other data on the drawing. In the runtime this model would have some matrix defining the model basic position and rotation, even scale. Then when the dragon needs to fly you would move its wings. Since the wings may be identical there may be only 1 group but the mesh would contain data to draw it twice with a different matrix. So the model has the matrix which is then multiplied with the wing group matrix to draw the wing itself:
push model matrix
multiply with the dragon matrix
push model matrix
multiply with the wing matrix
draw wing
pop matrix
push matrix
multiply with the second wing matrix
draw second wing
pop matrix
... draw other parts of the dragon
pop matrix
You can probably imagine the wing is then divided into multiple parts each again containing an internal relative matrix achieving a deeper level of matrix usage and drawing.
The same procedures would then be used on other parts of the model/mesh.
So the idea is to put as least data as possible on the GPU and reuse them. So when model is loaded all the textures and vertex data should be sent to the GPU and be prepared to use. The CPU must be aware of those buffers and how are they used. A whole model may have a single vertex buffer where each of the draw calls will reuse a different part of the buffer but rather just imagine there is a buffer for every major part of the mode such as a wing, a head, body, leg...
In the end we usually come up with something like a shared object containing all the data needed to draw a dragon which would be textures and vertex buffers. Then we have another dragon object which will point out to that model and contain all the necessary data to draw a specific dragon on the scene. That would include the matrix data for the position in the scene, the matrix for the groups to animate the wings and other parts, maybe some size or even some basic color to combine with the original model... Also some states are usually stored here such as speed, some AI parameters or maybe even hit points.
So in the end what we want to do is something like foreach(dragon in dragons) dragon.draw() which will use its internal data to setup the basic model matrices and use any additional data needed. Then the draw method will call out to all the groups, meshes in the model to be drawn as well until the "recursion" is done and the whole model is drawn.
So yes, the structure of the data is quite complicated in the end but if you start with the smaller parts and continue outwards it all fits together quite epic.
There are other runtime systems that need to be handled as well to have a smooth loading. For instance if you are in a game and there are dragons in vicinity you will not have the model for the dragon loaded. When the dragon enters the vicinity the model should be loaded in the background if possible but drawn only when needed (in visual range). Then when the dragon is gone you may not simply unload the model, you must be sure all of the dragons are gone and maybe even wait a little bit if someone might return. This then leads to something much like a garbage collector.
I hope this will help you to a better understanding.
I need some pointers on the best approach for a rotation task in OpenGL. I know how to rotate objects in 3D space using quaternions, I can translate them, all well and good.
But I want to know the best way to treat a collection of different objects as a single entity for the purpose of rotation. For example, suppose you have a desk with objects on it. Each has its own translation and rotation, but now I want to rotate the entire desk and everything on it, while keeping other objects in the room in place. This means objects on the outer edge of the desk will rotate and also translate around the center of the desk, while objects at the center might just rotate but otherwise stay in place, or simply not translate by as much, depending on their distance from the axis of rotation.
It seems that a rather inelegant way to do this is to individually rotate and translate each object on the desk, as well as the desk itself, knowing where the axis of rotation is. Perhaps this is the only good way to do it, but is there a technique to "group" disparate objects for this purpose?
What you're looking for are transformation hierachies. The objects on your desk are positioned relative to the desk, or in other words in the coordinate system of the desk. So lets designate M_Desk as the transformation defining the placement of the desk and the local coordinate system of it. Next let be M_Pencilbox the transformation of the pencil box standing on the desk in relation to the desk. And a pencil in the pencil box would be placed in relation to the pencil box.
So the pencil goes through a hierachy of transformations. Remember that in the column major notation used by OpenGL things "flow" through the transformation chain from last transformation to first (or right to left when written down).
Each transformation, like M_Desk for example, is a 4×4 matrix that can be constructed the usual way: Rotations, translations, scalings, etc.
So to transform the vertices of a pencil you'd apply the following transformation
… · M_Desk · M_Pencilbox · v_Pencil
Of course the desk itself may be in relation to something different, like a room. At the very beginning of that transformation chain would be the view transformation. So effectively we're building a modelview matrix here.
In terms of modern OpenGL, everytime you encounter a branch in the transformation hierachy (think of directories in a file system), you'd create a copy of the transformation chain built so far, so that you don't have to restart from scratch for each branch.
Let me know if you need further clearification.
This is generally accomplished by using some kind of scene-graph which incorporates a transform hierarchy.
A simple minimal version would be to have a tree where each node contains an object, a transform, and a list of child nodes. The transform is relative to the parent node.
So the objects on the desk would be children of the desk itself.
The transform for any given object is the concatenation of that object's transform with all its parents in the tree. There are many ways to accomplish that, but the 'old school' GL functionality provides a matrix stack for this purpose. You multiply in the local matrix for a node, draw the geometry for that node, recursively draw all the child nodes, and then pop the matrix back off.
In an educational software (JOGL) I have a hierarchical structure of several rotations and translations that moves a geometric shape (let's say a box) to a point in space.
I can calculate the position and the orientation of the object after translations and rotations using some basic math, but I also want to know if there is a way to read this data directly from OpenGL/JOGL?
The idea is students can see that the calculated position/orientation is equal to the real one (Coming from opengl).
but I also want to know if there is a way to read this data directly from OpenGL/JOGL?
OpenGL is not a scene graph, it just draws points, lines and triangles to a framebuffer, then forgets about the vertices you've supplied. As of such there's not even the trace of the sort of data structure to do this.
Or short: OpenGL doesn't work that way you (may) think it does and there's no such function to retrieve the information you seek, because that's not how OpenGL works.
I want to create a 2D game with monsters build as a custom vertex mesh and a texture map. I want to use this mesh to provide smooth vector animations. I'm using opengl es 2.0.
For now the best idea i have is to write a simple editor, where i can create a mesh and make key-frame based animation by changing position of each vertex and specifying the key-frames interpolation technics ( linear, quadric and so on).
I also have some understanding of bone animation (and skin based on bones), but i'm not sure i will be able to provide a good skeletons for my monsters.
I'm not sure it is a good way to go. Can you suggest some better ideas and / or editors, libraries for such mesh animations ?
PS: i'm using C++ now and so c++ libraries are the most welcome
You said this is a 2D game, so I'm going to assume your characters are flat polygons on to which you apply a texture map. Please add more detail to your question if this is not the case.
As far as the C++ part I think the same principles used for 3D blend shape animation can be applied to this case. For each character you will have a list of possible 'morph targets' or poses, each being a different polygon shape with same number of vertices. The character's AI will determine when to change from one to another, and how long a transition takes. So at any given point time your character can be either at a fixed state, matching one of your morph targets, or it can be in a transition state between two poses. The first has no trouble, the second case is handled by interpolating the vertices of the two polygons one by one to arrive to a morphed polygon. You can start with linear interpolation and see if that is sufficient, I suspect you may want to at least apply an easing function to the start and end of the transitions, maybe the smoothstep function.
As far as authoring these characters, have you considered using Blender? You can design and test your characters entirely within this package, then export the meshes as .obj files that you can easily import into your game.
In my OpenGL research (the OpenGL Red Book, I think) I came across an example of a model of an articulating robot arm consisting of an "upper arm", a "lower arm", a "hand", and five or more "fingers". Each of the sections should be able to move independently, but constrained by the "joints" (the upper and lower "arms" are always connected at the "elbow").
In immediate mode (glBegin/glEnd), they use one mesh of a cube, called "member", and use scaled copies of this single mesh for each of the parts of the arm, hand, etc. "Movements" were accomplished by pushing rotations onto the transformation matrix stack for each of the following joints: shoulder, elbow, wrist, knuckle - you get the picture.
Now, this solves problem, but since it's using old, deprecated immediate mode, I don't yet understand the solution to this problem in a modern OpenGL context. My question is: how to approach this problem using modern OpenGL? In particular, should each individual "member" keep track of its own current transformation matrix since matrix stacks are no longer kosher?
Pretty much. If you really need it, implementing your own stack-like interface is pretty simple. You would literally just store a stack, then implement whatever matrix operations you need using your preferred math library, and have some way to initialized your desired matrix uniform using the top element of the stack.
In your robot arm example, suppose that the linkage is represented as a tree (or even a graph if you prefer), with relative transformations specified between each body. To draw the robot arm, you just do a traversal of this data structure and set the transformation of whichever child body to be the parent body's transformation composed with its own. For example:
def draw_linkage(body, view):
//Draw the body using view matrix
for child, relative_xform in body.edges:
if visited[child]:
continue
draw_linkage(child, view * relative_xform)
In the case of rigid parts, connected by joints, one usually treats each part as a individial submesh, loading the appropriate matrix before drawing.
In the case of "connected"/"continous" meshes, like a face, animation usually happens through bones and deformation targets. Each of those defines a deformation and every vertex in the mesh is assigned a weight, how strong it is affected by each deformators. Technically this can be applied to a rigid limb model, too, giving each limb a single deformator nonzero weighting.
Any decent animation system keeps track of transformations (matrices) itself anyway, the OpenGL matrix stack functions are seldomly used in serious applications (since OpenGL had been invented). But usually the transformations are stored in a hierachy.
You generally do this at a level above openGL using a scenegraph.
The same matrix transforms at each node in the scenegraph tree just map simply onto the openGL matrices so it's pretty efficient.