Develop Reference

What tile storage structure to use on a side scroller?

I am developing a 2d side scroller in slick2d which i would like to be tile based, but I don't really know how to store the tiles. My game has infinite dynamicly generated terrain and is interactable (a bit like a mix of minecraft and terraria). I am currently using a
Map < Integer, Map < Integer, Tile > >
object but it doesn't seem right because I need dynamic world loading and generation. I am using JBox2d for physics.
Is there any better way to store the data in a more efficient way because only a portion of the world is supposed the be loaded because the world size can become infinitly big

You should take a look at the cunk-approach (There's a good reason games like Minecraft have chunks). Select a chunk size (for example 8x8) and create a Chunk data structure (class). Inside the chunk, you can store the static tiles inside a normal Array[][] if possible (faster), or, if needed, in an ArrayList.
public class Chunk
{
private int xPosition;
private int yPosition;
private Tile[][] staticTiles;
private ArrayList<Tile> dynamicTiles;
...
public boolean isInRenderRange()
{
...
}
public boolean isInUpdateRange()
{
...
}
...
}
Then you can go ahead and create the Level data structure. I would recommend something like a basic ArrayList where you can just add and remove elements as you which. You can just iterate over all elements (chunks) in your update and render methods and check for isInRenderRange() and isInUpdateRange().
This will give you the benefit of not having to deal with very complex data-structures like multi-linked lists. You can just change each chunks x- and yPosition when moving backwards, forwards, upwards or downwards. Each tile inside the chunk should have a reference to the chunk they are in in order to get their absolute position.
If you have huge loads of chunks you can sort the ArrayList once in a while to make use of branch-prediction in the extensive render and update calls.

If you are only scrolling one way (like Mario 1) then you need something like a linked list representing the left to right transition. At each node in the linked list you want an array (or possibly a structure) of tiles representing the tiles top to bottom for one horizontal point.
You then hold a link to the current node (i.e. the vertical structure that is at the left of the screen) and each redraw you go from the current point in the linked list forward, drawing vertical strips as you go.
If you want to go backwards (like Mario 3) you'll need a doubly linked list type structure so that your start pointer can move backward.
Going up and down would require either a more complex structure or a smaller vertical representation of the linked list structure.

Understanding 3D Models and Nodes in Libgdx

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!

OpenGL 2.0 ES how does a matrix stack work?

I am having some performance problems with OpenGL. I essentially want to create a grid of squares. I first tried to implement it where each square I would translate to where I want a square, then multiply the model and view matrix, pass it into the shader program and draw the square. I would do this for each square. After creating about 50 squares the frame rate would start to drop to less than what I desire.
I then tried a VBO method where I basically would generate a vertex buffer each time the squares change location. Frame rate increased dramatically with this approach, but I have too much latency when something changes because it has to regenerate all the vertex locations.
What I think I need is a matrix stack... I used opengl 1.1 before and would use push/pop. I don't really understand the concepts of what that was doing though and how to reproduce it. Does anyone know where a good example of a matrix stack is that I can use as an example? Or possibly just a good explanation for one?

You can check this tutorial, is basically doing the same you want to achieve, but with cubes instead of squares. It uses a VBO as well:
http://www.learnopengles.com/android-lesson-seven-an-introduction-to-vertex-buffer-objects-vbos/
About the matrices, in OpenGL ES 2.0 you don't have any matrix related functions anymore, but you can use the glmath library, which does the same (and much more):
http://glm.g-truc.net/
It's a header library, so you just need to copy it somewhere and include it where you need it.
I'm not sure if I completely understand your objective, but I guess you could copy the data of one square in the grapic card (using a VBO) and then repeatedly update the model matrix for every square.
The concept of a matrix stack makes sense if your squares have some kind of hierarchy between them (for instance, if one of them moves, the one to its left has to move accordingly).
You can imagine it as a skeleton made out of squares. If the shoulder moves, all the pieces in the arm will move as well (hands, fingers, and so on).
You can emulate that by using a matrix stack. You can create some kind of tree with all your squares, so that every square has a list of "descendants", which will apply the same transformation as the parent. then you can render recursively all the squares like that:
Apply transform to the root square(s)
Push the transform in a queue
Call the same render function for every child
Every child reads the matrix on the top of the queue, multiplies
it by its own transformation, push the new matrix on the queue and
calls the children
After that every child pops out the matrix they pushed before
Using the glmath is quite easy, you just need to create a queue (std:vector in this case) of matrices:
std::vector<glm::mat4> matrixStack;
And then for every child:
glm::mat4 modelMatrix = matrixStack.back();
glm::mat4 nodeTransform = /*apply your transform here*/
glm::mat4 new = modelMatrix * nodeTransform;
matrixStack.push_back(new);
/*Pass in the new matrix to the shader and call to glDrawArrays or whatever to render your square*/
for (every child) {
render();
}
matrixStack.pop_back();
For the drawing part, I guess you could bind the vertex array with the square vertices, and then update the model matrix in the shader for every child, before calling glDrawArrays.

3D Game Geometry

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)

Changing Pivot Point in Java3D

I've imported some 3d models in java3D and I want to change the pivot point of my model from the origin to a specific point!
Please don't say to translate to origin, rotate and then translate back
I want to know the exact way .

This helped me. The idea of translation is good, actually, do it like follows:
Create a TransformGroup "tg" for example containing the node you would like to rotate and/or translate.
Be sure that you translate it to the point you want to be your pivot point.
Then, create a new TransformGroup containing tg, and rotate it.
Translate back then (translate with the same vector*(-1)).
Rotation around a specific point (eg, rotate around 0,0,0)
This helped me

If I understand what you mean, you should traverse the scene graph produced by the model loader, find any GeometryArrays in it, and translate all the coordinates in the GeometryArrays (this is no simple task -- coordinates can be stored in a number of ways). That way a simple rotation transform would rotate around a different pivot point than before.