ICE - Get closest location on group

128 views
Skip to first unread message

Matt Lind

unread,
Jul 17, 2013, 9:13:15 PM7/17/13
to soft...@listproc.autodesk.com

OK, I’m giving ICE another shot in production, but so far it’s failing.  I’m hoping it’s my fault, but I don’t see how this time.  See attached for specifics (created in 2013 SP1)

 

I am attempting to rewrite an in-house tool which is a variant of GATOR.  The example illustrated in the attached image is a sphere trying to pick up the vertex colors from neighboring objects.  The neighboring objects are inputs to a ‘group geometry’ node, which is then fed into the ‘closest locations’ node.  I perform a number of ‘is on geometry’ checks to find out which object was hit, and then get the color value from that object’s vertex colors property and apply it to the sphere’s vertex color property.

 

I am successfully determining the hit object within the group (as illustrated by the numbers on each vertex in the image), but the problem I am running into is the color value returned from the hit object’s vertex color property is always (0,0,0,1).  Clearly this is wrong.  If I set viewport shade mode to “constant”, the sphere will be completely black.

 

NOTES:

 

-          Each object has it’s own material and vertex color property.

-          Each object’s vertex color property is called “PrimaryColor”

-          I have attempted writing the color values to ICE Attributes, then apply in a 2nd pass – same result.

-           

 

 

Ideas?

 

 

 

 

 

Matt

 

 

ex__get_closest_location_on_group.scn
ex__get_closest_location_on_group.scntoc

Alan Fregtman

unread,
Jul 17, 2013, 10:22:44 PM7/17/13
to XSI Mailing List
I think you're overthinking it. You set your data, and fetch it from the location. That's it. Locations let you access any attribute.

See attached scene and screenshot below:

Inline image 1

ps: did you a bonus of setting the object's name into the location. ;)

ICE_example_GetClosestVertexColorFromGroup.png
si2013_example_getClosestLocationOnGroup.7z

Matt Lind

unread,
Jul 17, 2013, 10:36:55 PM7/17/13
to soft...@listproc.autodesk.com

That’s what I started with, but Softimage kept throwing context errors and wouldn’t let me connect all the nodes.  I added the extra switch contexts, select case, and other stuff to get around that.

 

However, in the bottom ICE Tree feeding into the first ‘Set Data’ you have a “Get VertexColor” node.  I don’t see that node anywhere in the preset manager, nor can I pull that attribute from the get closest location node.  How did you get that?  Same for ‘get memberID’.

 

 

Matt

Ciaran Moloney

unread,
Jul 17, 2013, 10:51:06 PM7/17/13
to soft...@listproc.autodesk.com
Those are just the names of the attributes that the get data is getting. 
image001.png

Matt Lind

unread,
Jul 17, 2013, 10:56:54 PM7/17/13
to soft...@listproc.autodesk.com

There is no “vertexColor” attribute in this example.  That is why I ask the question.

 

When I attempt to build the ICE tree as Alan illustrates, I get errors thrown at me where the “get vertexColor” node is shown in the image.

Matt Lind

unread,
Jul 17, 2013, 11:10:41 PM7/17/13
to soft...@listproc.autodesk.com

Ah, figured it out.  Alan didn’t mention he added extra ICE Trees on the other objects in the scene to populate the color values so the sphere could find them.  That won’t work for our production as the other objects may be inside reference models or other configurations which don’t play nice.

 

I need a solution where the sphere can pull the vertex color on its own without assistance.  I tried playing with arrays, but that turned out to be much more hassle then it was worth.

 

Back to the original question – any ideas why my ICE tree doesn’t work?

Chris Chia

unread,
Jul 18, 2013, 12:08:27 AM7/18/13
to soft...@listproc.autodesk.com
Hi Matt,
The reason your PrimaryColor is always 0,0,0,1 is because it's vertices map has no value.
You need to paint some colors on the map to make it right.

I believe this is how you should use the "Color at Vertices Map" at least.

See the attached file for the working colors.


Regards,
Chris

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Thursday, July 18, 2013 11:11 AM
To: soft...@listproc.autodesk.com
Subject: RE: ICE - Get closest location on group

Ah, figured it out. Alan didn't mention he added extra ICE Trees on the other objects in the scene to populate the color values so the sphere could find them. That won't work for our production as the other objects may be inside reference models or other configurations which don't play nice.

I need a solution where the sphere can pull the vertex color on its own without assistance. I tried playing with arrays, but that turned out to be much more hassle then it was worth.

