Hi!
I’ve been wrangling with the Geo Comp for some time with a view to optimising frame rate for instancing of relatively complex geometries and can’t for the life of me work out how it’s actually handling instancing. I can summarise with a couple of questions, but any general advice would also be welcome. See screenshot below. I’m using a fairly old graphics card (NVIDIA Quadro M5000) so am not expecting miracles. In this example I’m instancing based on 400 pixels (yes, I know it’s a lot of instances lot for a complex model but my understanding of instancing is that there should be only small performance hit for instancing, I could be wrong here). Turning off the geo viewport raises framerate to max, meaning the noise TOP isn’t the source of the slowdown.
-
When attempting to reduce the actual number of instances that the system is handling by using the ‘active’ parameter in the ‘translate’ section of the first instancing tab, there is zero performance benefit when all instances are set to zero by setting the alpha output of the noise top to ‘zero’ - the models do disappear and I see a blank geo. It seems as if the GPU is doing all the calculation for instances which aren’t being rendered. What am I missing, and what is this parameter actually doing? This would be a useful way, in my networks, of reducing instance count.
-
Changing the render resolution from 1280 x 720 to 10 x 10 pixels has no effect (when a render top is actually included and all viewports are turned off, which it isn’t in my example above), suggesting this isn’t an issue with rendering complexity. Neither does perform mode.
-
I’ve optimised the geometry as best I can without losing too much detail. Is there a conversion I can do on the actual geometry itself to make it more efficient to render, and is there likely to be some overhead with converting it? Once it’s in the GEO, I’d have thought that it’s in the GPU with no further conversion necessary and the instance count wouldn’t make any difference. It’s currently imported as a tog file, and is only referenced once so any downstream optimisations prior to instancing would only have to cook once.
Thanks in advance from this newbie.
Hi there!
I’m a little bit afraid the performance issues are mainly caused by the age of your video card. I’m not familiar with the Quadro M5000, but google tells me it’s about half the performance of a 1080. Instancing as you say is indeed quite efficient since it only needs to keep track on references to an object instead of every detail of it. However when rendering you are still rendering 215254*400 = 86million vertices. If you have them all in the viewport (like in your example, or when rendering and having a camera aimed at it), it will definitely be heavy for the gpu.
Also I noticed when having vertices exactly on the same place (exactly same x,y,z coordinates), it becomes super heavy as well. What happens if you increase the noise amplitude and so the objects will move away from each other? Does that help the framerate a bit?
About your questions, the ‘active’ parameter is not decreasing the amount of instances, it’s just flags an instance if it needs to be rendered. I’m not entirely sure where in the process it gets discarded, but it definitely doesnt affect the instances count. So it’s not really a way to optimize things easy I’m afraid. Might help the renderer a bit, but like I said, not entirely sure.
Changing the render resolution didn’t help much since of the same amount of vertices visible by the camera being rendered. Optimizing the geometry is indeed the best way to gain performance, but best to do so in external modelling software. There is not really an easy way to automatically remove vertices and still make it look good. Keeping the vertex count as low as possible, and perhaps creating the fine details with texture maps instead of geometry.
Last thing about toggling the viewer on and off of the viewport. When you didn’t connect it to any renderer, turning the viewport off will stop everything from cooking and so will max your framerate.
Oh really last thing, also check the gpu memory usage. If you exceed the amount you have, things suddenly go super slow. However if the screenshot
is all you have in the network, I guess you’re not exceeding it 
Hope this helps! 
Cheers,
Tim
2 Likes
Not 100% answering your questions, but this is worth the watch: When Optimisations Work, But for the Wrong Reasons - YouTube
2 Likes
Hi Tim, and thanks for your really useful and considered reply - you’ve given me some things to consider. In answer to a couple of your questions:
The frame rate does not improve when most of the objects are off-screen. My current application is an infinite procedurally generated landscape where the camera is placed in the centre of a grid, and allowed to rotate freely, with instances destroyed and created as necessary at the visual extents of the grid as the camera moves around the world space - presumably a very common task. The calculation steps to acheive this are very simple indeed and don’t impact system resources at all. Most of the instances are therefore out of the FoV, often behind the camera as it rotates (if I could figure a way of filtering the instancing co-ordinates within the CHOPs to remove those that are not within the camera field of view then I’d probably achieve a much better level of optimisation, removing just under 5/6th of the instances for a 60 degree field of view - I just figured the geometry and rendering mechanisms would do that for me).
I presume there is a technical reason why the inactive instances are still calculated on the GPU - it made sense to me that they’d be removed at the earliest stage.
I do need to upgrade my GFX card, but it feels like there is still scope to optimise before I have to splash more cash.
Thanks Gauthier for the link - this was actually a really useful watch and taught me a lot in a short space of time - the main thing being how little I actually know about what is going on in the GPU.
