locators are more or less that, barycentric coordinates coupled with a facet index kinda thing. Why they are not exposed atomically isn't 100% clear. It might be some eval issues with those atoms if they were to be exposed, just lack of foresight in the implementation somewhere back then, simply something missing that might one day come, or they might look up additional data of sorts (accelstruct?) and can't be decoupled from that.
Regardless, they can't be cracked open that I know of, not to read from them more granular-ly, nor to write directly into or over one. On Wed, Jun 12, 2013 at 1:46 PM, Vincent Fortin <vfor...@gmail.com> wrote: > Figured I'd start a new thread. This has been arousing my curiosity for a > while and I need your wisdom :-) > > In Houdini I build locations by providing a polygon index and what is > called a "uv parametric location". The term uv is misleading here. All it > is, is a coordinate on each polygon plane. > > Softimage's sdk calls it "subtriangle barycentric weights". So along with > the polygon index and the vertex indices I managed to build my location in > python. I didn't test this thoroughly but I seem to be getting an > equivalent to what I'm used to in Houdini. > > With regard to recreate this in ICE: > 1) Do we have access to the necessary data? (that is, polygon index, > subtriangle indices and the normalized weights on the triangle?) > 2) How would we go about assembling it? > > I understand this all sounds a bit abstract. Like everyone I use locations > a lot in ICE, they're amazing and manipulating them is easy. Maybe there is > no need for exposing lower-level functionalities. > I'm merely experimenting here to see how far I can push them. An example > would be to access those barycentric coordinates and, say, slide a particle > on a polygon without having to resort to the Get Closest Location node. > > Thoughts? > > -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