Back to the original question - any ideas why my ICE tree doesn't work?

Matt



From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, July 17, 2013 7:57 PM
To: soft...@listproc.autodesk.com
Subject: RE: ICE - Get closest location on group

There is no "vertexColor" attribute in this example. That is why I ask the question.

When I attempt to build the ICE tree as Alan illustrates, I get errors thrown at me where the "get vertexColor" node is shown in the image.


Matt



From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Ciaran Moloney
Sent: Wednesday, July 17, 2013 7:51 PM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: Re: ICE - Get closest location on group

Those are just the names of the attributes that the get data is getting.

On Thu, Jul 18, 2013 at 3:36 AM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
That's what I started with, but Softimage kept throwing context errors and wouldn't let me connect all the nodes. I added the extra switch contexts, select case, and other stuff to get around that.

However, in the bottom ICE Tree feeding into the first 'Set Data' you have a "Get VertexColor" node. I don't see that node anywhere in the preset manager, nor can I pull that attribute from the get closest location node. How did you get that? Same for 'get memberID'.


Matt




From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>] On Behalf Of Alan Fregtman
Sent: Wednesday, July 17, 2013 7:23 PM
To: XSI Mailing List
Subject: Re: ICE - Get closest location on group

I think you're overthinking it. You set your data, and fetch it from the location. That's it. Locations let you access any attribute.

See attached scene and screenshot below:

[Inline image 1]

ps: did you a bonus of setting the object's name into the location. ;)


On Wed, Jul 17, 2013 at 9:13 PM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
OK, I'm giving ICE another shot in production, but so far it's failing. I'm hoping it's my fault, but I don't see how this time. See attached for specifics (created in 2013 SP1)

I am attempting to rewrite an in-house tool which is a variant of GATOR. The example illustrated in the attached image is a sphere trying to pick up the vertex colors from neighboring objects. The neighboring objects are inputs to a 'group geometry' node, which is then fed into the 'closest locations' node. I perform a number of 'is on geometry' checks to find out which object was hit, and then get the color value from that object's vertex colors property and apply it to the sphere's vertex color property.

I am successfully determining the hit object within the group (as illustrated by the numbers on each vertex in the image), but the problem I am running into is the color value returned from the hit object's vertex color property is always (0,0,0,1). Clearly this is wrong. If I set viewport shade mode to "constant", the sphere will be completely black.

NOTES:


- Each object has it's own material and vertex color property.

- Each object's vertex color property is called "PrimaryColor"

- I have attempted writing the color values to ICE Attributes, then apply in a 2nd pass - same result.

-


Ideas?





Matt




image001.png
ex__get_closest_location_on_group_modified.scn
color_vertice_map.png

Alan Fregtman

unread,
Jul 18, 2013, 12:13:54 AM7/18/13
to XSI Mailing List
>> Back to the original question – any ideas why my ICE tree doesn’t work?

You're trying to use SwitchContext nodes with different topology / point count. They're only for switching context between identical objects. If all the objects were the same it would probably work but obviously that's unfeasible.

After a little more thought, I retract my previous suggestion and recommend this simpler tree:

Inline image 1

image001.png
ICE_example_GetClosestVertexColorFromGroup2.png

Jack Kao

unread,
Jul 18, 2013, 12:15:02 AM7/18/13
to soft...@listproc.autodesk.com

What Alan did essentially.

image001.png
temp.jpg

Matt Lind

unread,
Jul 18, 2013, 12:45:50 AM7/18/13
to soft...@listproc.autodesk.com
WTF?  this makes absolutely no sense.
 
 
Intuitively I would expect the color to be an attribute that could be pulled from the location, or, you would use a 'select in array' style node where you specify the node index and it returns the color at that index.  plugging a location into a 'get data' node already instructed to pull a color from a vertex color property makes no sense / is poor UI design.
 
 
Matt
 
 

From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Alan Fregtman [alan.f...@gmail.com]
Sent: Wednesday, July 17, 2013 9:13 PM

Matt Lind

unread,
Jul 18, 2013, 12:53:53 AM7/18/13
to soft...@listproc.autodesk.com
the values in the sphere's vertex color property should be irrelevant because they're being overwritten by the colors of the neighboring objects.  Besides, I already tried painting just to see if stuff would show up, but it made no difference.  I think Alan's explanation applies in this case.
 
I have to say, ICE is really back assward in some of it's ways.
 
Matt
 
 
 

From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Chris Chia [chris...@autodesk.com]
Sent: Wednesday, July 17, 2013 9:08 PM

