next »

[Mathias 'cylab' Henze]

Is there a possibility to reuse one set of vertices cached on the hardware with multiple IndexedTriangle instances, or could this easily be implemented?

For my terrain implementation I only want to store the vertices of my highest LOD patch and render lower resulution patches by only passing different indices. On the other hand I don't know, if this is waste of memory and given the less frequent LOD changes, it might be more effective to resend the lower resolution geometry on a LOD change.

What do you think?

[Patheros]

Out of curiosity how are you going to specify the lower LOD models? What file formate are you going to use?

[Marvin Fröhlich]

Is there a possibility to reuse one set of vertices cached on the hardware with multiple IndexedTriangle instances, or could this easily be implemented?

For my terrain implementation I only want to store the vertices of my highest LOD patch and render lower resulution patches by only passing different indices. On the other hand I don't know, if this is waste of memory and given the less frequent LOD changes, it might be more effective to resend the lower resolution geometry on a LOD change.

What do you think?

Do you have any idea, how much memory this would consume on the VRAM? If it is say below 10 MB, then it is worth it.

I haven't found any information, how a VBO can be modified after it has been created. Do you have any doc about it? It shouldn't be too hard to implement. VBOs would be the technique to do that. You cannot use DisplayLists then.

Marvin

[Mathias 'cylab' Henze]

Out of curiosity how are you going to specify the lower LOD models? What file formate are you going to use?

The lower level geometry will be an IndexedTriangleArray that shares the vertices, normals and texture coordinates with it's most detailed counterpart, but has a different int[] as indicies pointing to the vertices to be used for triangle construction.

[Mathias 'cylab' Henze]

Do you have any idea, how much memory this would consume on the VRAM? If it is say below 10 MB, then it is worth it.

This directly depends on the patch-size and the amount of patches uploaded to VRAM at a given time. If you have a 257x257 toplevel patch (low resolution, covering the complete terrain) and replace the area around the player with four more detailed patches each of 129x129 and have a vertice to also contain a normal and a texture coordinate, you will end up with (257*257+129*129*4)*(3+3+2)*4bytes= 4MB. This is however _without_ mesh optimization. You will get much higher resolutions with a proper simplified mesh. The patches around the player have to be replaced with the next patch in range, when the player moves, so that only 4 high detail VBOs are stored in VRAM at any given time.

I haven't found any information, how a VBO can be modified after it has been created. Do you have any doc about it?

No, only the OpenGL extension registry entry: http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt and the JOGL forum

It shouldn't be too hard to implement. VBOs would be the technique to do that. You cannot use DisplayLists then.

Yeah, VBOs or possible VertexArrays to store the data in VRAM (are VAs stored in VRAM ?). One thing I don't know is how to expose this in the Xith-API. An elegant solution could be to hide this completely and just check the pointer equality of the array passed to setCoordinates, but this could be a bit too much of black magic Furthermore this could possible interfere with the vertexIndex argument of that method...

Don't know about the DisplayList optimization, since it might be possible to store the glDrawElements(indicies) call in a displaylist and also have the index-array stored on the  GFX card this way, but that might be wishful thinking

[Marvin Fröhlich]

Yeah, VBOs or possible VertexArrays to store the data in VRAM (are VAs stored in VRAM ?). One thing I don't know is how to expose this in the Xith-API. An elegant solution could be to hide this completely and just check the pointer equality of the array passed to setCoordinates, but this could be a bit too much of black magic Furthermore this could possible interfere with the vertexIndex argument of that method...

VBOs use VertexArrays to send the data to the VRAM. VAs are only stored in the VRAM if encapsulated by a DisplayList or VBO.

The index data is never stored in a VBO. So there's no problem changing them at runtime. No black magic needed.

Marvin

[Mathias 'cylab' Henze]

The index data is never stored in a VBO. So there's no problem changing them at runtime. No black magic needed.

I was refering to something different with my black magic statement, but it's too late to further elaborate today
I know, that indicies are not stored in VBOs, but could they be stored in display lists?

[Marvin Fröhlich]

The index data is never stored in a VBO. So there's no problem changing them at runtime. No black magic needed.

I was refering to something different with my black magic statement, but it's too late to further elaborate today
I know, that indicies are not stored in VBOs, but could they be stored in display lists?

Yes. They are stored in DLs. But the problem is, that the whole geometry is stored in one DL (vertices, normals, color-data, and texture-coordinates). Well, there's an idea coming to my mind. I will check, if that's true. DLs are corrently sometimes very slow. Maybe this is because the data is not actually stored in a DL... I will check that.

Another solution to ease your live would be to create LODShape with a callback method to react on LOD change. It would work very similar to the LODSwitch, but would not switch whole Nodes, but would only invoke the callback method on LOD change. In this method you could switch the index data. Since, that's easy to implement, I will do that independently of your decision. It could be of other use, too.

Marvin

[Marvin Fröhlich]

I've just committed the new LODShape3D class. It is an abstract Shape3D extension with an abstract event method to handle the LOD changes.

You can make use of it to change the index data for your IndexedTriangleArray.

Marvin

[Mathias 'cylab' Henze]

Thanks, that's a much better solution than using multiple IndexedTriangleArray instances. Good work!