I succeeded in creating a VBO measuring about 200 MB on a 64-bits machine under Cent OS Linux 5.3. I used this option but with a greater value of course.

Nice, I will try the same, that is VBOs.

However just a question about the displaying the image over the screen.

I am testing now how a 3d view of my model looks like. I applied a mouse listener and I can rotate and zoom, but I would like that it could rotate only around the X and Y axes. The problem arises when I rotate it first over Y axes, lets say, for 90° in left or right direction and then I try the rotation over X, but in this case the rotation is over Z for me.

I guess when I rotate over Y for 90°, also the model coordinating system rotate with it, and that is why its X axes corresponds to the Z axes in my coordinating system (the viewer).

Are you trying to implement a virtual trackball? There is an exemple of implementation using it in MSG (minimal scenegraph) and another one in Ardor3D, look at OrbitCamExample. I already implement it at work, do you use Euler angles?

Are you trying to implement a virtual trackball? There is an exemple of implementation using it in MSG (minimal scenegraph) and another one in Ardor3D, look at OrbitCamExample. I already implement it at work, do you use Euler angles?

No no

I am just trying to get a custom 3d view of a model, like this

However, I found a solution, but this implies that I do set the modelview matrix by myself

When you rotate an object, you're also rotating its axes so that further rotations are along those axes. So in order to get the picture on the bottom, you rotate on the X axis, then on the Y axis, which has now been rotated to be where your Z axis used to be.

It helps to visualize this for real: head over to an arts and crafts store, and get three colored pencils: one each of red, blue, and green, and a styrofoam ball. Poke the pencils into the ball so that the red pencil points right (X axis), the green one points up (Y axis), and the blue one points toward you (Z axis). When you want to visualize a rotation along an axis, loosely grab with your right hand the axis you want to rotate, pointing your thumb away from the ball. The direction your fingers curl is the positive direction of rotation.

Stick the rig on a spike like one from an office supply store and you can keep it in place while you visualize rotations.

Of course you can just fire up blender and do the same thing, but it's not nearly as fun.

When you rotate an object, you're also rotating its axes so that further rotations are along those axes. So in order to get the picture on the bottom, you rotate on the X axis, then on the Y axis, which has now been rotated to be where your Z axis used to be.

It helps to visualize this for real: head over to an arts and crafts store, and get three colored pencils: one each of red, blue, and green, and a styrofoam ball. Poke the pencils into the ball so that the red pencil points right (X axis), the green one points up (Y axis), and the blue one points toward you (Z axis). When you want to visualize a rotation along an axis, loosely grab with your right hand the axis you want to rotate, pointing your thumb away from the ball. The direction your fingers curl is the positive direction of rotation.

Stick the rig on a spike like one from an office supply store and you can keep it in place while you visualize rotations.

Of course you can just fire up blender and do the same thing, but it's not nearly as fun.

So you are telling me that there is no solution?

I guess the problem is just to connect somehow the second rotation to the first one with some geometric formulas

I didnt found anything about using a single normal vector per triangle with VBOs

..do you know if it is possible?

This is impossible. All attributes (colors, texcoords, normals, etc) are specified per vertex, not per triangle.

What a pity, I saw it was pretty easy with glBegin/End and I hoped it could somehow possible also with VBOs..

However, I am now exploring the advantages of an indexed VBOs (based on your previous tutorial link). It looks very cool because you can for sure make your vertex array much more compact (and since I am experiencing problem over 2M buffers..)

The only "problem" seems to be the index creation. I am formulating just very roughly (i guess) method, like scanning the whole array, looking for duplicate vertexs, removing one of them and then write in the index array the indexed vertex order..

You can make something like this:...I wrote this in the reply, so it might have compile errors.

Hashes obvious, cool! Thanks Riven

But I have a question: how can you interleave vertexs and normal vectors with an indexed array?

I mean, since every vertex has his own normal (at the moment I am just rewriting the normal vector for the i-th triangle three times, once for each vertex), at the end how you can establish which normal vector assign to a vertex that is shared by two or more triangles?

You don't; each normal is duplicated, not shared. A vertex is specified in its entirety by the complete set of its data: coordinate, normal, texcoords, colour, etc. The whole lot is reference by a single index.

If you thought that wasn't the case when using glBegin()/glEnd(), you are mistaken - it is an illusion. glVertex() commands inside a glBegin()/glEnd() actually copied the last specified colour/texture/normal for you behind the scenes.

It's probably worth noting that except for certain pathological edge cases (a box being the most common one) you very rarely want to share vertex positions but not normals. For any 'normal' model like your bunny it only really comes up at crease edges, and those will be a tiny fraction of your total vertices.

Also note that aggressive indexing like removing duplicates in models e.t.c. may REDUCE performance, due to the data not being linearly laid out. I found it better to just keep duplicates of vertices in many cases.

True, but you can optimize the layout of your data to fully utilize the vertex cache (non-trivial calculation). With a near-perfect solution you can calculate it in O(n).

This can be slightly faster in the general case, and much faster if you have a heavy vertex shader. If most of the vertices are unique, the level of indirection will indeed hurt performance.

In a small test I made, I had vertices that were each used in 4 to 8 different triangles (average around 7), and it was faster to make all of them unique even if that gave me several times more data to process. Granted, it was impossible to lay out the data in a really effective way.

However, I have the feeling that all of this belongs much more to what should be the tuning part :p so I would leave for the moment all your precious links and comments for later (I am not ironic, seriously)

Focusing back on the core part, after the rapresentation of my model I would need to put a light within the cabin and see where the shadow hits the ground, in terms of space (supposing I surround my model with a circle on the ground, I would need to know how many and how much shadows there are, not only by a graphical view but also by values, i.e: the biggest shadow is 2m long on the circle perimeter in front right side)

Another guy mentioned that since it is (or look) impossible to directly obtain the output from a shader, a solution might be using FBO

I guess I found the right way, another guy suggested me the following:

Quote

One way to do this is to create a FBO (frame buffer object) that has the dimensions of your plane. You'd then set up rendering to go into that FBO instead of the usual application buffers (that are displayed on the screeen) and have your modelview/projection matrices perform the projection of triangles onto the plane. Clear the FBO to white, enable GL_MIN blending (glBlendEquation(GL_MIN)) and render the triangles in black. Then use glReadPixels() to read back the data to main memory or another buffer on the GPU (that buffer could use CUDA/GL interop to be shared with CUDA) depending on where you need to process the information. Black pixels are in shadow, white ones are not.

And so far it works.. I get the confirm that the framebuffer is complete

But I need help, I will start by render a simple triangle, just for testing, but.... what about clearing the FBO to white?? And moreover, what about the pixel format when I am going to read them with glReadPixels()?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org