To: soft...@listproc.autodesk.com
Subject: RE: ICE - Get closest location on group

Hi Matt,

The reason your PrimaryColor is always 0,0,0,1 is because it’s vertices map has no value.

You need to paint some colors on the map to make it right.

 

I believe this is how you should use the “Color at Vertices Map” at least.

 

See the attached file for the working colors.

 

 

Regards,

Chris

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Thursday, July 18, 2013 11:11 AM
To: soft...@listproc.autodesk.com
Subject: RE: ICE - Get closest location on group

 

Ah, figured it out.  Alan didn’t mention he added extra ICE Trees on the other objects in the scene to populate the color values so the sphere could find them.  That won’t work for our production as the other objects may be inside reference models or other configurations which don’t play nice.

 

I need a solution where the sphere can pull the vertex color on its own without assistance.  I tried playing with arrays, but that turned out to be much more hassle then it was worth.

 

Back to the original question – any ideas why my ICE tree doesn’t work?

 

Matt

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, July 17, 2013 7:57 PM
To: soft...@listproc.autodesk.com
Subject: RE: ICE - Get closest location on group

 

There is no “vertexColor” attribute in this example.  That is why I ask the question.

 

When I attempt to build the ICE tree as Alan illustrates, I get errors thrown at me where the “get vertexColor” node is shown in the image.

 

 

Matt

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Ciaran Moloney
Sent: Wednesday, July 17, 2013 7:51 PM
To: soft...@listproc.autodesk.com
Subject: Re: ICE - Get closest location on group

 

Those are just the names of the attributes that the get data is getting. 

On Thu, Jul 18, 2013 at 3:36 AM, Matt Lind <ml...@carbinestudios.com> wrote:

That’s what I started with, but Softimage kept throwing context errors and wouldn’t let me connect all the nodes.  I added the extra switch contexts, select case, and other stuff to get around that.

 

However, in the bottom ICE Tree feeding into the first ‘Set Data’ you have a “Get VertexColor” node.  I don’t see that node anywhere in the preset manager, nor can I pull that attribute from the get closest location node.  How did you get that?  Same for ‘get memberID’.

 

 

Matt

 

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Alan Fregtman
Sent: Wednesday, July 17, 2013 7:23 PM
To: XSI Mailing List
Subject: Re: ICE - Get closest location on group

I think you're overthinking it. You set your data, and fetch it from the location. That's it. Locations let you access any attribute.

 

See attached scene and screenshot below:

 

Inline image 1

 

ps: did you a bonus of setting the object's name into the location. ;)

 

On Wed, Jul 17, 2013 at 9:13 PM, Matt Lind <ml...@carbinestudios.com> wrote:

OK, I’m giving ICE another shot in production, but so far it’s failing.  I’m hoping it’s my fault, but I don’t see how this time.  See attached for specifics (created in 2013 SP1)

 

I am attempting to rewrite an in-house tool which is a variant of GATOR.  The example illustrated in the attached image is a sphere trying to pick up the vertex colors from neighboring objects.  The neighboring objects are inputs to a ‘group geometry’ node, which is then fed into the ‘closest locations’ node.  I perform a number of ‘is on geometry’ checks to find out which object was hit, and then get the color value from that object’s vertex colors property and apply it to the sphere’s vertex color property.

 

I am successfully determining the hit object within the group (as illustrated by the numbers on each vertex in the image), but the problem I am running into is the color value returned from the hit object’s vertex color property is always (0,0,0,1).  Clearly this is wrong.  If I set viewport shade mode to “constant”, the sphere will be completely black.

 

NOTES:

 

-          Each object has it’s own material and vertex color property.

-          Each object’s vertex color property is called “PrimaryColor”

-          I have attempted writing the color values to ICE Attributes, then apply in a 2nd pass – same result.

-           

 

 

Ideas?

 

 

 

 

 

Matt

 

 

 

 

Matt Lind

unread,
Jul 18, 2013, 1:14:19 AM7/18/13
to soft...@listproc.autodesk.com
After hooking it up as illustrated, I still don't understand the logic.  Perhaps it's just the poor UI design here.
 
'Get Closest Locations' returns a location from one of the neighbor objects.  this is verified by hovering the mouse cursor over the output of the node.  Since topology of the neighbors is different than the sphere, and use a different vertex color property, why is the location connected as an input to the sphere's vertex color property and returning the neighbor's color?  Shouldn't the location be connected to the neighbor's vertex color property and looking up the color value from there?
 
