Hello Ventuzians!
THE FORUMS ARE CLOSED!
Please join our discord server HERE!! << click me
We are shutting our Ventuz Forum, but don't worry, it will all be archived for you to search in if you have a query. From now on, please add all your comments, questions or observations into our Discord Server
Thanks for the great time - see you on discord!!
Dee, Karol, Daniel and the whoooole Product and Support team!
THE FORUMS ARE CLOSED!
Please join our discord server HERE!! << click me
We are shutting our Ventuz Forum, but don't worry, it will all be archived for you to search in if you have a query. From now on, please add all your comments, questions or observations into our Discord Server
Thanks for the great time - see you on discord!!
Dee, Karol, Daniel and the whoooole Product and Support team!
D3D Performance
Moderator: Support
D3D Performance
Hi,
there seems to be an issue with how Vertex/Index Buffers are handled, when there are custom shader nodes in the scene.
In large scenes with lots of meshes( > 500 or so, I'm just guessing though, might be alot more),
everytime a node in the hierarchy is changed (added, moved, deleted) Ventuz freezes for a significant amount of time.
The more meshes the longer it freezes.
I have traced the DirectX calls and noticed that in all frames a node is modified, it reuploads what looks like every mesh in the scene.
This causes at least 4 times as many api calls and about 800mb of transferred data in our scene.
Going by the 800mb, maybe there are also textures involved, but I don't really want to dig through 200000 calls to find out.
Going by some simpler test scenes this seems to only happen when there are shader nodes in the scene, but I have not tested enough to be sure.
Michael
there seems to be an issue with how Vertex/Index Buffers are handled, when there are custom shader nodes in the scene.
In large scenes with lots of meshes( > 500 or so, I'm just guessing though, might be alot more),
everytime a node in the hierarchy is changed (added, moved, deleted) Ventuz freezes for a significant amount of time.
The more meshes the longer it freezes.
I have traced the DirectX calls and noticed that in all frames a node is modified, it reuploads what looks like every mesh in the scene.
This causes at least 4 times as many api calls and about 800mb of transferred data in our scene.
Going by the 800mb, maybe there are also textures involved, but I don't really want to dig through 200000 calls to find out.
Going by some simpler test scenes this seems to only happen when there are shader nodes in the scene, but I have not tested enough to be sure.
Michael
-
- Posts: 666
- Joined: 18 Jan 2012, 20:56
- Location: wuppertal
- Contact:
Re: D3D Performance
so we talk about working in the designer?
if you change nodes (not properties) in the scene, of course the scene will freeze....and of course the time depends on the complexity of the scene. this is not a bug and not a feature....just normal
have you tried to disable undo? the will save a lot of time in bigger scenes!!
greetz
christian
if you change nodes (not properties) in the scene, of course the scene will freeze....and of course the time depends on the complexity of the scene. this is not a bug and not a feature....just normal
have you tried to disable undo? the will save a lot of time in bigger scenes!!
greetz
christian
Re: D3D Performance
Yes this is about Designer.
Of course the scene will freeze on larger projects for a short amount of time, but we are talking about 2+ seconds here for every hierarchy change.
But deleting all shader nodes from the scene, the freezes go back to their normal level what you would expect from a large scene. (a couple of milliseconds)
A little illustration: That highlighted frame is when i drop a new axis node into the scene.
We suddenly have 50k extra api calls with 8.5e+02 MB (850 MB) of transferred data.
All of these extra calls consist of something similar to this Now I am not particular familiar with DirectX (I use OpenGL mostly), but that looks very much like uploading a mesh.
Obviously when this happens a couple of thousand times in a single frame Ventuz will freeze for a significant amount of time.
But I don't see a reason why this has to happen when I create, move or even delete a node from the hierarchy, every single time.
It's not like creating a color node would suddenly invalidate all mesh buffers at once, or even a single one.
As mentioned above this only happens when there are custom shader nodes in the scene. I have not tried it with the builtin ones though.
So there clearly seems to be an issue with buffers getting invalidated, when they shouldn't.
Greetings
Michael
Of course the scene will freeze on larger projects for a short amount of time, but we are talking about 2+ seconds here for every hierarchy change.
But deleting all shader nodes from the scene, the freezes go back to their normal level what you would expect from a large scene. (a couple of milliseconds)
A little illustration: That highlighted frame is when i drop a new axis node into the scene.
We suddenly have 50k extra api calls with 8.5e+02 MB (850 MB) of transferred data.
All of these extra calls consist of something similar to this Now I am not particular familiar with DirectX (I use OpenGL mostly), but that looks very much like uploading a mesh.
Obviously when this happens a couple of thousand times in a single frame Ventuz will freeze for a significant amount of time.
But I don't see a reason why this has to happen when I create, move or even delete a node from the hierarchy, every single time.
It's not like creating a color node would suddenly invalidate all mesh buffers at once, or even a single one.
As mentioned above this only happens when there are custom shader nodes in the scene. I have not tried it with the builtin ones though.
So there clearly seems to be an issue with buffers getting invalidated, when they shouldn't.
Greetings
Michael
Re: D3D Performance
I forgot to add that but it doesn't let me edit my post anymore?
Undo is indeed turned off.
Undo is indeed turned off.
Re: D3D Performance
Hi Michael,
I you modify the Hierarchy Tree by adding/deleting nodes, the new tree is completely re-validated in the first frame.
Normally only those parts of the tree are re-validated which have been invalidated before (I guess an average value would be 10-15% of the whole tree).
So a rendering stall is normal. But 2 seconds are pretty long! How many nodes do you have in your scene?
Best Regards
Karol
I you modify the Hierarchy Tree by adding/deleting nodes, the new tree is completely re-validated in the first frame.
Normally only those parts of the tree are re-validated which have been invalidated before (I guess an average value would be 10-15% of the whole tree).
So a rendering stall is normal. But 2 seconds are pretty long! How many nodes do you have in your scene?
Best Regards
Karol
Re: D3D Performance
Hi Karol ,
The number of nodes I don't really know, only thing I can say is that there are a lot. It really is a big scene.
Would it really invalidate parts of the tree if I drop a node at the top level, with no other nodes following it?
So that node does not affect any part of the tree, but still shows the same freezes.
I don't have any time to investigate this further this week.
The only thing I can still add is what I mentioned before. Removing shader nodes from the scene seems to bring the freezes back to a normal level, in regards to scene size.
Michael
The number of nodes I don't really know, only thing I can say is that there are a lot. It really is a big scene.
Would it really invalidate parts of the tree if I drop a node at the top level, with no other nodes following it?
So that node does not affect any part of the tree, but still shows the same freezes.
I don't have any time to investigate this further this week.
The only thing I can still add is what I mentioned before. Removing shader nodes from the scene seems to bring the freezes back to a normal level, in regards to scene size.
Michael
Re: D3D Performance
To find out how many nodes you have in your scene go to 'Tools -> Scene Statistics' !
Re: D3D Performance
Well, I'm back.
Sadly I have not had any success to nail down the problem or effectively reproduce it in a simpler scene.
It is very inconsistent.
Here is a screenshot of the scene statistics if that is of any help Anyway, I am going to put this on halt for now since I'm out of ideas.
And I guess I can't convince anyone with access to the actual source code to do some profiling on complex scenes without a concrete issue.
Greetings
Michael
Sadly I have not had any success to nail down the problem or effectively reproduce it in a simpler scene.
It is very inconsistent.
Here is a screenshot of the scene statistics if that is of any help Anyway, I am going to put this on halt for now since I'm out of ideas.
And I guess I can't convince anyone with access to the actual source code to do some profiling on complex scenes without a concrete issue.
Greetings
Michael
Re: D3D Performance
Hi Michael!
Your scene is pretty huge! 23k nodes with 15k of them being Hierarchy nodes is actually the problem why you have stalls if you change the hierarchy tree.
If you add or delete a hierarchy nodes, the complete tree is recalculated and re-validated - this takes time.
The only way to reduce these stalls would be to modularize your scene and use ScenePorts. Scenes inside ScenePorts are not re-validated if the parent scene tree changes.
If you want to take me a look inside your scene, please write me a PM.
Best Regards
Karol
Your scene is pretty huge! 23k nodes with 15k of them being Hierarchy nodes is actually the problem why you have stalls if you change the hierarchy tree.
If you add or delete a hierarchy nodes, the complete tree is recalculated and re-validated - this takes time.
The only way to reduce these stalls would be to modularize your scene and use ScenePorts. Scenes inside ScenePorts are not re-validated if the parent scene tree changes.
If you want to take me a look inside your scene, please write me a PM.
Best Regards
Karol
Re: D3D Performance
Hi,
We now have a different project with a much smaller scene.
It still has the same issue I reported a while ago, that it freezes for almost two seconds when moving a hierarchy node.
So the hierarchy size definately cannot be the problem.
The total polygon amount is about 1.1 million, which still seems to get copied to graphics memory everytime a node is modified.
Now please don't think 1.1 million polys is to much for Ventuz to handle. Performace is just fine at about 13-14ms, totally reasonable for a modern graphics card.
Also the same fix still applies, deleting all shader nodes from the scene and all the freezes disappear.
I might be able to send you the scene for inspection if neccessary.
It would be nice if someone could seriously look into this since it is very annoying.
Regards,
Michael
We now have a different project with a much smaller scene.
It still has the same issue I reported a while ago, that it freezes for almost two seconds when moving a hierarchy node.
So the hierarchy size definately cannot be the problem.
The total polygon amount is about 1.1 million, which still seems to get copied to graphics memory everytime a node is modified.
Now please don't think 1.1 million polys is to much for Ventuz to handle. Performace is just fine at about 13-14ms, totally reasonable for a modern graphics card.
Also the same fix still applies, deleting all shader nodes from the scene and all the freezes disappear.
I might be able to send you the scene for inspection if neccessary.
It would be nice if someone could seriously look into this since it is very annoying.
Regards,
Michael