Hi everyone,
I’ve implemented a cloth simulation using particles and now I want to draw the cloth ( a grid n x n) using a triangle strip and calculate the vertex normals. I really need an efficient algorithm since calculations are already pretty expensive.
Someone have an idea?
(Code is really appreciate…)
Thanks a lot
Bye
Haven’t got code to hand to generate the normal but one tip springs to mind - don’t use triangle strips, they’re gone the way of the dodo. Instead just sort your triangles by some arbitrary vertex index number - say, the first vertex in each triangle - and draw them using GL_TRIANGLES. You’ll find it’s exactly the same speed as GL_TRIANGLE_STRIP when using glDrawElements.
Cas 
For a vertex normal you typically compute a weighted average of the face normals surrounding the vertex. A face normal can be calculated by taking the cross product of the two edge vectors. An approach without using a vector library can be found here: http://gmc.yoyogames.com/index.php?showtopic=374068
With google I found a paper called “Fast Accurate Normal Calculation for Heightfield Lighting on a Non-Isometric Grid”, but it wasn’t publically availabe anywhere. But if you are willing to pay the 19$, it might be useful for you.
@princec
Is this true? I always thought that at least the space saving gives some benefits, so I am using triangle strips in my terrain implementation…
With DrawElements you still only have to store the unique vertices, and the index array will reference the shared vertices how ever many times necessary. To keep performance similar to triangle strips you will want to make sure you draw all triangles with shared vertices close enough together that the shared vertices will still be in the cache.
Yep; I find that sorting the triangles based on the index number of one of the vertices more or less ensures you get a reasonably good cache hit rate. Sorting by patches first would probably be even better (say, 5x5).
Cas
i recently read somewhere that all mainstream GPUs are designed to use indexed geometry. The driver is responsible to create indices if there are no application provided indices available just to be able to pass the geometry to the GPU.
i would say the currently fastest way to render connected geometry is:
1*. geometry in compiled DLs (it shouldn’t make a difference if organised in triangle strips or independent, indexed or not)
2. indexed VBOs (i guess interleaving is only relevant if you have to small VBOs to be performant)
whether you can see a difference or not will depend where the bottleneck is (as always). In java land its almost always the CPU 
[1] even if a bit outdated and deprecated, DLs are still the best way to get optimal cache aligned geometry for the given gpu and cache size
Actually I use indexed triangle strips
lol
In my experience indexed interleaved VBOs are best, not only for small data sizes.
(I don’t use displaylists as my geometry is dynamic, and compiling displaylists takes way too long).
How comparable are vertex arrays vs. vbos that need to be updated each frame? I’ve always assumed that changing a vbo was close to as bad as with a display list, but I haven’t done any benchmarks.
Well, they are dynamic, but they don’t change every frame. Otherwise, they have the same performance as VAs.
VBOs perform best when there are between 5 and 10mb large (from my appearance on nvidia hardware). With interleaving you can artificially increase VBO size since you are merging multiple specialized VBOs into one. Thats why I said there are esp. good for small data sets. I should have explained it a bit better
I use VBOs too since there are the most flexible format. I am also looking forward to the GL3 features like async updates etc. But test it yourself put your entire scenegraph shapshot into a DL and render it. If you where GPU limited before you should see at least 20% performance increase.
There is a recent discussion to resurrect DLs and enable multi-threaded DL creation triggered by the Siggraph papers (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=252362&fpart=3). I would already be happy if it would be possible to compile them asynchronously (then we could use them like VBOs) but currently they block the whole pipeline it doesn’t matter in which gl context they are 