thanks,
 
 
Matt
 
 
 
 

From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Alan Fregtman [alan.f...@gmail.com]
Sent: Wednesday, July 17, 2013 9:13 PM

Matt Lind

unread,
Jul 18, 2013, 1:16:30 AM7/18/13
to soft...@listproc.autodesk.com
I should add:
 
The sphere's vertex color property color values are at the default (0.75, 0.75, 0.75, 1) for all nodes.  Why is ICE displaying them as (0,0,0,1)?
 
 
Matt
 
 
 
 

From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Matt Lind [ml...@carbinestudios.com]
Sent: Wednesday, July 17, 2013 9:53 PM

Ahmidou Lyazidi

unread,
Jul 18, 2013, 1:19:57 AM7/18/13
to soft...@listproc.autodesk.com
It's not the sphere's property, but the neighbors ones. I think you are confused because they all have the same name.
Try to rename the sphere's property.

Cheers
A.

-----------------------------------------------
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos
http://www.cappuccino-films.com


2013/7/18 Matt Lind <ml...@carbinestudios.com>
image001.png
ICE_example_GetClosestVertexColorFromGroup2.png

Matt Lind

unread,
Jul 18, 2013, 1:24:46 AM7/18/13
to soft...@listproc.autodesk.com
I renamed all the neighbors' clusters and the ICE Tree still worked.  That's why I was confused.
 
 
Matt
 
 
 

From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Ahmidou Lyazidi [ahmid...@gmail.com]
Sent: Wednesday, July 17, 2013 10:19 PM

To: soft...@listproc.autodesk.com
Subject: Re: ICE - Get closest location on group

Ahmidou Lyazidi

unread,
Jul 18, 2013, 1:30:30 AM7/18/13
to soft...@listproc.autodesk.com
so you are saying that:

sphere prop named "A"
neighbors props named "B"

and in your icetree:
Closest location --> "A"

is still working? that might be a refresh issue, can you try to cut/paste the whole tree?

-----------------------------------------------
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos
http://www.cappuccino-films.com


2013/7/18 Matt Lind <ml...@carbinestudios.com>

Matt Lind

unread,
Jul 18, 2013, 1:36:29 AM7/18/13
to soft...@listproc.autodesk.com
all objects started with the same cluster and cluster property names:
 
   sphere.cls.NC_VertexData.PrimaryColor
   grid.cls.NC_VertexData.PrimaryColor
   torus.cls.NC_VertexData.PrimaryColor
   cube.cls.NC_VertexData.PrimaryColor
 
I renamed the neighbors so all are unique:
 
   sphere.cls.NC_VertexData.PrimaryColor
   grid.cls.ralph.PrimaryColor
   torus.cls.joe.PrimaryColor
   cube.cls.harry.PrimaryColor
 
After this modification I disconnected and reconnected the ICE tree, but the ICE tree still worked.
 
 
Matt
 
 
 
 

Sent: Wednesday, July 17, 2013 10:30 PM

Ahmidou Lyazidi

unread,
Jul 18, 2013, 2:00:17 AM7/18/13
to soft...@listproc.autodesk.com
Then restart softimage, or try to rebuild from scratch?

