Horde3D

Hello!

As I see, the invisible nodes geometry are still in the video memory.
Can I control somehow this behavior? I have a huge environment
with large amount of geometry, and just a part of this is visible
at any given time.

anchor

You'll probably need to unload the resource.
I think that will be the only way to remove them from the video memory.

I'm not sure how that would affect the scene node, if you attempted to render it that is.
But I'd guess it would be fine as long as you don't try to render the scene node whilst it has no geometry. Otherwise you'd have to remove the scene nodes associated with a removed geometry.

So have you tried unloading the resource?

Thank You for the answer!

Yes, meanwhile i solved the problem with resource unloading,
and reloading from the system memory. The performance is
acceptable And lot of video memory saved.

Here is a small video from our project:
http://www.youtube.com/watch?v=kMEDbXeRlxk

anchor

You're welcome. I wish I answered earlier.
Did you simply call h3dUnloadResource? Or did you remove the scene node when it became invisible? Since nodes might share a resource..
From what you described, I guess you need to unload the resource.

That is a very nice demo. Is that your project or what company do you work for? If you don't mind me asking.

I'm use h3dLoadResource(),h3dAddNodes() if visible, and h3dRemoveNode(),h3dUnloadResource() if invisible the node.
This geometry is not shared, every node is unique. (generated vegetation geometry)

Soon We will announce the mentioned game in horde3d forum (Its not my project)

anchor

If so, why don't you try unloading the resource but not the scene node. Leave the scene node but just set it to not be rendered.

It may also be necessary to remove the geometry from the mesh, if a mesh can have a NULL geometry that is. You'd need to remove the geometry from the Mesh first if that is the case...maybe not actually, because you are not accessing the geometry, simply setting a new geometry (NULL).
Then when the node becomes visible again, you will only need to load the geometry again and attach it to the mesh for the scene node.

Or if the above is not possible, you could set every invisible node's geometry to have only 1 vertex (the same point for all). That would save a lot of geometry space (nearly all of it) ...

This would save time on creating scene nodes, and I think it would save much more time than you would lose by having many invisible scene nodes to traverse.

What do you think?

Maybe I will try it. But Marciano knows the truth, is this possible or not

anchor

I am sure that the 2nd method I mentioned will work.

I will explain more clearly what I mean. You said that the geometry is all unique.
So to save video card memory for invisible nodes, unload the geometry resource for the invisible node and attach a static geometry resource (one that you build when you initialize the application) to the node's mesh.
Use the same static geometry for every invisible node. That way no matter how many nodes are invisible you will actually only need 1 geometry kept in video memory for the invisible nodes, and it will be pre-built so you just attach it. Then when the node becomes visible again, simply load the proper geometry again and attach it to the node again.

That's what I'd do.
Do it. It makes sense. Don't wait for Marciano.

Hi anchor,

setting an invalid geometry resource for a model node is currently not allowed (see ModelNode::setParamI in the horde code). Using some shared dummy resource as vikingcode recommends and setting the Inactive flag for the nodes should work fine.

If your streamable geometry is static (not skinned), instead of loading/unloading resources, another thing you could consider is using a pool of geometry resources for which you update the vertex data. This is a bit more complicated though. Probably you will have to parse the geo file yourself (which is actually quite easy) and second you need to make sure you don't stall the GPU by partly updating a vertex buffer that is still referenced in the command buffer. This would save you from the overhead of allocating/deallocating resources but if you don't have any performance issues with that, I would just keep it simple.

I tried the dummy geometry solution, but the shadow goes crazy, when I
rotate or move the camera. This happens when the node changed from
invisible to visible. (the dummy geometry changed to real one)





The nodes bounding box seems okay.

anchor

What do you mean the shadow goes crazy?

I'd do it in this order.
Set the node invisible, attach the dummy geometry to the mesh, unload the geometry resource.
Load the geometry resource, attach the geometry to the mesh, set the node visible.

I tried the same order, what You proposed.
The shadow disappears randomly, when I
move the camera. (and the node disappears
sometimes too) Its looks like the bounding
box corrupted, and the clipping not working
properly.

anchor

So does this only happen after you have changed the geometry to a dummy geometry and then changed it back to the proper geometry?
Now Marciano could help!

Maybe when scene nodes are modified they need a cycle of the engine to set them up properly. Maybe there are internal methods that set up the bounding boxes etc.. But when they are first created they are setup properly in the initializer so to speak.
Marciano is that wrong? It's just the only guess I can make without more knowledge.

Actually you would have to update the mesh node parameters as well, otherwise they index into a vertex buffer which is too small. But these attributes are read-only at the moment. For a future version I would prefer to have the batch data (index and vertex range) stored in the geometry resource along with the local AABB to avoid all these issues that we have now

Are there any issues with your first solution of just unloading the resource and deactivating the corresponding scene nodes?

Ahhh of course, the geometry is put into a mesh. Does the mesh have its own set of indices?
Internally, why not just attach the geometry to the mesh and reference the geometry from within the mesh when retrieving mesh geometry data? (I'm probably not thinking about many design issues!!)

Marciano, if the Mesh parameters are read-only, does that mean that anchor must also remove the mesh node and then create a new mesh node when the geometry is loaded again?
If so, then he will also need to remove the model node which holds the geometry will he?

Sounds like a good move to make.

Not just deactivating, but removing the scene node is what he did.
He said that works well enough so he should be ok for now.

anchor, what happens if you simply remove the geometry resource and set the node invisible?
Do not remove the Node.
Then when the node becomes visible again, load the geometry resource again.

If that works, that is the most efficient. You should only need to remove the node if geometry resources are shared, then you must remove all nodes that contain that particular geometry.

I don't see why it should not work to simply unload the resource because the engine will not attempt to render the invisible node, hence the engine should not try to access the geometry for invisible nodes.

The only problem is, does the Mesh and Model node need to be recreated, or can they be updated?