I am trying to get a better understanding of the Models and their Nodehierarchy in Libgdx.
As much as i understood, a Model is made of many ChildNodes, which can contain other Nodes as well. Each node has a Vector3 translation describing its position, Vector3 scale, describing its scale and Quaternion rotation describing its rotation, all relative to the parent Node or Model. The Matrix4 gloabalTransform describes the same, but relative to the world they are in.
Now if i think about games like Garrys Mod, where the Models of the Players can move parts of the model dynamically (for example if they lie on an edge after they died their upper body can hang down the wall), i can only think about, that they modify the single Nodes at runtime, in their source code.
Now my questions:
Is my assumption correct?
Do i have the possibility to create the Nodes in Blender (lets say 1 Node is the left lower leg, 1 Node is the left upper leg...) and get and change them at runtime by using (for example) modelInstance.getNode("leftLowerLeg").translation.set(Vector3 position), or are they created and named automatically, depending on the shape, facecount...?
Thanks a lot!
Looking at that it appears that the concept of node is that of scene graph. Your model can be made of parts (MeshPart) and each separate part is a child of a node. Having a separate node means you can apply transforms to it thus moving it independently from any other model part. So it appears that you do want to construct your model as separate parts and load those parts in a hierarchy of nodes to suit your needs. Keep a reference to the node you want to move independently and apply transforms.
Node can "contain" a MeshPart (i.e. MeshPart is child of Node) Nodes can contain other nodes. take a look wikipedia for scene graph terminology. Hang on the docs for Model say "A model represents a 3D assets. It stores a hierarchy of nodes. A node has a transform and optionally a graphical part in form of a MeshPart and Material. Mesh parts reference subsets of vertices in one of the meshes of the model. Animations can be applied to nodes, to modify their transform (translation, rotation, scale) over time." Note it says sub set of vertices which implies that the model is one model but you separate them for your needs assigning different sub sets into Nodes.
From Xoppa:
This tutorial shows how to use the node hierarchy from the modeling application.
Here are two tutorials explaining the node structure and how to use it:
Theory
Practical
I am currently working on this exact problem. Nodes can have nodes which can have nodes! You can find a specific node using ModelInstance.getNode(String NameOfNode); which returns an object of type Node. These nodes are named what you named the objects in blender. EG, to get the Right shoulder bone in a model with the bone named Shoulder_R, you could do:
Node node = myModelInstance.getNode("Shoulder_R");
node that contains all the information pertaining to that bone, including translation, rotation, scale, and the appropriate transform matrices. I am currently stuck at the point of trying to manipulate these bones while an animation is playing, post the animation controller update.
My desired end result is to manually modify for example where an arm is pointing so its pointing at another object while the animation and model continue to play/move. I hope this helps you in your quest, and if you discover the answer to the remaining part of the mystery, please post back!
Related
I'm kinda new to LibGDX, and trying to understand the basic Model system, with nodes, meshes etc. After hours spent reading the wiki or looking at the documentation, I would like to know if I'm right.
A Model (that can be rendered using a ModelInstance) is composed by many Node's. A Node is basically kind of an abstract concept, it's a set of data, containing a position, rotation and scale value. It also contains a globalTransform variable (a Matrix4 instance), and using this matrix to set the position / rotation / scale by using Matrix4#setToTranslation will set the position of the Node in the current World. Although, using the position vector in the Node directly doesn't change the world position.
Then, each Node can have children. These children can be other Node's, NodePart's (= MeshPart + Material) or MeshPart's. A MeshPart is a subset of vertices coming from a Mesh. To add a MeshPart to the Node, we can create a MeshPart with a MeshBuilder using the part method. To add a NodePart, we can create a ModelBuilder and use the part method.
Our Model finished, we can create a ModelInstance, either by putting the entire model in a ModelInstance (new ModelInstance(model) ) or by specifying which node of the Model we want to use in our ModelInstance. Then we call the render method from a ModelBatch to display our ModelInstance.
As a conclusion, The relationship between Model and Node is "the same" as the one between Node and NodePart, and the same as the one between Mesh and MeshPart
Are my assumptions correct ? I'm not sure if I'm right at this point : "We can add a MeshPart to the Node as a child"
Thank you very much for reading !
Askigh
I already created graph with different color each graph based on some attribute in its node. This is my current graph
Is it possible to place node that has same color closely? How could I implement that?
I am looking for a similar functionality and came across Viewers (http://graphstream-project.org/doc/Tutorials/Graph-Visualisation_1.0/). I disabled the default viewer and mentioned co-ordinates for individual nodes (which works but doesn't look pretty and is additional headache to mention co-ordinates in the code).
However, I haven't figured out if we can still use default viewer and group nodes based on some attributes.
Let me know if you figure out a way to do that.
I see that there are some fairly similar questions, but those are mostly regarding performance. I would be very grateful if someone could take the time to explain as to how I could implement what I currently have into the vertex shader(For animation, as the title states).
I have a simple .FBX file reader which extracts the following:
Vertex coordinates (X, Y, Z);
Vertex indices;
Normal coordinates (X, Y, Z);
As far as bones go:
Bone names
Indices of the vertices attached to the bones;
The weight of each of the vertices;
A 4x4 matrix array of the bone. (Not sure how this is laid out, please explain! Wouldn't the matrix only hold the position of 1 end?)
Help appreciated!
Looks like you may be missing a few things. Most notably, the bone hierarchy.
The way it typically works, is you have a root node, whose transformations propagate down to the next level of "bones", whose transformations propagate, and so on until you reach the "leaf" bones, or bones with no children. This transformation chain is done using matrix multiplication.
There are a few ways to then transform the vertices. It's sometimes done with with an "influence" that is decided on beforehand and is usually loaded from a 3d application such as 3dsmax.
There's another way of doing this which is simple and straightforward. You simply calculate the distance from the vertex to the bone node. The influence of the bone's transformation is directly related to this distance.
The 4x4 matrix you speak of holds much more than just position. It holds rotational data as well. It has the potential to hold scaling data as well but this typically isn't used in skinning/bone applications.
Getting the orchestra to play together nicely requires a thorough understanding of matrix math/coordinate systems. I'd grab a book on the subject of 3D math for game programming. Any book worth its weight will have an entire section devoted to this topic.
I am trying to parse an XML file in java, after I have to represent it as a tree using Jframe like this
Trees are generally one of the easier linked constructs to lay out like this, because paths generally don't "merge" or "cross".
You can approach it in a roughly tabular way by traversing the tree "left to right": start at the root, and draw its representation at the top left of the area. Then, traverse its "left" branch one level at a time, drawing those nodes' representations on successively lower "rows", in the same "column" as the root. Then, as you move to the "right"-side nodes, draw that node in the next "column" available to the right on the same level. This will produce a ramp-shaped graph of the tree's structure.
You can add some pre-analysis of the number of levels and nodes at each level, which will allow you to "center" the tree into a rough pyramid shape by knowing the maximum number of levels the graph will require and the number of nodes at each level of that graph. But, that requires traversing the entire graph before you start drawing anything.
As for "arranging" a tree's nodes so they fit in the smallest area without arrows crossing or overlapping, that's a problem with a scope far exceeding the average SO answer.
There are lots of good libraries for visualizing graphs.
Here's a pretty extensive list of options: http://s6ai.livejournal.com/33969.html
Us the standard forms to print the image
http://www.java-forums.org/awt-swing/6763-how-display-image.html
Prefuse could probably create something aesthetically similar. Of course, you could go the primitive route and do the graphics manually. For an XML to graph transform, the TreeMLReader API may be of some use, however you might have to convert the XML to the TreeML format with XSLT first.
I have a simple game that uses a 3D grid representation, something like:
Blocks grid[10][10][10];
The person in the game is represented by a point and a sight vector:
double x,y,z, dx,dy,dz;
I draw the grid with 3 nested for loops:
for(...) for(...) for(...)
draw(grid[i][j][k]);
The obvious problem with this is when the size of the grid grows within the hundreds, fps drop dramatically. With some intuition, I realized that:
Blocks that were hidden by other blocks in the grid don't need to be rendered
Blocks that were not within the person's vision field also don't need to be rendered (ie. blocks that were behind the person)
My question is, given a grid[][][], a person's x,y,z, and a sight vector dx,dy,dz, how could I figure out which blocks need to be rendered and which don't?
I looked into using JMonkeyEngine, a 3D game engine, a while back and looked at some of the techniques they employ. From what I remember, they use something called culling. They build a tree structure of everything that exists in the 'world'. The idea then is that you have a subset of this tree that represents the visible objects at any given time. In other words, these are the things that need to be rendered. So, say for example that I have a room with objects in the room. The room is on the tree and the objects in the room are children of the tree. If I am outside of the room, then I prune (remove) this branch of the tree which then means I don't render it. The reason this works so well is that I don't have to evaluate EVERY object in the world to see if it should be rendered, but instead I quickly prune whole portions of the world that I know shouldn't be rendered.
Even better, then when I step inside the room, I trim the entire rest of the world from the tree and then only render the room and all its descendants.
I think a lot of the design decisions that the JMonkeyEngine team made were based on things in David Eberly's book, 3D Game Engine Design. I don't know the technical details of how to implement an approach like this, but I bet this book would be a great starting point for you.
Here is an interesting article on some different culling algorithms:
View Frustum Culling
Back-face Culling
Cell-based occlusion culling
PVS-based arbitrary geometry occlusion culling
Others
First you need a spatial partitioning structure, if you are using uniform block sizes, probably the most effective structure will be an octree. Then you will need to write an algorithm that can calculate if a box is on a particular side of (or intersecting) a plane. Once you have that you can work out which leaf nodes of the octree are inside the six sides of your view frustum - that's view culling. Also using the octree you can determine which blocks occlude others (sometimes called frustum masking), but get the first part working first.
It sounds like you're going for a minecraft-y type thing.
Take a look at this android minecraft level renderer.
The points to note are:
You only have to draw the faces of blocks that are shared with transparent blocks. e.g.: don't bother drawing the faces between two opaque blocks - the player will never see them.
You'll probably want to batch up your visible block geometry into chunklets (and stick it into a VBO) and determine visibility on a per-chunklet basis. Finding exactly which blocks can be seen will probably take longer than just flinging the VBO at the gpu and accepting the overdraw.
A flood-fill works pretty well to determine which chunklets are visible - limit the fill using the view frustum, view direction (if you're facing in the +ve x direction, don't flood in the -ve direction), and simple analyses of chunklet data (e.g.: if an entire face of a chunklet is opaque, don't flood through that face)