I just tryed, and I have the correct behavior here (2012) and pulling the vertex color from the neigbhors not the sphere.
If I change a neighbor cluster name the tree become invalid.
another thing is that sometimes (it's pretty rare) you have to cut/past the reference names in a not working set data to refresh.
It's generally working better than disconnect/reconnect.

Cheers,
A

Raffaele Fragapane

unread,
Jul 18, 2013, 2:35:07 AM7/18/13
to soft...@listproc.autodesk.com
It's perfectly possible to rename some properties, parameters or clusters and seeing a graph that behaved before still behave with the old names displayed but looking up the old hooks.
Until you reload, that is, that's when things will go (as they should) down the crapper.

Copying -> deleting -> pasting the entire graph is often as good as re-assemblying from scratch, and on par or some times better than reloading the scene.

Grahame Fuller

unread,
Jul 18, 2013, 12:23:13 PM7/18/13
to soft...@listproc.autodesk.com
The location is plugged into the Source input (which takes a location), rather than In Name (which takes a reference).

So the logic is: evaluate the attribute named "cls.NC_VertexData.PrimaryColor.Colors" at the input location (which is on the grouped geometry, not the sphere). This gives red, green, or blue depending on the location.

Later on, you use that value to set sphere.cls.NC_VertexData.PrimaryColor.Colors, but that has nothing intrinsically to do with the cls.NC_VertexData.PrimaryColor.Colors that you evaluated at the location, apart from being a property that shares the same name on a different object.

gray

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Thursday, July 18, 2013 1:14 AM
To: soft...@listproc.autodesk.com
Subject: RE: ICE - Get closest location on group

After hooking it up as illustrated, I still don't understand the logic. Perhaps it's just the poor UI design here.

'Get Closest Locations' returns a location from one of the neighbor objects. this is verified by hovering the mouse cursor over the output of the node. Since topology of the neighbors is different than the sphere, and use a different vertex color property, why is the location connected as an input to the sphere's vertex color property and returning the neighbor's color? Shouldn't the location be connected to the neighbor's vertex color property and looking up the color value from there?

thanks,


Matt




________________________________
From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [softimag...@listproc.autodesk.com] On Behalf Of Alan Fregtman [alan.f...@gmail.com]
Sent: Wednesday, July 17, 2013 9:13 PM
To: XSI Mailing List
Subject: Re: ICE - Get closest location on group
>> Back to the original question - any ideas why my ICE tree doesn't work?

You're trying to use SwitchContext nodes with different topology / point count. They're only for switching context between identical objects. If all the objects were the same it would probably work but obviously that's unfeasible.

After a little more thought, I retract my previous suggestion and recommend this simpler tree:

[Inline image 1]


On Wed, Jul 17, 2013 at 11:10 PM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
Ah, figured it out. Alan didn't mention he added extra ICE Trees on the other objects in the scene to populate the color values so the sphere could find them. That won't work for our production as the other objects may be inside reference models or other configurations which don't play nice.

I need a solution where the sphere can pull the vertex color on its own without assistance. I tried playing with arrays, but that turned out to be much more hassle then it was worth.

Back to the original question - any ideas why my ICE tree doesn't work?

Matt



From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>] On Behalf Of Matt Lind
Sent: Wednesday, July 17, 2013 7:57 PM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: RE: ICE - Get closest location on group

There is no "vertexColor" attribute in this example. That is why I ask the question.

When I attempt to build the ICE tree as Alan illustrates, I get errors thrown at me where the "get vertexColor" node is shown in the image.


Matt



From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Ciaran Moloney
Sent: Wednesday, July 17, 2013 7:51 PM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: Re: ICE - Get closest location on group

Those are just the names of the attributes that the get data is getting.

On Thu, Jul 18, 2013 at 3:36 AM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
That's what I started with, but Softimage kept throwing context errors and wouldn't let me connect all the nodes. I added the extra switch contexts, select case, and other stuff to get around that.

However, in the bottom ICE Tree feeding into the first 'Set Data' you have a "Get VertexColor" node. I don't see that node anywhere in the preset manager, nor can I pull that attribute from the get closest location node. How did you get that? Same for 'get memberID'.


Matt




From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>] On Behalf Of Alan Fregtman
Sent: Wednesday, July 17, 2013 7:23 PM
To: XSI Mailing List
Subject: Re: ICE - Get closest location on group

I think you're overthinking it. You set your data, and fetch it from the location. That's it. Locations let you access any attribute.

See attached scene and screenshot below:

[Inline image 1]

ps: did you a bonus of setting the object's name into the location. ;)


On Wed, Jul 17, 2013 at 9:13 PM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
OK, I'm giving ICE another shot in production, but so far it's failing. I'm hoping it's my fault, but I don't see how this time. See attached for specifics (created in 2013 SP1)

I am attempting to rewrite an in-house tool which is a variant of GATOR. The example illustrated in the attached image is a sphere trying to pick up the vertex colors from neighboring objects. The neighboring objects are inputs to a 'group geometry' node, which is then fed into the 'closest locations' node. I perform a number of 'is on geometry' checks to find out which object was hit, and then get the color value from that object's vertex colors property and apply it to the sphere's vertex color property.

I am successfully determining the hit object within the group (as illustrated by the numbers on each vertex in the image), but the problem I am running into is the color value returned from the hit object's vertex color property is always (0,0,0,1). Clearly this is wrong. If I set viewport shade mode to "constant", the sphere will be completely black.

NOTES:


- Each object has it's own material and vertex color property.

- Each object's vertex color property is called "PrimaryColor"

- I have attempted writing the color values to ICE Attributes, then apply in a 2nd pass - same result.

-


Ideas?





Matt





image003.jpg
image004.png

Matt Lind

unread,
Jul 19, 2013, 10:34:42 PM7/19/13
to soft...@listproc.autodesk.com

