Here’s a couple of examples of how to use a geometry query to modify certain points in a point cloud. The geometry queries return locations, and you can’t plug locations into Set Data nodes, so you need to take a different approach.
Tag Archives: locations
ICE: Storing vectors in a color at vertices property
The ICE trees for something suggested by Pooby in this Storing initial values thread on si-community. In this example, I’m trying to store per-point data into a per-sample attribute, so I have do a little extra work. I’m actually storing the point position multiple times for each vertex (one vertex had N samples), but I don’t know if it’s worth the effort to try and avoid that.
Given vertex index get point position
Three different ways to get the point position coordinates for a given vertex index.
In terms of getting to a per-object context, Point Index to Location seemed the most straightforward.
Stick to emit location on moving emitters
Getting equidistant points on a curve revisited
I had posted something on this before, but I used a Repeat node because Get Curve Distance from Curve Location doesn’t take an array of Distance Values.
Recently, Gray posted another approach on the XSI mailing list. While using Curve Distance to Curve Location will give you greater accuracy, this approach has the advantage of simplicity and no Repeat node:
The other day it occurred to me that maybe I could get rid of my Repeat node by using a point cloud:
- Use a per-point attribute to hold the different curve distance values.
- Then feed that per-point data set into the Distance Value port of the Curve Distance to Curve Location node
Here’s my ICE tree
It looks like it should work, but it doesn’t. Something goes wrong when I do the Set Point Position…all the odd-numbered points end up positioned at the end of the curve.
If I disconnect the Set Point Position node, and debug the tree, it looks like I’m getting all the right locations and points. So, for now, I’m stuck thinking I’m doing something wrong, but I haven’t figured it out yet…
Context matters: from PolygonToVertices to VertexToPolygons
This came up last week on the XSI mailing list. The goal, as I understand it, was this: for each polygon, build an array that contains the indices of all polygon neighbors.
So, to start, you can get an array of vertex locations for each polygon:
But when try to use those locations to get VertexToPolygons, that’s when you hit a problem:
Usually if it’s a context mismatch, you won’t be able to plug in the connection. In this situation, you can plug the result of Point Index to Location into the Get VertexToPolygons, but as soon as you do, both nodes go red. The tooltip indicates that ICE cannot figure out the structure of the data, that is, is this a single value or an array of values? The error goes back up to the Index port on Point Index to Location (if you right-click Point Index to Location and click Show Messages, you’ll get “ERROR: The type of port ‘Index’ is not defined.”).
If you unplug Get PolygonToVertex, then things are ok:
So, it is possible to use a Repeat node to build the per-polygon array of neighbor polygons.