Instancing Spread of different geometries

Hello,

I’m trying to use instancing but this time with different geometries, different transforms and (later) different textures.

Using noodles contrib, I can’t find how to achieve this, probably because IID order is wrong in the end. I made a simple patch with Merge geometry.

Any ideas ?

thanks

ConstantBuffered.v4p (16.1 KB)

Yo,
I think your problem is that the merge node depends on having some instance info input in the first place. Here’s a quick mod of the help patch, should be what you want? Also make sure to change the technique on constant-buffered to read the texture array too.MergeTexArray.v4p (33.3 KB)

Thanks I did try the help patch provided with the Merge node but the problem I found with this is I must use one IID module for each different geometries. Problem is IID node is very CPU intensive, I guess because of pipeline statistic node, also in my case I don’t know how many different geometries I want to instance, so I don’t know at first how many IID node I would need.

I know that instancing is useful to copy one type of geometry. Maybe in my case, instancing is not the best solution. In my example patch I use 3 differents type of geometry with differents transforms (and different binsize for each), but instead of 3 it could be 5 or 6.

Something like this :
ConstantBuffered.v4p (20.4 KB)
But I have to spread geometry before binding to merge shader so that’s totally not efficient…

You can build your own IID Buffers pretty easily.

The only tricky thing is to know the vertex count of each model. This is what the IID node does for you (and also why it had the ugly pipeline statistics inside).

As for using instancing in the first place, there’s as far as I know no performance benefit, and indeed extra overhead when using small spread sizes like this. That might be counterbalanced by making some things more convenient in your pipeline downstream.

I guess you’re probably trying to add some things to a mixing system or some such? That makes a harder design challenge then a fixed project for sure.

Also just for reference here’s your patch with the IIDs. If that’s really the source of overhead issues for you you might also
consider a S+H approach (there’s buffered versions in noodles too), so you are just building those as oneshots

ConstantBuffered.v4p (30.5 KB)

1 Like

I am trying to do something similar, but using several IID nodes is not practical, as there any number of source meshes, but 1 mesh for each transform.

You mention that you can build your own IID Buffers, if you know the vertex count. Since I am loading the meshes from an .obj file I know the vertex and indices counts for each mesh.

I am attaching a file which is based on the Geometry Export example, since that is actually what I would want to use it for.

How can I end up with just the geometry buffer of several transformed geometries. The final thing has usually around 100-1000 instances, so I guess would benefit from this. Plus the geometry export is interesting.

Thanks for any help.

What it looks like at the moment with superphysical with one of the geometry sets:

instance_multi_geom_noodles.zip (183.9 KB)

Well, not really. I would say purely performance wise to just make more drawcalls. Plus in your case where we use merge repeatedly it’s kind of worst of both worlds (as in the overhead of multiple draw calls + the overhead of setting up instancing to then do the same stuff as one). But if you want to do it like that in order to use it for export or on gsfx nodes etc here’s how I’d do it: instance_multi_geom_noodles_FIXED.v4p (30.7 KB)

Thanks @everyoneishappy, I will take a look at your fixed patch.

Right now I primarily am interested in the Object Export functionality. As I am using different colors for each instance, I wouldnt be able to use Transform Buffered anyways, since as far as I can tell Superphysical doesnt support a color buffer. Also the performance is not great but sufficient and instancing is actually not the bottleneck. It starts getting slower after around 1000 objects, but I think thats more due to the gigantuan patch which has to deal with all sorts of things like midi controllers, midi note input, a really elaborate GUI and all the bells and whistles like DoF, AO and lots of Anti Aliasing.

So I will stick without the instancing for rendering for now.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.