Not intuitive representation in the graph, but at least the logic makes sense and more closely aligns with what I see in the scripting and C++ SDK.

 

Next question – and this returns to where I started:  How do I look up vertex colors (or texture UVs or user normals) when the properties are arbitrarily named on each object?  

 

In my original example all the vertex color properties existed in a cluster with identical names.  99% of the time in production, the properties will have unique names, and/or unique paths to the properties.  Therefore, I cannot use a one size fits all solution of a single vertex color property reading the location of ‘get closest locations’.  Hence, my original setup with the ‘select case’ nodes and such.

 

What seems to be lacking is the ability to know which object in the group the found location resides.  Basically the same problem that exists with getting the subsurface index on NURBS Surface Meshes.  I need that index to properly branch the logic to look up the color in the proper vertex color property.  I can use a script, pick session or other method to find those properties and insert them into the ICE Tree, but I still need to know the group geometry index to properly look up the values in the correct vertex color property – other than the ‘is on geometry’ check, how do you deal with that problem?

 

Matt

 

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Grahame Fuller
Sent: Thursday, July 18, 2013 9:23 AM
To: soft...@listproc.autodesk.com
Subject: RE: ICE - Get closest location on group

 

The location is plugged into the Source input (which takes a location), rather than In Name (which takes a reference).

 

So the logic is: evaluate the attribute named “cls.NC_VertexData.PrimaryColor.Colors” at the input location (which is on the grouped geometry, not the sphere). This gives red, green, or blue depending on the location.

 

Later on, you use that value to set sphere.cls.NC_VertexData.PrimaryColor.Colors, but that has nothing intrinsically to do with the cls.NC_VertexData.PrimaryColor.Colors that you evaluated at the location, apart from being a property that shares the same name on a different object.

 

gray

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Thursday, July 18, 2013 1:14 AM
To: soft...@listproc.autodesk.com
Subject: RE: ICE - Get closest location on group

 

After hooking it up as illustrated, I still don't understand the logic.  Perhaps it's just the poor UI design here.

 

'Get Closest Locations' returns a location from one of the neighbor objects.  this is verified by hovering the mouse cursor over the output of the node.  Since topology of the neighbors is different than the sphere, and use a different vertex color property, why is the location connected as an input to the sphere's vertex color property and returning the neighbor's color?  Shouldn't the location be connected to the neighbor's vertex color property and looking up the color value from there?

 

thanks,

 

 

Matt

 

 

 

 

From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Alan Fregtman [alan.f...@gmail.com]
Sent: Wednesday, July 17, 2013 9:13 PM
To: XSI Mailing List
Subject: Re: ICE - Get closest location on group

>> Back to the original question – any ideas why my ICE tree doesn’t work?

 

You're trying to use SwitchContext nodes with different topology / point count. They're only for switching context between identical objects. If all the objects were the same it would probably work but obviously that's unfeasible.

 

After a little more thought, I retract my previous suggestion and recommend this simpler tree:

 

Inline image 1

 

 

On Wed, Jul 17, 2013 at 11:10 PM, Matt Lind <ml...@carbinestudios.com> wrote:

Ah, figured it out.  Alan didn’t mention he added extra ICE Trees on the other objects in the scene to populate the color values so the sphere could find them.  That won’t work for our production as the other objects may be inside reference models or other configurations which don’t play nice.

 

I need a solution where the sphere can pull the vertex color on its own without assistance.  I tried playing with arrays, but that turned out to be much more hassle then it was worth.

 

Back to the original question – any ideas why my ICE tree doesn’t work?

 

Matt

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, July 17, 2013 7:57 PM
To: soft...@listproc.autodesk.com
Subject: RE: ICE - Get closest location on group

 

There is no “vertexColor” attribute in this example.  That is why I ask the question.

 

When I attempt to build the ICE tree as Alan illustrates, I get errors thrown at me where the “get vertexColor” node is shown in the image.

 

 

Matt

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Ciaran Moloney
Sent: Wednesday, July 17, 2013 7:51 PM
To: soft...@listproc.autodesk.com
Subject: Re: ICE - Get closest location on group

 

Those are just the names of the attributes that the get data is getting. 

On Thu, Jul 18, 2013 at 3:36 AM, Matt Lind <ml...@carbinestudios.com> wrote:

That’s what I started with, but Softimage kept throwing context errors and wouldn’t let me connect all the nodes.  I added the extra switch contexts, select case, and other stuff to get around that.

 

