ice context (again)

[Sam Cuttriss]

sorry to flog this one again.

but i am consistently bumping into context problems when tinkering with ice.  

I figure, i cant be the only one,

so i might as well put in the effort to publicly figure it out with your help.

In the attached image im getting hung up trying to find neighbor polygons.  

The broader goal: ultimately i want to check a color at vertex map on the nodes(samples) of neighbor polygons to dictate the color of the currently assessed polygon.  

or basically probe attributes of any subcomponent and use their condition to set attributes on any other subcomponent.  

here im stalling out when i attempt to collect the adjacentPolys attribute i set at the per vertex level earlier (whilst im in a per polygon context, i think?)

obviously there is something very basic im misunderstanding.

cheers

_sam

[Ciaran Moloney]

Try using the point index to location node instead. ID to location is for particles.


Ciaran

[Sam Cuttriss]

sorry, yes i missed that one.  

still no dice,

its strange i can get an array of point positions using polygonToVerticies - index to location - get data (pointposition)   

but if i search for adjacentPolys things start turning red. even though the values display as arrays of polygon indices in the image i sent.

[Steven Caron]

i worked with sam a bit and we simplified the graph, but i think the issue is two fold. a) going back AND forth from verts to polys and b) the data you are trying to access at each component is of the array type. these arrays can be of different sizes, so when building an array from that set of data you can't use the proper indice mapping attribute ( 'PolygonToVertices', 'VertexToPolygons', etc ) to index into the array from set anymore. at least not do it easily. maybe using 'Select SubArray in Array' might help?

s

[Sam Cuttriss]

so here is an example of where i started before branching out into hack land.  

the lower branch is where things get squirrely

why will ice not return me the concatinated arrays of poly ids stored as "Polys" per vertex at the poly context level?

if i remove the select in array my graph turns red.  

if i add a "build array from set" i get an array of all locations at the object context level, not per polygon. 

[Grahame Fuller]

If I understood correctly, you ultimately want the CAVs of the polygon neighbours of a particular polygon. Do you mean neighbours that share a vertex or neighbours that share an edge? Or do you actually want the CAVs on just the polynodes that share a vertex with the original polygon?

gray

[Sam Cuttriss]

im doing a little cellular-automata (conways game of life: http://www.bitstorm.org/gameoflife/  http://en.wikipedia.org/wiki/Conway's_Game_of_Life)

I was going to use polygon colors to store/ see live or dead values.

these could obviously be per polygon boolean values, but that would avoid the whole point of this learning experience.

I am just using the test as a tool to learn how to juggle contexts effortlessly with ice.  

as you can probably tell, my level of comfort deteriorates rapidly as i start seeking to get or set data outside the current implicit context.

[Julian Johnson]

Sam - does ID to location work with geometry? Thought it was Particle
only. Would Point Index to Location be better?

[Grahame Fuller]

That's actually pretty tricky. I'm not entirely sure that it can be done without using Repeat nodes.

gray

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Sam Cuttriss
Sent: Thursday, October 06, 2011 05:10 PM
To: soft...@listproc.autodesk.com
Subject: Re: ice context (again)

[Sam Cuttriss]

I was suspecting as much.  

The limitation as i see it:  I can not concatenate  arrays of values from arbitrary contexts to another specified context?

i can get one value from another context but not arrays of values.

if i want arrays concatenated i can only store them at the object level ( build array from set )

A "build array at current element" node would be great for this if the functionality is not something that you want all nodes to naturally support?

The bottom branch of my above example  shows a case where my graph fails when arrays are being retrieved but functions fine when single values are presented.  

_sam

[Grahame Fuller]

Yep, that's pretty much the limitation in a nutshell. It is a lot easier finding polygon neighbours based on shared edges instead of shared points because you know that each edge is shared by only one or two polygons.

gray

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Sam Cuttriss
Sent: Friday, October 07, 2011 03:08 PM
To: soft...@listproc.autodesk.com
Subject: Re: ice context (again)

[Alan Fregtman]

You can store an array per particle, but it depends how your tree is flowing.

For example if you set an array with a SetData to an "On Creation"
input of an emitter, you should get an array per particle. There's
probably another way to do it, but off the top of my head I'm not
sure.

Contexts are certainly the most confusing aspect of ICE work, however.
Someone who completely understands should make a comprehensive ICE
contexts tutorial. It would be incredibly welcome.

Just my $0.02,

-- Alan

[Sam Cuttriss]

Storing an array per polygon, vertexes edge, whatever is not the problem

its concatenating neighboring arrays where ice fails.

in my example script i start in the polygon context, i get neighbor vertices, and retrieve their adjacent polygon ids 

for a non border polygon i would expect to get an array of 16 polygon ids ( 4 vertices with 4 adjacent polygons each )

i then would remove the current polygon ID and make all remaining IDs unique ( why isnt there a make array unique node?)

hypothetically leaving me an array of 8 unique neighbor polygon IDs per polygon.

now just like a scene from inception i want to go another level deeper and get color at vertex info from neighbour polygon nodes... etc etc etc.

i agree, a context whisperers dummies guide to getting and setting attributes from and too arbitrary contexts would be greatly appreciated.

[Sam Cuttriss]

So.... um.

noone feels limited by this?

to me it feels like a very real limitation,

if there are work arounds im happy to pursue them, 

or if others feel the same as me im happy to log a feature request.

[Steven Caron]

i think everyone does, but its hard to put into detail other than saying 'context' in ICE can be confusing. just look at all the ICE related posts by stephen blair on http://xsisupport.wordpress.com/. many of them discuss context and try to make it easier to understand. could there be a improvement to ICE at the core? or new compounds to ease the pain?

s

[Alan Fregtman]

Here's a way to make an ICE array unique:
http://s3.darkvertex.com/hlinked/ice/ICE_example_uniqueArray.png

Vectors in this case, but it should work with any array-capable ICE datatype.

Cheers,

-- Alan

[Steven Caron]

thanks alan

but the array being unique isn't an issue, in fact sam made a compound to make an array unique. and there is a 'vector3_union' custom node that ships with the softimage sdk.

s

[Alan Fregtman]

Missed Sam's unique compound. Move along then! ;)

[Alan Fregtman]

Haven't watched it fully but just noticed Paul Smith has a context
tutorial, if anyone wants to see it:
http://vimeo.com/26321257

[Stephen Blair]

As [I think] Gray mentioned, you could use a Repeat node.
http://xsisupport.files.wordpress.com/2011/10/neighbor_polys_array.png

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Sam Cuttriss
Sent: October-13-11 2:22 PM
To: soft...@listproc.autodesk.com
Subject: Re: ice context (again)

[Sam Cuttriss]

yes most these problems can be worked around with enough object level arrays and repeat nodes.  

at the expense of efficiency.

I guess others are not seeing it as a constant roadblock,

I'll rethink my approach, perhaps i can structure things differently