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 ?
It works for me, have you set spread count on your instance & transformBuffered nodes? i think its on 1 per default.
in the attached patch, SuperPhysical engine is rendering one instance while GoruaudPoint is rendering all
forum transformbufferd.zip (171.6 KB)
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.
would it make sense to adopt the dynamicbuffers from noodles ?
in my opinion, there lies a lot of visual potential behind merging the two
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.
It’s all open source for everyone to tinker with and implement those features if needed … :)
@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.
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.