However, in the bottom ICE Tree feeding into the first ‘Set Data’ you have a “Get VertexColor” node.  I don’t see that node anywhere in the preset manager, nor can I pull that attribute from the get closest location node.  How did you get that?  Same for ‘get memberID’.

 

 

Matt

 

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Alan Fregtman
Sent: Wednesday, July 17, 2013 7:23 PM
To: XSI Mailing List
Subject: Re: ICE - Get closest location on group

I think you're overthinking it. You set your data, and fetch it from the location. That's it. Locations let you access any attribute.

 

See attached scene and screenshot below:

 

Inline image 1

 

ps: did you a bonus of setting the object's name into the location. ;)

 

On Wed, Jul 17, 2013 at 9:13 PM, Matt Lind <ml...@carbinestudios.com> wrote:

OK, I’m giving ICE another shot in production, but so far it’s failing.  I’m hoping it’s my fault, but I don’t see how this time.  See attached for specifics (created in 2013 SP1)

 

I am attempting to rewrite an in-house tool which is a variant of GATOR.  The example illustrated in the attached image is a sphere trying to pick up the vertex colors from neighboring objects.  The neighboring objects are inputs to a ‘group geometry’ node, which is then fed into the ‘closest locations’ node.  I perform a number of ‘is on geometry’ checks to find out which object was hit, and then get the color value from that object’s vertex colors property and apply it to the sphere’s vertex color property.

 

I am successfully determining the hit object within the group (as illustrated by the numbers on each vertex in the image), but the problem I am running into is the color value returned from the hit object’s vertex color property is always (0,0,0,1).  Clearly this is wrong.  If I set viewport shade mode to “constant”, the sphere will be completely black.

 

NOTES:

 

-          Each object has it’s own material and vertex color property.

-          Each object’s vertex color property is called “PrimaryColor”

-          I have attempted writing the color values to ICE Attributes, then apply in a 2nd pass – same result.

-           

 

 

Ideas?

 

 

 

 

 

Matt

 

 

 

 

 

Grahame Fuller

unread,
Jul 22, 2013, 12:14:29 PM7/22/13
to soft...@listproc.autodesk.com
There's no ICE solution for that. The references get resolved before evaluation, which is why there is no string-to-reference node (which would require evaluation to get resolved).

You would need a script or something similar to go through the objects' clusters, figure out what properties they have, and rename them or copy them to standardized names. After that, you can do the rest in ICE. Obviously it's not ideal: you would need to relaunch the script whenever you add something to the group, and there'll be issues with multiple properties of the same type but with some good heuristics you can probably cover 99% of the cases.

As for knowing which member of the group a location belongs to, you can store a custom GroupID attribute individually on each group member and read that at the location. Again, you can use a script to add the trees on each member of the group, and you'd need to rerun whenever you add to the group or change its order. The XSISAMPLES\Scenes\ICE\ Kinematics_Rabbit_Rig scene was built using that technique to (to keep track of deformers, not to distinguish between locations on geometry). You can find the scripts in Application\Workgroups\ICE_Kinematics\Data\Scripts.

gray

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Friday, July 19, 2013 10:35 PM
To: soft...@listproc.autodesk.com
Subject: RE: ICE - Get closest location on group

Not intuitive representation in the graph, but at least the logic makes sense and more closely aligns with what I see in the scripting and C++ SDK.

Next question - and this returns to where I started: How do I look up vertex colors (or texture UVs or user normals) when the properties are arbitrarily named on each object?

In my original example all the vertex color properties existed in a cluster with identical names. 99% of the time in production, the properties will have unique names, and/or unique paths to the properties. Therefore, I cannot use a one size fits all solution of a single vertex color property reading the location of 'get closest locations'. Hence, my original setup with the 'select case' nodes and such.

What seems to be lacking is the ability to know which object in the group the found location resides. Basically the same problem that exists with getting the subsurface index on NURBS Surface Meshes. I need that index to properly branch the logic to look up the color in the proper vertex color property. I can use a script, pick session or other method to find those properties and insert them into the ICE Tree, but I still need to know the group geometry index to properly look up the values in the correct vertex color property - other than the 'is on geometry' check, how do you deal with that problem?

Matt




From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Grahame Fuller
Sent: Thursday, July 18, 2013 9:23 AM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: RE: ICE - Get closest location on group

The location is plugged into the Source input (which takes a location), rather than In Name (which takes a reference).

So the logic is: evaluate the attribute named "cls.NC_VertexData.PrimaryColor.Colors" at the input location (which is on the grouped geometry, not the sphere). This gives red, green, or blue depending on the location.

