ICE: Doing an element-wise stretch on an array

Posted on March 28, 2013 by xsisupport

I’m not sure “element-wise stretch” is the right terminology, but what I mean is suppose you want to build a new array by repeating the original elements N times. For example, suppose you have the array [1,2], and you want to turn it into [1,1,1,1,2,2,2,2].

Here’s a little ICE technique to do just that:

This tree relies on Divide by Scalar truncating the scalar result to make it an integer.

Setting the DataArray2D attribute in scripting

Posted on March 20, 2013 by xsisupport

Last time I tried this, I gave up on JScript (it seemed impossible) and got something to work in Python.

In JScript, I kept getting errors like “# WARNING : 3392 – Invalid offset specified while extracting data from this attributeÈ.

si = Application
from win32com.client import constants as C            # win32com.client.constants

oObj = si.Selection(0)
oICEAttrMats = oObj.ActivePrimitive.AddICEAttribute("MyString", C.siICENodeDataString, C.siICENodeStructureArray, C.siICENodeContextSingleton)
oICEAttrMats.DataArray2D = [["a", "b", "c", "d"]]

x = oICEAttrMats.DataArray2D
print x
print len(x)
print len(x[0])
print len(x[0][0])

for d in x[0][0]:
    print d


# (((u'a', u'b', u'c', u'd'),),)
# 1
# 1
# 4
# a
# b
# c
# d

See also this Getting DataArray2D attribute values post.

ICE: Storing vectors in a color at vertices property

Posted on March 18, 2013 by xsisupport

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.

Getting the stored vectors back out:

Getting the DataArray2D for the Materials ICE attribute

Posted on March 12, 2013 by xsisupport

Here’s the Python way:

Application.SelectObj("Pedestrian_Mesh.Actor_Copies", None, None);
o = Application.Selection(0)

a = o.ActivePrimitive.Geometry.GetICEAttributeFromName("Materials")
print len(a.DataArray2D)
print len(a.DataArray2D[0] )
print a.DataArray2D[0][0]
for s in a.DataArray2D[0][0]:
    print s

# 1
# 1
# (u'', u'Sources.Materials.PedestrianLib.Shoes', u'Sources.Materials.PedestrianLib.Hair', u'Sources.Materials.PedestrianLib.Legs', u'Sources.Materials.PedestrianLib.Skin', u'Sources.Materials.PedestrianLib.Shirt')
# Sources.Materials.PedestrianLib.Shoes
# Sources.Materials.PedestrianLib.Hair
# Sources.Materials.PedestrianLib.Legs
# Sources.Materials.PedestrianLib.Skin
# Sources.Materials.PedestrianLib.Shirt

And here’s how to do it in JScript:

o = Selection(0);

a = o.ActivePrimitive.Geometry.GetICEAttributeFromName("Materials");

x = new VBArray( a.DataArray2D ).toArray();
y = new VBArray( x[0] ).toArray();
for ( var i = 0; i < y.length; i++ )
{
    LogMessage( y[i] )
}

ICE: translating polygons

Posted on March 11, 2013 by xsisupport

Here’s the basics for “transporting” polygons to another location. At this point, I’m just moving them one at a time (using Get Current Frame to drive it). The tricky part, if I remember correctly, was moving just some of them.

I had to calculate the destination positions in a separate ICE Tree further down the stack:

ICE: Removing duplicates from arrays

Posted on March 6, 2013 by xsisupport

Here’s an ICE tree that removes all duplicate elements from an array. It uses Generate Sample Set, so there’s no repeat nodes. But it relies on the fact that you can feed in an array of indices into Remove from Array, and Remove from Array doesn’t care if that array of indices itself contains duplicate. So, if you plug the array [1,1,1,2,2,2,3,3,3] in the Index port, Remove from Array will nicely remove elements 1, 2, and 3 with no complaints.

Unlike some other methods, this works with scalars too:

Use Global Coordinates for Display

Posted on February 27, 2013 by xsisupport

Sometimes it can be useful to turn on Use Global Coordinates for Display. Because otherwise you’re going to be looking at points in local space, and that can mess up your thinking.

Here’s a simple example to show the difference. Purple is global, light green is local. As you can see, the purple points match up with the actual coordinates.

Now here’s a better example of the usefulness of Use Global Coordinates for Display. Red is local (and misleading). Yellow is global. Imagine you’re doing all kinds of coordinate system conversions in a complicated tree, and then you decide to show values as points. If you’re not careful, like me sometimes, you end up doubting everything you’ve done and pulling it all apart.