ICE - Get closest location on group
Matt Lind
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
Alan Fregtman
Matt Lind
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
Matt Lind
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
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
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.
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
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.
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
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:
ps: did you a bonus of setting the object's name into the location. ;)
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"
-
Ideas?
Matt
Alan Fregtman
Matt Lind
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
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
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:
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
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
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
A.
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos
http://www.cappuccino-films.com
Matt Lind
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
Ahmidou Lyazidi
neighbors props named "B"
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos
http://www.cappuccino-films.com
Matt Lind
Ahmidou Lyazidi
I just tryed, and I have the correct behavior here (2012) and pulling the vertex color from the neigbhors not the sphere.
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.
Raffaele Fragapane
Until you reload, that is, that's when things will go (as they should) down the crapper.
Grahame Fuller
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
________________________________
To: XSI Mailing List
Subject: Re: ICE - Get closest location on group
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:
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.
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
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.
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
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:
ps: did you a bonus of setting the object's name into the location. ;)
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"
-
Ideas?
Matt
Matt Lind
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:
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:
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
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.
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.
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
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
________________________________
To: XSI Mailing List
Subject: Re: ICE - Get closest location on group
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:
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.
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
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.
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
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:
ps: did you a bonus of setting the object's name into the location. ;)
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"
-
Ideas?
Matt