Hello
just tried to re assemble a pretty much ordinary ICE construction - to use an array as uv input of ‘uv to location’ (prim uv vop in H) - and this does not work. Input does not match. Same with XYZ distance.
Now, question, is it a general rule. Does it work with some sort of coding, instead of VOP ?
Primitive attribute VOP and array
6344 6 0- amm
- Member
- 98 posts
- Joined: Aug. 2014
- Offline
- Anonymous
- Member
- 678 posts
- Joined: July 2005
- Offline
- amm
- Member
- 98 posts
- Joined: Aug. 2014
- Offline
1d array of 3d vectors, per point. Something like attached pic. Get element (ICE ‘select in array’) become at the end. Generally I'm seeking for something more flexible and pleasant, instead of bunch of prim atribute nodes. Evaluation speed doesn't matter that much, as it happens before deformations.
From what I've read, this should be doable by For Each SOP in H, but for now I have no idea how to get For Each thing to output an array.
From what I've read, this should be doable by For Each SOP in H, but for now I have no idea how to get For Each thing to output an array.
- Anonymous
- Member
- 678 posts
- Joined: July 2005
- Offline
- amm
- Member
- 98 posts
- Joined: Aug. 2014
- Offline
It is asking for ‘_standard_helpers_.h’ which probably is not present on my machine. Anyway thanks, I think I understand the method.
In meantime, got the workaround to work, by spreading points from points via Point Generate SOP, distributing values by point numbers of Point Generate, finally collecting them back by using Pcfind VOP (which one nicely returns array). In case of uniform distribution, actually I'd be able to avoid the Pcfind in favor of some modulo trickery.
Just for info, ICE ‘UV to location’ is exclusive for NURBS surfaces and curves, querying only an ‘intrinsic’ uv.
In meantime, got the workaround to work, by spreading points from points via Point Generate SOP, distributing values by point numbers of Point Generate, finally collecting them back by using Pcfind VOP (which one nicely returns array). In case of uniform distribution, actually I'd be able to avoid the Pcfind in favor of some modulo trickery.
Just for info, ICE ‘UV to location’ is exclusive for NURBS surfaces and curves, querying only an ‘intrinsic’ uv.
- Anonymous
- Member
- 678 posts
- Joined: July 2005
- Offline
amm
It is asking for ‘_standard_helpers_.h’ which probably is not present on my machine.
That's my personal file with some #define helpers I use sometimes. Not used anywhere in the file, so you can safely remove this line.
BTW. I didn't even used there vectors stored in array, because I don't see them used anywhere in attached image. It seems to just test array size, generate new array of numbers from 0-arraysize(), divides it and use it as U value. And that's it. No vector reading from original array.
- amm
- Member
- 98 posts
- Joined: Aug. 2014
- Offline
mantragora
BTW. I didn't even used there vectors stored in array, because I don't see them used anywhere in attached image. It seems to just test array size, generate new array of numbers from 0-arraysize(), divides it and use it as U value. And that's it. No vector reading from original array.
Well, it is an array, you should believe me Exactly is an array of locations, (relative coordinate interplated between points), from there you'll get point position or any else existing attribute. I intentionally made a screenshot of tooltip. But yeah, because of node polymorphism, you know that there is an array, only by tooltip, or by red node if trying to drive the wrong context (similar to attribute class in H), or, by what is plugged into port - that ‘invisibility’ is not a nice point, imho.
Wouldn't hurt to see the extension of work on array nodes in H15, already started in H14. It's not only geo querry in ICE, able to process an array - it is also a bunch of curve creation nodes ( I mean, ‘virtual’ curve). Or, feeding a random array into ray direction of ICE raycast (H intersect), creates a sort of ambient occlusion effect. And so on.
-
- Quick Links