Later on, you use that value to set sphere.cls.NC_VertexData.PrimaryColor.Colors, but that has nothing intrinsically to do with the cls.NC_VertexData.PrimaryColor.Colors that you evaluated at the location, apart from being a property that shares the same name on a different object.

gray

From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Thursday, July 18, 2013 1:14 AM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: RE: ICE - Get closest location on group

After hooking it up as illustrated, I still don't understand the logic. Perhaps it's just the poor UI design here.

'Get Closest Locations' returns a location from one of the neighbor objects. this is verified by hovering the mouse cursor over the output of the node. Since topology of the neighbors is different than the sphere, and use a different vertex color property, why is the location connected as an input to the sphere's vertex color property and returning the neighbor's color? Shouldn't the location be connected to the neighbor's vertex color property and looking up the color value from there?

thanks,


Matt




________________________________
From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [softimag...@listproc.autodesk.com] On Behalf Of Alan Fregtman [alan.f...@gmail.com]
Sent: Wednesday, July 17, 2013 9:13 PM
To: XSI Mailing List
Subject: Re: ICE - Get closest location on group
>> Back to the original question - any ideas why my ICE tree doesn't work?

You're trying to use SwitchContext nodes with different topology / point count. They're only for switching context between identical objects. If all the objects were the same it would probably work but obviously that's unfeasible.

After a little more thought, I retract my previous suggestion and recommend this simpler tree:

[Inline image 1]


On Wed, Jul 17, 2013 at 11:10 PM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
Ah, figured it out. Alan didn't mention he added extra ICE Trees on the other objects in the scene to populate the color values so the sphere could find them. That won't work for our production as the other objects may be inside reference models or other configurations which don't play nice.

I need a solution where the sphere can pull the vertex color on its own without assistance. I tried playing with arrays, but that turned out to be much more hassle then it was worth.

Back to the original question - any ideas why my ICE tree doesn't work?

Matt



From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>] On Behalf Of Matt Lind
Sent: Wednesday, July 17, 2013 7:57 PM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: RE: ICE - Get closest location on group

There is no "vertexColor" attribute in this example. That is why I ask the question.

When I attempt to build the ICE tree as Alan illustrates, I get errors thrown at me where the "get vertexColor" node is shown in the image.


Matt



From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Ciaran Moloney
Sent: Wednesday, July 17, 2013 7:51 PM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: Re: ICE - Get closest location on group

Those are just the names of the attributes that the get data is getting.

On Thu, Jul 18, 2013 at 3:36 AM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
That's what I started with, but Softimage kept throwing context errors and wouldn't let me connect all the nodes. I added the extra switch contexts, select case, and other stuff to get around that.

However, in the bottom ICE Tree feeding into the first 'Set Data' you have a "Get VertexColor" node. I don't see that node anywhere in the preset manager, nor can I pull that attribute from the get closest location node. How did you get that? Same for 'get memberID'.


Matt




From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>] On Behalf Of Alan Fregtman
Sent: Wednesday, July 17, 2013 7:23 PM
To: XSI Mailing List
Subject: Re: ICE - Get closest location on group

I think you're overthinking it. You set your data, and fetch it from the location. That's it. Locations let you access any attribute.

See attached scene and screenshot below:

[Inline image 1]

ps: did you a bonus of setting the object's name into the location. ;)


On Wed, Jul 17, 2013 at 9:13 PM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
OK, I'm giving ICE another shot in production, but so far it's failing. I'm hoping it's my fault, but I don't see how this time. See attached for specifics (created in 2013 SP1)

I am attempting to rewrite an in-house tool which is a variant of GATOR. The example illustrated in the attached image is a sphere trying to pick up the vertex colors from neighboring objects. The neighboring objects are inputs to a 'group geometry' node, which is then fed into the 'closest locations' node. I perform a number of 'is on geometry' checks to find out which object was hit, and then get the color value from that object's vertex colors property and apply it to the sphere's vertex color property.

I am successfully determining the hit object within the group (as illustrated by the numbers on each vertex in the image), but the problem I am running into is the color value returned from the hit object's vertex color property is always (0,0,0,1). Clearly this is wrong. If I set viewport shade mode to "constant", the sphere will be completely black.

NOTES:


- Each object has it's own material and vertex color property.

- Each object's vertex color property is called "PrimaryColor"

- I have attempted writing the color values to ICE Attributes, then apply in a 2nd pass - same result.

-


Ideas?





Matt





image001.jpg