No the method I describe is just for surface colors, not shaders. It's just a little quicker than having to have a prepared texture map on the geometry, if all you want to do is match simple colors.. You can't lookup surface lighting information on a geometry, you'd have to bake that. You can of cou...

Another method would be to use a CAV lookup. The mesh's vertex color could be looked up in the render tree and also looked up by particles (e.g. get emit location > cluster property > color). You might control the CAV map by painting or more procedurally in another ICE tree. But, of course you'll be...

Hi, like it says in the manual, you can't write data directly to groups, only to individual members. But you can do all your calculations on input data from a group, in a single ICETree (e.g. on a null). So, you'll be working on an array of data. Then on each member of the group, you'll need an ICE ...

Except the Face Roboto lip sinc, the other stuff is like......something that had to come with a patch, not with a final release... Omg, Autoshit politics.... they are gonna sell "nothing" for a lot of money. Jesus! A lot more shaders to speed up and optimize the render ? Omg... wtf! ?! Th...

I'm not certain, but I have a funny feeling that Mentalray does not support moblur on animated displacements.

Looks like a great release. Congrats, Eric!
Hey, if you're still pondering cache file formats, The GTO format looks pretty interesting.

The problem isn't the randomize compound, it's the use of animation offsets with ICE instances - a known issue. The set instance geometry nodes involve metalray assemblies which are written to disk, the usual (undesirable) behavior you see is preprocessing time going up and up the further you get o...

Hi Eric, is there any chance you could use the ICE cache format itself? I don't know what extra data you have in there, but assuming a topology description similar to that provided by the SDK polymesh.Get or .Get2, I don't see (naively) why you couldn't store that data as custom ICE attributes (sing...

seriously ascii is really slower than raw binary data, specially if you need topology data Yeah, our networks would not appreciate it, especially when we start to deal with heavy meshes...So, it'd be great if your binary format could support compression, like the ICE cache format does (I think it u...

just had a play with the demo, looks great! I'm sure I'll have some feature requests to come, but I like the level of control that's already available. If you're familiar with pWrapper, there's a nice function called 'swrap' that produces concavities and pinching in the mesh, that can give a very ex...

Very impressive, Eric.

Hi,
I've played with this idea a bit too: http://www.xsibase.com/forum/index.php? ... #msg252627

Hi,
you can use custom geometry along the strand, but not directly in ICE. Helge Mathee wrote a plugin that does this (it was on SI|Community forum). I think he uses a custom geometry operator to extrude a mesh along the strand.

In that case, you won't be able to access the UVs of the instances, only the original.

Maybe you could solve this in the Render Tree?

Just plug a randomize by range into the spin rate (turn animate off), so that each particle has a different rate.
Or, try turbulize by range so that the rate of each particle will evolve over its lifetime.

You can. e.g. Get data > Self.PointLocation > Get Data > Clusters/Textures_Coords/Texture_Projection/UVs The only problem is it has to be explicit UVs i.e. freeze the texture generator op. But, you can also write those UVs values, so you can come up with your own funky projections. As far as I know ...