Question concerning JOGL VertexArray implementation

[STRESS]

I stumpled across the tutorial for using VertexArrays. I noticed this could be a better solution to my problem I am experiencing currently with the default display list JOGL implementation. Also the performance is far better probably. Still not as good as it might be with VBOs but definitely a major step forward.

But I've got a couple of question concerning that:

Do I only need to create a GlslPolygonShader to activate VertexArrays (according to the tutorial that seems to be the only step necessary)

Will the functionality like shading & lighting, colouring for line, faces and points stay the same?

How reliable / safe is it to use at the moment?

[gunn]

This is a brand-new tutorial which I cooked up because I wanted to find out be able to compare vertex arrays and display lists.

You can read the results in the latest version of the tutorial here. As it mentions there, at least for the hardware I'm using and the situation of geometry that only changes sporadically, display lists are significantly faster.

[STRESS]

This is a brand-new tutorial which I cooked up because I wanted to find out be able to compare vertex arrays and display lists.

You can read the results in the latest version of the tutorial here. As it mentions there, at least for the hardware I'm using and the situation of geometry that only changes sporadically, display lists are significantly faster.

Hmm strange I'll get the opposite effect. Vertex Array is a lot faster maybe your geometry is too small. Or it gets stored in the wrong memory area. That's the problem with VertexArrays compared to VBO I think you can't control where it should be stored.
But so far it looks to be far more stable as well. I can create bigger geometries where display list just do not display anything at all for me.

What hardware / OS /driver are you running on?

[gunn]

My setup: A new quad-core Intel machine with 4 Gbytes and an NVidia Quadro FX 5600 with 1500Mbyte memory.

I'm not familiar with using FBO's to render geometry, just for rendering images. Can you provide a reference to where I might read about that?

[STRESS]

My setup: A new quad-core Intel machine with 4 Gbytes and an NVidia Quadro FX 5600 with 1500Mbyte memory.

I'm not familiar with using FBO's to render geometry, just for rendering images. Can you provide a reference to where I might read about that?

Hmm quite a beefy setup.

I am only using a NVidia Quadro MVS160 at the moment. Dual Core Dell Notebook runing Windows XP SP3.

About Vertex Buffer Objects (VBO) I think a good start would be the NVidia document about it

http://developer.nvidia.com/attach/6427

They are basically similar to Direct3D9's Vertex Buffer resource concept which I personaly found way superior to anything OpenGL had to offer for a very long long time.

The problem with them is to find the optimal size to get maximum cache performance. Large geometry you might have to split up into several indexed buffers.

Btw I noticed with your experimental Vertex Array there might be some sort of memory leak since it uses up a lot of memory and I run out of Java VM memory shortly after awhile

[STRESS]

Btw I noticed with your experimental Vertex Array there might be some sort of memory leak since it uses up a lot of memory and I run out of Java VM memory shortly after awhile

Hmm I think I have a feeling what could be the cause of that. The GLSLPolygonShader has a hashmap of all the buffers it created for an IndexedFaceSet which I understand why because it doesn't want to generate the VertexArray each frame. So far so good.

But if you keep on creating new Geometry with different IndexedFaceSets on the same SceneNode it will fill up the hashmap on and on and on and there is nothing which seems to flush it. This means it will run out of memory at some stage because the garbage collector will not see the memory as being unreachable.

This is probably a design flaw. In my opinion it shouldn't store a reference of the IndexedFaceSet as HashEntry but rather to the SceneGraphNode and check if it's geometry has changed or not.

[gunn]

Thanks for the information.

The GlslPolygonShader is somewhat experimental code contributed by another team member, so I'm not sure how and when the shortcomings you've discovered will be repaired.

In the meantime you may be able to avoid this problem by re-using the IndexedFaceSet you're working with rather than creating a new one. I don't know if that is practical, but if so, the simplest way would be to use a single IndexedFaceSetFactory; it keeps the same instance of IndexedFaceSet over the course of its lifetime. You wouldn't even need to call sgc.setGeometry() more than once. Just remember to call update() after making changes.

There is by the way a first version of JavaDoc for these factories here; also check the JavaDoc for its superclasses.

[STRESS]

Thanks for the information.

No problem one major advantage I forgot to mention with VBOs you do not have to keep the client buffer lying around after you successfully created it you just need a handle to it for drawing, which is a major advantage especially with Java since it does not need to keep it in its heap space that in my experience is always few to spare, especially if you work with graphics.

In the meantime you may be able to avoid this problem by re-using the IndexedFaceSet you're working with rather than creating a new one. I don't know if that is practical, but if so, the simplest way would be to use a single IndexedFaceSetFactory; it keeps the same instance of

Thanks for the tip I've come to the same conclusion and I am nearly there :) I still have some bizarre memory issues when the IndexedFaceSet grows bigger after its first initial creation.

[steffen]

I assume it's my code... Sounds like a WeakHashMap could help, right? Using the component as a key will not -- as soon as people start to replace the component we have the same problem again. Btw. the same geometry may be referenced from different components, and we don't want to have duplicate vertex arrays...

Maybe we need the same hashing mechanism as for textures, since there might be different instances of GL, or do these share the vertex arrays?

[STRESS]

I assume it's my code... Sounds like a WeakHashMap could help, right? Using the component as a key will not -- as soon as

Not sure if it's your code. But it is already using WeakHashMap so that obviously doesn't seem to help.

people start to replace the component we have the same problem again. Btw. the same geometry may be referenced from different components,
and we don't want to have duplicate vertex arrays...

That is true. With component you probably just decrease the frequency of it happening. But someone has to clear the WeakHashMap. The only way I can see that is to have some sort of listener that gets notified when geometry is added and removed and then deletes the Map entry correspondingly. Or hHaving some sweeper/GC thread going around after awhile but I am not sure how that would be able to detect if something is still in use or not.

I have no idea how difficult this will be but I can imagine that will require some larger changes since currently shaders don't need to do that.

Alternatively you could attach the GL structures to the geometry nodes themself and let them keep track on their liveness that's what most scenegraph APIs do but that obviously doesn't fit very well in your having different backends philosophy so it would requires probably even more changes.

Maybe we need the same hashing mechanism as for textures, since there might be different instances of GL, or do these share the vertex arrays?

Not sure if I understand what you are asking here?

[gunn]

The JOGL backend creates its own "proxy" version of the scene graph so it can cache things and keep track of just the sort of resource issues as here. But the problem here is that it's happening in a shader, and shaders are only loosely tied to the scene graph structure, in the sense that they are "black boxes" which the JOGL backend invokes without knowing exactly what or how the shader operates. Hence the possibility of having different shaders. But then the question is how these different shaders can keep track of resources.

One possible solution: The shaders DO know about the JOGL backend, so it may be possible for the shaders to have access to the hash map which the JOGL backend keeps for the Geometry instances it encounters. I'll look into this.

[steffen]

Hi, just checked the code, it uses WeakHashMaps for the ByteBuffer-caching, but it also uses a HashMap (upToDateIFS, Line 575). Please try to replace HashMap by WeakHashMap in that line, I assume that will fix the leak.

However, using VertexArrays (or even VBOs) should be better supported (and maybe become standard at least for large geometries). I will look into that the next weeks...