Could be a new big jump for the instancing in geo via top, introduce an easy way to pass texture3d as instanced texture.
So after reading one slice it moves onto the next one? Seems very reasonable. I’ll add it to my todos!
yes the idea is could create 1 frame per slice on 3d displacement commonly i did this via glsl, but this could give an interesting speed-up to the process and nice effects mixing with the time-machine TOP:)
This will be functional in builds 2020.42850 and later. Both 3D Textures and 2D Texture Arrays will work. Thanks for the suggestion!
Was just thinking about this today… so glad to see it’s in the experimental branch. I love it when it feels like you’ve read my mind
Hi Malcolm i was trying to play a bit with texture3d introduced in the last experimental.
I believe that there’s a miss on this implementation… there’s no parameter to offset the texture slice on the depth. (as in compute shader using the texture3d)
…or maybe i missed something.
Well that would be a general feature to crop the instance data. That’s no different than wanting to ignore the first 100 samples of a CHOP or the first 200 pixels of a 2D texture. Good idea for sure but not specific to the texture3d cases.
@malcolm - I love this, and I find that I’m doing more and more in texture for instances / voxels. Here’s my crazy idea for you to think about
A new family - Voxel Operators.
These would always be 32 bit, use texel operations, and could help solve some of these challenges of working in texture to do computational operations for geometry, volumes, and instances.
Bonus if they could internally handle pixel packing - it’s a bit of a pain to be working in 4 channels and moving elements around. Those ops might also have some of the other CHOP style operators - a filter, lag, object, transform, math, function - most of those are showing up in TOPs, but having a dedicated family for dealing with voxels would help create some better distinctions between texture as image / uv and texture as datatype for computation. It feels like the point file in TOPs are also in this family, as is the ouster and other ops that work in texture as data.
I’m curious what @paketa12 , @elburz, and @lucesintetica think about this. A new family of Ops isn’t nothing, but having a better method for working with volumes is something that it seems like it would be helpful for all of us these days. Thanks for at least entertaining my goofy idea here.
Hmm I haven’t tried that specific new feature yet but I can definitely speak on operator families. A trend I’m seeing is that everyone wants everything GPU accelerated, which is great except at the moment TOPs are the only family running on the GPU. As @raganmd mentioned, this led to point file pipeline and similar that are essentially purely data operations but they’re in the “texture operator” family. I can only see this fundamental leading to most new operators (that have any sense of scale) needing to be in TOPs. Over time this will lead to a super diluted family of operators that will end up a giant list of operators that do everything except basic state machine functionality and some simple hardware i/o. I have somewhat similar feelings about audio being in CHOPs and had a previous RFE to move all audio operators to their own family (AOPs).
So with that spiel aside, I agree that although new family of operators is a large task, it might be best to tackle this early before it becomes a GIANT issue later. Voxels seem logical, a “3d” GPU accelerated version of SOPs would be cool, etc.
Yep we’re on the same page. With Vulkan and the ability to use Compute shaders on macOS finally we’re way more free with what we can create. Greg has been talking about a new family of GPU operators that are GPU accelerated data in general. I’ve also echoed the concerns about the new Point* TOPs not quite fitting into TOPs, but they are a good stop-gap for now.
my personal idea to use the texture 3d in top is just because i was started to understand how to create a sculpting system in touchdesigner… so i’ve started to see some vincent houze material for compute shader but this impose to work as a raymarcher and is not confortable for non skilled users…(plus others problems connected with growing data structures, storage of data, etc…) so… i tried using the instance TOP and i’ve discovered the uncompatible use of tex3d.
Talking about the “VOPs” For sure implement an apporoach with dedicated operators could be super cool! I’m wating the Vulkan version and i hope the support of rtx and eventually use the tensore core to have some “a.i.” nodes … i believe that the future run on a.i. systems for several reasons… and at moment the only road is by pass using python and scripting in top to take some external process for a.i.
This an extended personal point of view, i know that there’s too much to cook here… but is my personal vision of for TD in the future.
p.s. maybe could be useful create more documentation and tutorials about how to develop external c++ nodes…this could speed up a lot the growth of new nodes
I was experimenting with this recently, and it looks like while transform works as expected, rotation is not applied. I can put together an example if that would help.
Ah ok, I’ll take a look
Hmm, I’m not able to reproduce, can you send your sample?
will do - give me a hot second
Oh bother - I think this might actually be user error. Still working on a clear example
confirmed that I just had it all wrong - I was missing a set of transforms.
An example for other folks looking at this technique:
base_instnace_from_3D_texture.tox (2.0 KB)