SuperPhysical geometry from TransformBuffered

[ggml]

take the Curl (VF3D.Operators) help patch, route it to SuperPhysical via TransformBuffered and it will only show one Box instance in the renderer. Is this expected ? How can the two packs be merged ?

[gegenlicht]

It works for me, have you set spread count on your instance & transformBuffered nodes? i think its on 1 per default.

[ggml]

in the attached patch, SuperPhysical engine is rendering one instance while GoruaudPoint is rendering all

forum transformbufferd.zip (171.6 KB)

[mburk]

you are trying to use the deferred version of super physical? do you really need this? the forward version works very well our of the box.´

Then just use it as a regular geometry.

The only drawback here ist, that it is treated as a single mesh with only one material.
The deferred version of superphysical has a proof of concept implementation of how to implement instancing, but there is no convenient adapter for instance noodles yet.

[ggml]

would it make sense to adopt the dynamicbuffers from noodles ?
in my opinion, there lies a lot of visual potential behind merging the two

[seltzdesign]

agree with @ggml. Being able to use Instance Noodles with the deffered version of Superphysical would be amazing. Write transform buffers, color/material buffers and geometry selection buffers (to select on of several geometries for each instance) early on, ideally in VL. Then have Superphysical setup with all the lighting and so on and point it to the buffers. That would be a great workflow and useful for a lot of the particle/instancing-lots-of-geometry kind of scenarios, which a lot of people are facing. The hard part we often face is the geometry selection part - where you want to give each instance one of say 10 different geometries and one of say 10 different materials. Doing this efficiently is tricky, because it always involves sifting and selecting and so on so all the same geometries are together in chunks, which quickly becomes heavy in vvvv when you get above certain numbers of instances. Anyway, looking forward to any future improvements and compatibility between the 2 worlds.

[readme]

It’s all open source for everyone to tinker with and implement those features if needed … :)

[ggml]

i have sent a funding proposal to @mburk, as many of us here, @readme, are not coders. if someone care to join, maybe we could reach some form of critical mass

[seltzdesign]

@ggml I am sure we would be willing to invest some funds in this as well, as it would help a lot. Like ggml says, we are very experienced in vvvv, getting there in VL, but we don’t do any coding in C# or shader language, so we do unfortunately rely on either the work graciously submitted by someone here or hiring someone (ideally the original creator as they probably have to most knowledge of it) to do the coding. I am willing to help in any other way I can.

Would be great to have some sort of mini-kickstarter/patreon kind of thing where we could support the implementation of new features if enough people support it.

[mburk]

Hey peeps, sorry for late reply. I’m on the road right now and will post a proper answer next week. In short: I think the features you ask for for are pretty straight forward to implement. Let me see what I can do. I’ll have to think about it and maybe create a little roadmap of necessary steps.

[mburk]

Hi.
I tried a quick and dirty approach here:

GitHub - michael-burk/SuperPhysical at Instancing

please give this a test.

there is a new patch in examples and also a new help patch for instanced version.
this is still based on the material workflow, so you need to define materials and then assign them via an ID to the instances.
how to you feel about this workflow?

[seltzdesign]

@mburk Wow, looks awesome. Just played around a bit and 2 things I noticed.

1. My render output is way brighter than in your screenshot:
   

   
   
   This is after first opening in latest alpha.

2. I noticed that in the volumetrics node, the NB_Steps parameters needs to have some min and max value. Accidentally going negative causes a hard crash of the graphics card (ie. screen freezes completely)

Just playing around how to do it with multiple geometries through spreaded instance counts but that doesnt seem to work, all the geometries just get transformed the same. Ideally there would just be a Geometry ID as well as a Material ID.

edit: I see there are examples with multiple geometries in the help file. Will work from those ;)

[seltzdesign]

@mburk found another weird issue: If I provide just one material but then set the material ID to 1 all objects are red. If I set it to 2 all objects are flickering black/white at above 2 everything has a black material. So I assume there is no clever wrapping of indexes like in vvvv in the shader!? Still strange that that’s what’s happening with out of bounds material IDs.

[mburk]

thanks for the feedback…will check.

[seltzdesign]

@mburk Found out why my colours looked so off. I had renamed the packs folder and it wouldn’t find the LUT file. Once I set the custom path to it, it looked fine.

[ggml]

@mburk thank you also for addressing the this
is the deffered verision to be expected to be faster than forward+depthonly ?

[mburk]

Deferred is only faster in certain situations. I wouldn’t recommend using it at this point, unless you have a special use case. E.g. custom gBuffer generated by Field Trip. If you need many lights check out the FWP example.