custom ICENode - questions and request for example source code

[Matt Lind]

I’ve been looking at the ICE SDK as a start to the process of writing custom ICE Nodes in C++.  I need to write topology generators, modifiers and deformation nodes.  So far all the source code I’ve seen supplied with Softimage only deal with particle clouds or primitive data such as converting integers to scalars.  Does anybody have source code for working with the Softimage SDK inside an ICE Node to modify topology/geometry?.....or Kinematics?   Example:  creating a polygon mesh from scratch, adding/removing subcomponents, dealing with clusters, etc…  I ask this partly because the ICE SDK docs say to not use the object model….which leads to the question – how do I do anything?

 

 

 

 

While also browsing the SDK docs, I saw in the ‘limitations’ section that custom ICE Nodes cannot define reference, location, or execute ports.   Since I am very interested in working with locations, does this mean I cannot do queries for locations from inside the ICE Node?  Or does it only mean I cannot send/receive locations from other ICE nodes?

 

Example:

 

I need to write an ICE Node which takes a polygon mesh and 2 NURBS Surfaces as inputs, and whose output is the deformation of a 2^nd polygon mesh.  To accomplish this feat requires the use of point Locators to map the relationship between the first polygon mesh’s points relative to the first surface, then re-interpret that information to deform the points of the 2^nd polygon mesh in relation to the 2^nd surface.  You can assume the two polygon meshes and two surfaces have identical topology.  I need to write this as a custom ICE node because it is prohibitively expensive to use the factory nodes (too many nodes/workarounds required leading to severe performance degradation).

 

I’d like to be able to do a point locator query from inside the custom ICE node for performance (and convenience) reasons.  Sample code would be a big help.

 

 

Anybody?

 

 

Matt

 

 

[Ciaran Moloney]

I'm sorta , kinda sure that's a dead end for a custom node. You might be better off optimizing your ICE tree. It doesn't sound like such a complex problem, care to share?

[Raffaele Fragapane]

Yeah, same hunch here.

Unless the performance expectations are in the multiple characters real-time concurrently, in which case I think neither way is gonna get there usually.

--
Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

[Matt Lind]

well, let's answer the questions first:

 

1) Does anybody have source code they are willing to share for custom ICE Nodes that deal with topology and/or geometry?

 

2) Does the lack of reference, location, and execute ports for custom ICE nodes mean I cannot cast a location search from inside an ICE node?

 

 

 

To answer your question:

 

Imagine two nulls and two NURBS Surfaces.  the task is to find the nearest location from the first null to the first surface.  At that location, build an orthonormal basis and compute the local transform of the null relative to that basis.  Then reconstruct that relationship by applying it to the 2nd null relative to the 2nd surface assuming both surfaces use uniform parameterization, not non-uniform as is the softimage default.  Version 2: extend to operate on vertices of polygon meshes instead of nulls.  I have a working version, but it is slow and not very stable.

 

The problem I'm encountering is it simply takes too many factory nodes to be able to work efficiently. Each node has a certain amount of overhead regardless of what it does. Plus, the support for NURBS in ICE is rather abysmal. I have to construct my own orthonormal basis plus implement my own algorithm to convert from non-uniform parameterization to uniform parameterization.  Both are doable, but take very many nodes to do it (including support for edge cases) making the whole effort rather clumsy at best. The parameterization conversion is expensive as it involves sorting and searching (while/repeat/counter nodes).  When applying the ICE Compound to a polygon mesh with 5,000+ vertices.....it gets the job done, but chugs. 

 

I have a version of this tool written as a scripted operator, and it performs really well because it has better SDK support and the sorting/searching can be better optimized.  But one shortcoming of scripted operators is they self-delete if an input goes missing (which often happens on scene load or model import when the content has been modifed externally).  This in turn causes content using the operator to malfunction generating bug reports which are sent to artists to fix.  Unfortunately most artists weren't around when the content was created years ago, so they have no idea what's wrong, what the expected output is supposed to look like, or how to fix it.  Often an asset has to be retired and replaced.   This is my motivation for rewriting the tool as a custom ICE node as ICE is much more graceful when it's inputs don't exist - it just turns red and sits patiently until conditions improve.  This gives artists a chance to fix the problem without having to sweat the details because they can read the GetData node to see what's missing, then find and repair it.  I'm trying to make the content in our pipeline more durable.

 

So...I'm looking for code samples of how to deal with topology and geometry in ICE.  So far I have not found any.

 

 

Matt

 

 

 

 

 

 

---

From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane [raffsx...@googlemail.com]
Sent: Tuesday, May 14, 2013 9:00 PM
To: soft...@listproc.autodesk.com
Subject: Re: custom ICENode - questions and request for example source code

[Ahmidou Lyazidi]

From my small experience about this, you can't make a custom topology or kinematics "node", you make a node that abstract the more or less complex  computation, then you feed the topology nodes (or a matrix in the case of  kinematics).

As you stated you can't use locators, or location queries in a custom ice node, so if you need them the workflow is to break you ice node in smaller parts.

About the preformance sometimes it's faster, sometimes quite the same. I made a parallel transport frame node, the gain was only 15% but the setup faster.

This node seems to perform way faster:

http://shaderop.com/2011/07/cubic-bezier-curve-node-for-softimage-ice/index.html

A

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

2013/5/15 Matt Lind <ml...@carbinestudios.com>

[Raffaele Fragapane]

If you are using while and repeat nodes to reparametrize the surface, you are paying a ton of unnecessary costs. Yes, those things are slow, no, they are often not required, which is why both me and Ciaran had the same hunch.

Matter of fact, I very recently worked on an equivalent problem, but trickier (think of adding a dimensionality).

By far the fastest approach, although it might seem counter-intuitive, is to search and filter geometry, even if it's A LOT of nearest location runs, they will always be fast and do an excellent job of accessing a shared optimized structure, then it's up to you to filter the arrays in an ICE friendly way (so, no repeats), which again is a puzzling art on its own some times (Stephen's has excellent blog entries about many basics and sorting tricks if you are unfamiliar)

I hear a lot of people complaining about ICE performance, and then frequently enough they treat it like if it was a normal programming language and try to hammer in whiles, repeats, walking to conditions, multidimensional array equivalents and so on, on the assumption that saving nodes is going to make things faster, when in actuality there are other ways, that might seem counter-intuitive, that will blaze by any of those methods.

Most factory nodes even in the hundreds add a negligible overhead, I have complex functions totalling hundreds running faster than the monitor loop can time them, and still topping the vSync with sampling rates in the thousands. Food for thought there.

ICE still sucks at some many to one cases and definitely does at many to many, but a problem like re-parametrizing a surface and getting a correlated coherent transform for a null from is not one of them.

I mean no offense, but it sounds like you haven't spent a lot of time working with ICE, and you are coming from the assumption that your respectable programming knowledge in terms of what's optimal and what isn't might transfer across directly, when chances are it's hurting more than anything.

You have to think laterally a good few degrees of separation from C or JS to ICE in terms of what's optimal, it's often ironically a lot closer to the metal in its SIMD roots than something that gets to scuttle through GCC before running gets to be.

[Guillaume Laforge]

For topology, there is no SDK access. But a custom node can do all the low level stuff (manipulating the so called PolygonalDescription).

Same for Kinematics, a custom node can manipulate a 4X4 matrix.

At the end you need to set the topo/kine using the corresponding attribute.

Here is an example (with source code) to create topology using a custom ICE node: http://frenchdog.wordpress.com/2012/01/05/happy-2012/

If you want to do everything with one node, it is a job for a custom operator I think.

Guillaume

[Guillaume Laforge]

As my blog is rather dead those days, I put the code, compound and scenes on this public repo: https://github.com/frenchdog/ICEConvexHull

Cheers,

Guillaume

[Matt Lind]

That’s what I was afraid of.

 

I remember your findings from a while ago, which was part of my incentive to pursue this route.  500ms vs. 20ms is quite significant (2500%). In my case it would be the difference between acceptable performance and unacceptable performance.

 

I’m OK with having to break this down into a small handful of nodes (~10), but I’m not OK with having to use 300 or so as is currently the case.

 

On the kinematics front, I’d like to compute the local transform of one object relative to another and spit out the result as a 4x4 matrix.  That alone would eliminate 50 nodes from the tree for each instance which the functionality is needed.  Another node to convert a UV location from non-uniform to uniform parameterized space would eliminate a significant number of nodes too, and that’s really the bottleneck at this point because doing searches and reverse lookups using the factory nodes is quite cumbersome and impractical.

 

 

 

Matt

[Matt Lind]

BTW – the link to the source code is dead.

 

Matt

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Ahmidou Lyazidi

Sent: Wednesday, May 15, 2013 3:07 AM

[Sebastien Sterling]

" for Topology there is no SDK access" does this mean none existent or locked ? and..Why ? if Matt wants to create custom nodes, are the limitation inherent to ice, or is ice like the standard SDK locked in certain areas ?

[Grahame Fuller]

I'm confused. Calculating the local tranform of of object relative to another is just a matter of matrix inversion and multiplication. But of course you already know that, Matt, so I must be misunderstanding something about your problem.

Also, have you tried using either the Reinterpret Location on New Geometry or the UV to Location nodes? They might avoid the parameterization issues.

If I can find some spare time I might try to knock up a simple demo. Remind me which version of Softimage you are currently using?

gray

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, May 15, 2013 02:26 PM
To: soft...@listproc.autodesk.com
Subject: RE: custom ICENode - questions and request for example source code

That's what I was afraid of.

I remember your findings from a while ago, which was part of my incentive to pursue this route. 500ms vs. 20ms is quite significant (2500%). In my case it would be the difference between acceptable performance and unacceptable performance.

I'm OK with having to break this down into a small handful of nodes (~10), but I'm not OK with having to use 300 or so as is currently the case.

On the kinematics front, I'd like to compute the local transform of one object relative to another and spit out the result as a 4x4 matrix. That alone would eliminate 50 nodes from the tree for each instance which the functionality is needed. Another node to convert a UV location from non-uniform to uniform parameterized space would eliminate a significant number of nodes too, and that's really the bottleneck at this point because doing searches and reverse lookups using the factory nodes is quite cumbersome and impractical.



Matt

From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Ahmidou Lyazidi
Sent: Wednesday, May 15, 2013 3:07 AM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: Re: custom ICENode - questions and request for example source code

>From my small experience about this, you can't make a custom topology or kinematics "node", you make a node that abstract the more or less complex computation, then you feed the topology nodes (or a matrix in the case of kinematics).
As you stated you can't use locators, or location queries in a custom ice node, so if you need them the workflow is to break you ice node in smaller parts.
About the preformance sometimes it's faster, sometimes quite the same. I made a parallel transport frame node, the gain was only 15% but the setup faster.
This node seems to perform way faster:
http://shaderop.com/2011/07/cubic-bezier-curve-node-for-softimage-ice/index.html
A


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

2013/5/15 Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>>

well, let's answer the questions first:

1) Does anybody have source code they are willing to share for custom ICE Nodes that deal with topology and/or geometry?

2) Does the lack of reference, location, and execute ports for custom ICE nodes mean I cannot cast a location search from inside an ICE node?



To answer your question:

Imagine two nulls and two NURBS Surfaces. the task is to find the nearest location from the first null to the first surface. At that location, build an orthonormal basis and compute the local transform of the null relative to that basis. Then reconstruct that relationship by applying it to the 2nd null relative to the 2nd surface assuming both surfaces use uniform parameterization, not non-uniform as is the softimage default. Version 2: extend to operate on vertices of polygon meshes instead of nulls. I have a working version, but it is slow and not very stable.

The problem I'm encountering is it simply takes too many factory nodes to be able to work efficiently. Each node has a certain amount of overhead regardless of what it does. Plus, the support for NURBS in ICE is rather abysmal. I have to construct my own orthonormal basis plus implement my own algorithm to convert from non-uniform parameterization to uniform parameterization. Both are doable, but take very many nodes to do it (including support for edge cases) making the whole effort rather clumsy at best. The parameterization conversion is expensive as it involves sorting and searching (while/repeat/counter nodes). When applying the ICE Compound to a polygon mesh with 5,000+ vertices.....it gets the job done, but chugs.

I have a version of this tool written as a scripted operator, and it performs really well because it has better SDK support and the sorting/searching can be better optimized. But one shortcoming of scripted operators is they self-delete if an input goes missing (which often happens on scene load or model import when the content has been modifed externally). This in turn causes content using the operator to malfunction generating bug reports which are sent to artists to fix. Unfortunately most artists weren't around when the content was created years ago, so they have no idea what's wrong, what the expected output is supposed to look like, or how to fix it. Often an asset has to be retired and replaced. This is my motivation for rewriting the tool as a custom ICE node as ICE is much more graceful when it's inputs don't exist - it just turns red and sits patiently until conditions improve. This gives artists a chance to fix the problem without having to sweat the details because they can read the GetData node to see what's missing, then find and repair it. I'm trying to make the content in our pipeline more durable.

So...I'm looking for code samples of how to deal with topology and geometry in ICE. So far I have not found any.


Matt






________________________________

From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>] On Behalf Of Raffaele Fragapane [raffsx...@googlemail.com<mailto:raffsx...@googlemail.com>]

Sent: Tuesday, May 14, 2013 9:00 PM

To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>

Subject: Re: custom ICENode - questions and request for example source code
Yeah, same hunch here.
Unless the performance expectations are in the multiple characters real-time concurrently, in which case I think neither way is gonna get there usually.

On Wed, May 15, 2013 at 1:04 PM, Ciaran Moloney <moloney...@gmail.com<mailto:moloney...@gmail.com>> wrote:
I'm sorta , kinda sure that's a dead end for a custom node. You might be better off optimizing your ICE tree. It doesn't sound like such a complex problem, care to share?

On Wed, May 15, 2013 at 2:41 AM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
I've been looking at the ICE SDK as a start to the process of writing custom ICE Nodes in C++. I need to write topology generators, modifiers and deformation nodes. So far all the source code I've seen supplied with Softimage only deal with particle clouds or primitive data such as converting integers to scalars. Does anybody have source code for working with the Softimage SDK inside an ICE Node to modify topology/geometry?.....or Kinematics? Example: creating a polygon mesh from scratch, adding/removing subcomponents, dealing with clusters, etc... I ask this partly because the ICE SDK docs say to not use the object model....which leads to the question - how do I do anything?

[Steven Caron]

they don't provide access to the 'topology' type input or output port. you have to make a node that outputs point positions and polygon description.

here is an example node which meshes and openvdb grid from an incomplete project of mine...

https://github.com/caron/OpenVDB_Softimage/blob/master/VDB_Node_VolumeToMesh.cpp

s

[Matt Lind]

I think your assumptions are rather off base, Raff.

 

I’d be interested in seeing how you remap a non-uniform UV coordinate to uniform space in ICE using your brute force technique.  I solved this problem for a traditional operator, but I cannot see how using your methods it can be done in ICE.  In fact, I don’t think ICE exposes enough of the right kind of information to make it possible.  But since you said you’ve done it, I’d like to see how it’s done. J

 

The problem:

 

Given a location described as a normalized UV coordinate in non-uniform parameterized space, find the equivalent location on another NURBS surface as a normalized UV coordinate described in uniform parameterized space.

 

Test case:

 

Given 2 NURBS grids with 4 isolines (subdivisions) in U and V.  Leave the first surface as a flat plane without deformations, create the 2^nd surface by duplicating the first surface and deforming the 2^nd surface significantly – translate the 2^nd surface away from the world origin so you can see what you’re doing.  On the first surface, get the UV Coordinate for the first interior isoline intersection in U and V (should be roughly 0.25, 0.25).  Convert that UV coordinate to uniform parameterized space so it finds the same first interior isoline intersection on the 2^nd surface.  Do it using only factory ICE nodes.

 

Actual use case: Repeat the test for arbitrary locations when the surfaces are surface meshes comprised of multiple surfaces (or subsurfaces if you prefer)

 

 

The main problem here is it takes waaaaaaay too many nodes to get the job done in a practical manner.  We need protection against regressions of nodes that seem to occur from release to release.  The last thing I want to deal with is debugging an ICE Tree with 300+ nodes because one node in the bunch now clamps incorrectly, returns NaN, or doesn’t handle divide by zero errors correctly (because a bug elsewhere fed it a zero).  Finding problems like this in a traditional operator is manageable, but doing so in ICE is torture.

 

 

Matt

[Matt Lind]

Yes, computing a local transform between two objects is pretty trivial, but that’s not what I’m doing.

 

I am finding the nearest location on a NURBS surface from an object.  I then build an orthonormal basis at that location, and compute the local transform from the object relative to the orthonormal basis.  The issue is with the location on the NURBS surface.  There is no convenient way to compute the orthonormal basis because the information returned in the point locator is approximate and based on the control point hull of the surface, not the surface itself.  Therefore I’ve had to resort to a workaround of manually constructing the tangent vectors by issuing multiple location searches by minute distances in U and V from the nearest location found on the surface.  Problems arise when I get near the edge/boundary of a surface as I must flip my logic around to create vectors pointing the other direction so I can construct the basis.  I have accomplished the feat, but not after using waaaaaay more nodes than should be necessary for such a basic task.  I would like to package this into a custom ICE node for convenience as the functionality is needed multiple times within the ICE Tree.

 

The UV to Location and reinterpret nodes both operate in non-uniform parameterized space.  They take a given UV coordinate from one surface and remap it to the other surface, but the resulting location is not topologically equivalent.  I had to solve this manually in my scripted operator by doing a reverse lookup of the surrounding knots and samples of the location on the first surface, then do a linear interpolation between the equivalent subcomponents on the other surface to find the topologically equivalent location.  Works, but is slow, and Softimage occasionally returns NaN when requesting the sample/knot near a boundary/edge.

 

Using Softimage 2013 SP1 (32 bit)

2013/5/15 Matt Lind <ml...@carbinestudios.com>

well, let's answer the questions first:

 

1) Does anybody have source code they are willing to share for custom ICE Nodes that deal with topology and/or geometry?

 

2) Does the lack of reference, location, and execute ports for custom ICE nodes mean I cannot cast a location search from inside an ICE node?

 

 

 

To answer your question:

 

Imagine two nulls and two NURBS Surfaces.  the task is to find the nearest location from the first null to the first surface.  At that location, build an orthonormal basis and compute the local transform of the null relative to that basis.  Then reconstruct that relationship by applying it to the 2nd null relative to the 2nd surface assuming both surfaces use uniform parameterization, not non-uniform as is the softimage default.  Version 2: extend to operate on vertices of polygon meshes instead of nulls.  I have a working version, but it is slow and not very stable.

 

The problem I'm encountering is it simply takes too many factory nodes to be able to work efficiently. Each node has a certain amount of overhead regardless of what it does. Plus, the support for NURBS in ICE is rather abysmal. I have to construct my own orthonormal basis plus implement my own algorithm to convert from non-uniform parameterization to uniform parameterization.  Both are doable, but take very many nodes to do it (including support for edge cases) making the whole effort rather clumsy at best. The parameterization conversion is expensive as it involves sorting and searching (while/repeat/counter nodes).  When applying the ICE Compound to a polygon mesh with 5,000+ vertices.....it gets the job done, but chugs. 

 

I have a version of this tool written as a scripted operator, and it performs really well because it has better SDK support and the sorting/searching can be better optimized.  But one shortcoming of scripted operators is they self-delete if an input goes missing (which often happens on scene load or model import when the content has been modifed externally).  This in turn causes content using the operator to malfunction generating bug reports which are sent to artists to fix.  Unfortunately most artists weren't around when the content was created years ago, so they have no idea what's wrong, what the expected output is supposed to look like, or how to fix it.  Often an asset has to be retired and replaced.   This is my motivation for rewriting the tool as a custom ICE node as ICE is much more graceful when it's inputs don't exist - it just turns red and sits patiently until conditions improve.  This gives artists a chance to fix the problem without having to sweat the details because they can read the GetData node to see what's missing, then find and repair it.  I'm trying to make the content in our pipeline more durable.

 

So...I'm looking for code samples of how to deal with topology and geometry in ICE.  So far I have not found any.

 

 

Matt

 

 

 

 

 

 

From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane [raffsx...@googlemail.com]
Sent: Tuesday, May 14, 2013 9:00 PM
To: soft...@listproc.autodesk.com
Subject: Re: custom ICENode - questions and request for example source code

Yeah, same hunch here.

Unless the performance expectations are in the multiple characters real-time concurrently, in which case I think neither way is gonna get there usually.

On Wed, May 15, 2013 at 1:04 PM, Ciaran Moloney <moloney...@gmail.com> wrote:

I'm sorta , kinda sure that's a dead end for a custom node. You might be better off optimizing your ICE tree. It doesn't sound like such a complex problem, care to share?

 

On Wed, May 15, 2013 at 2:41 AM, Matt Lind <ml...@carbinestudios.com> wrote:

I’ve been looking at the ICE SDK as a start to the process of writing custom ICE Nodes in C++.  I need to write topology generators, modifiers and deformation nodes.  So far all the source code I’ve seen supplied with Softimage only deal with particle clouds or primitive data such as converting integers to scalars.  Does anybody have source code for working with the Softimage SDK inside an ICE Node to modify topology/geometry?.....or Kinematics?   Example:  creating a polygon mesh from scratch, adding/removing subcomponents, dealing with clusters, etc…  I ask this partly because the ICE SDK docs say to not use the object model….which leads to the question – how do I do anything?

 

 

 

 

While also browsing the SDK docs, I saw in the ‘limitations’ section that custom ICE Nodes cannot define reference, location, or execute ports.   Since I am very interested in working with locations, does this mean I cannot do queries for locations from inside the ICE Node?  Or does it only mean I cannot send/receive locations from other ICE nodes?

 

Example:

 

I need to write an ICE Node which takes a polygon mesh and 2 NURBS Surfaces as inputs, and whose output is the deformation of a 2^nd polygon mesh.  To accomplish this feat requires the use of point Locators to map the relationship between the first polygon mesh’s points relative to the first surface, then re-interpret that information to deform the points of the 2^nd polygon mesh in relation to the 2^nd surface.  You can assume the two polygon meshes and two surfaces have identical topology.  I need to write this as a custom ICE node because it is prohibitively expensive to use the factory nodes (too many nodes/workarounds required leading to severe performance degradation).

 

I’d like to be able to do a point locator query from inside the custom ICE node for performance (and convenience) reasons.  Sample code would be a big help.

 

 

Anybody?

 

 

Matt

 

 

[Guillaume Laforge]

" for Topology there is no SDK access" does this mean none existent or locked ? and..Why ?

It means that you can't get the Topology attribute inside your custom node to play with it and you can't output Topology attribute from a custom node.

The Topology attribute is not only the topology of the mesh. You can imagine the Topology attribute like a system that let you describe what you want to do on your mesh using standard Softimage modeling operators. 

Lets say you want to extrude and then add a vertex to your polygon mesh, the topology attribute will just store a "stack of actions" that will be executed only when you plug it into a Set Data node set to "Topology".

The operations that can be added to this stack must be known by Softimage. For example, if you plug a Split Edge node into a Set Topology node, it will call the same Split Edge function than modelers are using since ...XSI can split edges :).

Adding SDK support for ICE Topology would mean adding the ability for users to add their own custom modeling function callable from ICE. I have no idea how complicate it would be to implement such thing :).

While I was working on ICE Modeling I added the "Create Topo" node to let users create custom topology from built in nodes or from a custom one.

Create Topo just need the array of positions and the indices of the polygons to create the mesh. 

The advantage of native modeling commands vs Create Topo is that they can update clusters...

Now you know as much as I know on ICE topo ;)

Cheers

G.   

---

2013/5/15 Matt Lind <ml...@carbinestudios.com>

I've been looking at the ICE SDK as a start to the process of writing custom ICE Nodes in C++. I need to write topology generators, modifiers and deformation nodes. So far all the source code I've seen supplied with Softimage only deal with particle clouds or primitive data such as converting integers to scalars. Does anybody have source code for working with the Softimage SDK inside an ICE Node to modify topology/geometry?.....or Kinematics? Example: creating a polygon mesh from scratch, adding/removing subcomponents, dealing with clusters, etc… I ask this partly because the ICE SDK docs say to not use the object model….which leads to the question - how do I do anything?

 

 

 

 

While also browsing the SDK docs, I saw in the 'limitations' section that custom ICE Nodes cannot define reference, location, or execute ports. Since I am very interested in working with locations, does this mean I cannot do queries for locations from inside the ICE Node? Or does it only mean I cannot send/receive locations from other ICE nodes?

 

Example:

 

I need to write an ICE Node which takes a polygon mesh and 2 NURBS Surfaces as inputs, and whose output is the deformation of a 2^nd polygon mesh. To accomplish this feat requires the use of point Locators to map the relationship between the first polygon mesh's points relative to the first surface, then re-interpret that information to deform the points of the 2^nd polygon mesh in relation to the 2^nd surface. You can assume the two polygon meshes and two surfaces have identical topology. I need to write this as a custom ICE node because it is prohibitively expensive to use the factory nodes (too many nodes/workarounds required leading to severe performance degradation).

 

I'd like to be able to do a point locator query from inside the custom ICE node for performance (and convenience) reasons. Sample code would be a big help.

 

 

Anybody?

 

 

Matt

 

 

 

[olivier jeannel]

Hi there,

Nightmaring on this the whole afternoon, I thought I'd be genius enough
to find but, ....no :(

I have a simulated pointcloud of 40 particles.
I have another non simulated pointcloud of 1 particle with a strand with
a StrandCount of 40.

How the hell, do I snap the 40 StrandPosition on the 40 (PointPosition)
particles ?
I'd like one big strand (not 40 pieces of strands in between
pointpositions) .

Thank's for any help ^^

Olivier

[Steven Caron]

you want a line connecting them all?

[olivier jeannel]

Yessss

[Thomas Volkmann]

no time to try it, but 'build array from set' should work?

get the 40pointspointcloud.pointPosition -> build array from set -> set StrandPosition

 

olivier jeannel <olivier...@noos.fr> hat am 15. Mai 2013 um 22:31 geschrieben:

[olivier jeannel]

It's not possible that it was so simple.
Arrrrrrrr
Thank's Thomas ! You're my new best friend :D

[Grahame Fuller]

Reinterpret Location does not work well for this case but I seem to be getting good results with UV to Location. See attached pic. (Let me know if you can't see the attachment.) I tried several values and they all seem good.

Now to find a clever way to store and read the subsurface ID.

gray

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, May 15, 2013 03:15 PM
To: soft...@listproc.autodesk.com

Subject: RE: custom ICENode - questions and request for example source code

I think your assumptions are rather off base, Raff.

I'd be interested in seeing how you remap a non-uniform UV coordinate to uniform space in ICE using your brute force technique. I solved this problem for a traditional operator, but I cannot see how using your methods it can be done in ICE. In fact, I don't think ICE exposes enough of the right kind of information to make it possible. But since you said you've done it, I'd like to see how it's done. :)

The problem:

Given a location described as a normalized UV coordinate in non-uniform parameterized space, find the equivalent location on another NURBS surface as a normalized UV coordinate described in uniform parameterized space.

Test case:

Given 2 NURBS grids with 4 isolines (subdivisions) in U and V. Leave the first surface as a flat plane without deformations, create the 2nd surface by duplicating the first surface and deforming the 2nd surface significantly - translate the 2nd surface away from the world origin so you can see what you're doing. On the first surface, get the UV Coordinate for the first interior isoline intersection in U and V (should be roughly 0.25, 0.25). Convert that UV coordinate to uniform parameterized space so it finds the same first interior isoline intersection on the 2nd surface. Do it using only factory ICE nodes.

Actual use case: Repeat the test for arbitrary locations when the surfaces are surface meshes comprised of multiple surfaces (or subsurfaces if you prefer)


The main problem here is it takes waaaaaaay too many nodes to get the job done in a practical manner. We need protection against regressions of nodes that seem to occur from release to release. The last thing I want to deal with is debugging an ICE Tree with 300+ nodes because one node in the bunch now clamps incorrectly, returns NaN, or doesn't handle divide by zero errors correctly (because a bug elsewhere fed it a zero). Finding problems like this in a traditional operator is manageable, but doing so in ICE is torture.


Matt






From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane
Sent: Wednesday, May 15, 2013 3:36 AM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: Re: custom ICENode - questions and request for example source code

If you are using while and repeat nodes to reparametrize the surface, you are paying a ton of unnecessary costs. Yes, those things are slow, no, they are often not required, which is why both me and Ciaran had the same hunch.

Matter of fact, I very recently worked on an equivalent problem, but trickier (think of adding a dimensionality).
By far the fastest approach, although it might seem counter-intuitive, is to search and filter geometry, even if it's A LOT of nearest location runs, they will always be fast and do an excellent job of accessing a shared optimized structure, then it's up to you to filter the arrays in an ICE friendly way (so, no repeats), which again is a puzzling art on its own some times (Stephen's has excellent blog entries about many basics and sorting tricks if you are unfamiliar)

I hear a lot of people complaining about ICE performance, and then frequently enough they treat it like if it was a normal programming language and try to hammer in whiles, repeats, walking to conditions, multidimensional array equivalents and so on, on the assumption that saving nodes is going to make things faster, when in actuality there are other ways, that might seem counter-intuitive, that will blaze by any of those methods.
Most factory nodes even in the hundreds add a negligible overhead, I have complex functions totalling hundreds running faster than the monitor loop can time them, and still topping the vSync with sampling rates in the thousands. Food for thought there.

ICE still sucks at some many to one cases and definitely does at many to many, but a problem like re-parametrizing a surface and getting a correlated coherent transform for a null from is not one of them.

I mean no offense, but it sounds like you haven't spent a lot of time working with ICE, and you are coming from the assumption that your respectable programming knowledge in terms of what's optimal and what isn't might transfer across directly, when chances are it's hurting more than anything.
You have to think laterally a good few degrees of separation from C or JS to ICE in terms of what's optimal, it's often ironically a lot closer to the metal in its SIMD roots than something that gets to scuttle through GCC before running gets to be.

On Wed, May 15, 2013 at 5:42 PM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
well, let's answer the questions first:

1) Does anybody have source code they are willing to share for custom ICE Nodes that deal with topology and/or geometry?

2) Does the lack of reference, location, and execute ports for custom ICE nodes mean I cannot cast a location search from inside an ICE node?



To answer your question:

Imagine two nulls and two NURBS Surfaces. the task is to find the nearest location from the first null to the first surface. At that location, build an orthonormal basis and compute the local transform of the null relative to that basis. Then reconstruct that relationship by applying it to the 2nd null relative to the 2nd surface assuming both surfaces use uniform parameterization, not non-uniform as is the softimage default. Version 2: extend to operate on vertices of polygon meshes instead of nulls. I have a working version, but it is slow and not very stable.

The problem I'm encountering is it simply takes too many factory nodes to be able to work efficiently. Each node has a certain amount of overhead regardless of what it does. Plus, the support for NURBS in ICE is rather abysmal. I have to construct my own orthonormal basis plus implement my own algorithm to convert from non-uniform parameterization to uniform parameterization. Both are doable, but take very many nodes to do it (including support for edge cases) making the whole effort rather clumsy at best. The parameterization conversion is expensive as it involves sorting and searching (while/repeat/counter nodes). When applying the ICE Compound to a polygon mesh with 5,000+ vertices.....it gets the job done, but chugs.

I have a version of this tool written as a scripted operator, and it performs really well because it has better SDK support and the sorting/searching can be better optimized. But one shortcoming of scripted operators is they self-delete if an input goes missing (which often happens on scene load or model import when the content has been modifed externally). This in turn causes content using the operator to malfunction generating bug reports which are sent to artists to fix. Unfortunately most artists weren't around when the content was created years ago, so they have no idea what's wrong, what the expected output is supposed to look like, or how to fix it. Often an asset has to be retired and replaced. This is my motivation for rewriting the tool as a custom ICE node as ICE is much more graceful when it's inputs don't exist - it just turns red and sits patiently until conditions improve. This gives artists a chance to fix the problem without having to sweat the details because they can read the GetData node to see what's missing, then find and repair it. I'm trying to make the content in our pipeline more durable.

So...I'm looking for code samples of how to deal with topology and geometry in ICE. So far I have not found any.


Matt






________________________________

From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>] On Behalf Of Raffaele Fragapane [raffsx...@googlemail.com<mailto:raffsx...@googlemail.com>]

Sent: Tuesday, May 14, 2013 9:00 PM

To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>

Subject: Re: custom ICENode - questions and request for example source code
Yeah, same hunch here.
Unless the performance expectations are in the multiple characters real-time concurrently, in which case I think neither way is gonna get there usually.

On Wed, May 15, 2013 at 1:04 PM, Ciaran Moloney <moloney...@gmail.com<mailto:moloney...@gmail.com>> wrote:
I'm sorta , kinda sure that's a dead end for a custom node. You might be better off optimizing your ICE tree. It doesn't sound like such a complex problem, care to share?

On Wed, May 15, 2013 at 2:41 AM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
I've been looking at the ICE SDK as a start to the process of writing custom ICE Nodes in C++. I need to write topology generators, modifiers and deformation nodes. So far all the source code I've seen supplied with Softimage only deal with particle clouds or primitive data such as converting integers to scalars. Does anybody have source code for working with the Softimage SDK inside an ICE Node to modify topology/geometry?.....or Kinematics? Example: creating a polygon mesh from scratch, adding/removing subcomponents, dealing with clusters, etc... I ask this partly because the ICE SDK docs say to not use the object model....which leads to the question - how do I do anything?

[Thomas Volkmann]

I can't wait to tell my mum that I have a real friend now!! She will be super exited! 

olivier jeannel <olivier...@noos.fr> hat am 15. Mai 2013 um 23:02 geschrieben:

[Grahame Fuller]

Forgot to mention, the ICE tree must be above any deformations or you'll be seeing predeformation values.

gray

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Grahame Fuller
Sent: Wednesday, May 15, 2013 05:05 PM
To: soft...@listproc.autodesk.com
Subject: RE: custom ICENode - questions and request for example source code

Reinterpret Location does not work well for this case but I seem to be getting good results with UV to Location. See attached pic. (Let me know if you can't see the attachment.) I tried several values and they all seem good.

Now to find a clever way to store and read the subsurface ID.

gray

[Ahmidou Lyazidi]

I asked Mohammad, and he gave me the autorisation to share his sources:
https://bitbucket.org/ahmidou_lyazidi/so_cubicbeziercurve

Cheers

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

2013/5/16 Matt Lind <ml...@carbinestudios.com>

[Matt Lind]

What attributes are you setting in your SetData nodes?

 

 

 

 

Matt

 

 

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Grahame Fuller
Sent: Wednesday, May 15, 2013 2:05 PM
To: soft...@listproc.autodesk.com
Subject: RE: custom ICENode - questions and request for example source code

 

Reinterpret Location does not work well for this case but I seem to be getting good results with UV to Location. See attached pic. (Let me know if you can’t see the attachment.) I tried several values and they all seem good.

 

Now to find a clever way to store and read the subsurface ID.

 

gray

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, May 15, 2013 03:15 PM
To: soft...@listproc.autodesk.com
Subject: RE: custom ICENode - questions and request for example source code

 

I think your assumptions are rather off base, Raff.

 

I’d be interested in seeing how you remap a non-uniform UV coordinate to uniform space in ICE using your brute force technique.  I solved this problem for a traditional operator, but I cannot see how using your methods it can be done in ICE.  In fact, I don’t think ICE exposes enough of the right kind of information to make it possible.  But since you said you’ve done it, I’d like to see how it’s done. J

 

The problem:

 

Given a location described as a normalized UV coordinate in non-uniform parameterized space, find the equivalent location on another NURBS surface as a normalized UV coordinate described in uniform parameterized space.

 

Test case:

 

Given 2 NURBS grids with 4 isolines (subdivisions) in U and V.  Leave the first surface as a flat plane without deformations, create the 2^nd surface by duplicating the first surface and deforming the 2^nd surface significantly – translate the 2^nd surface away from the world origin so you can see what you’re doing.  On the first surface, get the UV Coordinate for the first interior isoline intersection in U and V (should be roughly 0.25, 0.25).  Convert that UV coordinate to uniform parameterized space so it finds the same first interior isoline intersection on the 2^nd surface.  Do it using only factory ICE nodes.

From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane [raffsx...@googlemail.com]
Sent: Tuesday, May 14, 2013 9:00 PM
To: soft...@listproc.autodesk.com
Subject: Re: custom ICENode - questions and request for example source code

Yeah, same hunch here.

Unless the performance expectations are in the multiple characters real-time concurrently, in which case I think neither way is gonna get there usually.

On Wed, May 15, 2013 at 1:04 PM, Ciaran Moloney <moloney...@gmail.com> wrote:

I'm sorta , kinda sure that's a dead end for a custom node. You might be better off optimizing your ICE tree. It doesn't sound like such a complex problem, care to share?

 

On Wed, May 15, 2013 at 2:41 AM, Matt Lind <ml...@carbinestudios.com> wrote:

I’ve been looking at the ICE SDK as a start to the process of writing custom ICE Nodes in C++.  I need to write topology generators, modifiers and deformation nodes.  So far all the source code I’ve seen supplied with Softimage only deal with particle clouds or primitive data such as converting integers to scalars.  Does anybody have source code for working with the Softimage SDK inside an ICE Node to modify topology/geometry?.....or Kinematics?   Example:  creating a polygon mesh from scratch, adding/removing subcomponents, dealing with clusters, etc…  I ask this partly because the ICE SDK docs say to not use the object model….which leads to the question – how do I do anything?

 

 

 

 

While also browsing the SDK docs, I saw in the ‘limitations’ section that custom ICE Nodes cannot define reference, location, or execute ports.   Since I am very interested in working with locations, does this mean I cannot do queries for locations from inside the ICE Node?  Or does it only mean I cannot send/receive locations from other ICE nodes?

 

Example:

 

I need to write an ICE Node which takes a polygon mesh and 2 NURBS Surfaces as inputs, and whose output is the deformation of a 2^nd polygon mesh.  To accomplish this feat requires the use of point Locators to map the relationship between the first polygon mesh’s points relative to the first surface, then re-interpret that information to deform the points of the 2^nd polygon mesh in relation to the 2^nd surface.  You can assume the two polygon meshes and two surfaces have identical topology.  I need to write this as a custom ICE node because it is prohibitively expensive to use the factory nodes (too many nodes/workarounds required leading to severe performance degradation).

 

I’d like to be able to do a point locator query from inside the custom ICE node for performance (and convenience) reasons.  Sample code would be a big help.

 

 

Anybody?

 

 

Matt

 

 

--
Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

[Grahame Fuller]

Just temp ones to display the crosshairs in the viewports.

gray

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, May 15, 2013 06:28 PM
To: soft...@listproc.autodesk.com
Subject: RE: custom ICENode - questions and request for example source code

What attributes are you setting in your SetData nodes?




Matt





From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Grahame Fuller
Sent: Wednesday, May 15, 2013 2:05 PM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: RE: custom ICENode - questions and request for example source code

Reinterpret Location does not work well for this case but I seem to be getting good results with UV to Location. See attached pic. (Let me know if you can't see the attachment.) I tried several values and they all seem good.

Now to find a clever way to store and read the subsurface ID.

gray

From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, May 15, 2013 03:15 PM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: RE: custom ICENode - questions and request for example source code

I think your assumptions are rather off base, Raff.

I'd be interested in seeing how you remap a non-uniform UV coordinate to uniform space in ICE using your brute force technique. I solved this problem for a traditional operator, but I cannot see how using your methods it can be done in ICE. In fact, I don't think ICE exposes enough of the right kind of information to make it possible. But since you said you've done it, I'd like to see how it's done. :)

The problem:

Given a location described as a normalized UV coordinate in non-uniform parameterized space, find the equivalent location on another NURBS surface as a normalized UV coordinate described in uniform parameterized space.

Test case:

Given 2 NURBS grids with 4 isolines (subdivisions) in U and V. Leave the first surface as a flat plane without deformations, create the 2nd surface by duplicating the first surface and deforming the 2nd surface significantly - translate the 2nd surface away from the world origin so you can see what you're doing. On the first surface, get the UV Coordinate for the first interior isoline intersection in U and V (should be roughly 0.25, 0.25). Convert that UV coordinate to uniform parameterized space so it finds the same first interior isoline intersection on the 2nd surface. Do it using only factory ICE nodes.

Actual use case: Repeat the test for arbitrary locations when the surfaces are surface meshes comprised of multiple surfaces (or subsurfaces if you prefer)


The main problem here is it takes waaaaaaay too many nodes to get the job done in a practical manner. We need protection against regressions of nodes that seem to occur from release to release. The last thing I want to deal with is debugging an ICE Tree with 300+ nodes because one node in the bunch now clamps incorrectly, returns NaN, or doesn't handle divide by zero errors correctly (because a bug elsewhere fed it a zero). Finding problems like this in a traditional operator is manageable, but doing so in ICE is torture.


Matt






From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [mailto:softimag...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane
Sent: Wednesday, May 15, 2013 3:36 AM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: Re: custom ICENode - questions and request for example source code

If you are using while and repeat nodes to reparametrize the surface, you are paying a ton of unnecessary costs. Yes, those things are slow, no, they are often not required, which is why both me and Ciaran had the same hunch.

Matter of fact, I very recently worked on an equivalent problem, but trickier (think of adding a dimensionality).
By far the fastest approach, although it might seem counter-intuitive, is to search and filter geometry, even if it's A LOT of nearest location runs, they will always be fast and do an excellent job of accessing a shared optimized structure, then it's up to you to filter the arrays in an ICE friendly way (so, no repeats), which again is a puzzling art on its own some times (Stephen's has excellent blog entries about many basics and sorting tricks if you are unfamiliar)

I hear a lot of people complaining about ICE performance, and then frequently enough they treat it like if it was a normal programming language and try to hammer in whiles, repeats, walking to conditions, multidimensional array equivalents and so on, on the assumption that saving nodes is going to make things faster, when in actuality there are other ways, that might seem counter-intuitive, that will blaze by any of those methods.
Most factory nodes even in the hundreds add a negligible overhead, I have complex functions totalling hundreds running faster than the monitor loop can time them, and still topping the vSync with sampling rates in the thousands. Food for thought there.

ICE still sucks at some many to one cases and definitely does at many to many, but a problem like re-parametrizing a surface and getting a correlated coherent transform for a null from is not one of them.

I mean no offense, but it sounds like you haven't spent a lot of time working with ICE, and you are coming from the assumption that your respectable programming knowledge in terms of what's optimal and what isn't might transfer across directly, when chances are it's hurting more than anything.
You have to think laterally a good few degrees of separation from C or JS to ICE in terms of what's optimal, it's often ironically a lot closer to the metal in its SIMD roots than something that gets to scuttle through GCC before running gets to be.

On Wed, May 15, 2013 at 5:42 PM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:
well, let's answer the questions first:

1) Does anybody have source code they are willing to share for custom ICE Nodes that deal with topology and/or geometry?

2) Does the lack of reference, location, and execute ports for custom ICE nodes mean I cannot cast a location search from inside an ICE node?



To answer your question:

Imagine two nulls and two NURBS Surfaces. the task is to find the nearest location from the first null to the first surface. At that location, build an orthonormal basis and compute the local transform of the null relative to that basis. Then reconstruct that relationship by applying it to the 2nd null relative to the 2nd surface assuming both surfaces use uniform parameterization, not non-uniform as is the softimage default. Version 2: extend to operate on vertices of polygon meshes instead of nulls. I have a working version, but it is slow and not very stable.

The problem I'm encountering is it simply takes too many factory nodes to be able to work efficiently. Each node has a certain amount of overhead regardless of what it does. Plus, the support for NURBS in ICE is rather abysmal. I have to construct my own orthonormal basis plus implement my own algorithm to convert from non-uniform parameterization to uniform parameterization. Both are doable, but take very many nodes to do it (including support for edge cases) making the whole effort rather clumsy at best. The parameterization conversion is expensive as it involves sorting and searching (while/repeat/counter nodes). When applying the ICE Compound to a polygon mesh with 5,000+ vertices.....it gets the job done, but chugs.

I have a version of this tool written as a scripted operator, and it performs really well because it has better SDK support and the sorting/searching can be better optimized. But one shortcoming of scripted operators is they self-delete if an input goes missing (which often happens on scene load or model import when the content has been modifed externally). This in turn causes content using the operator to malfunction generating bug reports which are sent to artists to fix. Unfortunately most artists weren't around when the content was created years ago, so they have no idea what's wrong, what the expected output is supposed to look like, or how to fix it. Often an asset has to be retired and replaced. This is my motivation for rewriting the tool as a custom ICE node as ICE is much more graceful when it's inputs don't exist - it just turns red and sits patiently until conditions improve. This gives artists a chance to fix the problem without having to sweat the details because they can read the GetData node to see what's missing, then find and repair it. I'm trying to make the content in our pipeline more durable.

So...I'm looking for code samples of how to deal with topology and geometry in ICE. So far I have not found any.


Matt






________________________________

From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>] On Behalf Of Raffaele Fragapane [raffsx...@googlemail.com<mailto:raffsx...@googlemail.com>]

Sent: Tuesday, May 14, 2013 9:00 PM

To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>

Subject: Re: custom ICENode - questions and request for example source code
Yeah, same hunch here.
Unless the performance expectations are in the multiple characters real-time concurrently, in which case I think neither way is gonna get there usually.

On Wed, May 15, 2013 at 1:04 PM, Ciaran Moloney <moloney...@gmail.com<mailto:moloney...@gmail.com>> wrote:
I'm sorta , kinda sure that's a dead end for a custom node. You might be better off optimizing your ICE tree. It doesn't sound like such a complex problem, care to share?

On Wed, May 15, 2013 at 2:41 AM, Matt Lind <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> wrote:

I've been looking at the ICE SDK as a start to the process of writing custom ICE Nodes in C++. I need to write topology generators, modifiers and deformation nodes. So far all the source code I've seen supplied with Softimage only deal with particle clouds or primitive data such as converting integers to scalars. Does anybody have source code for working with the Softimage SDK inside an ICE Node to modify topology/geometry?.....or Kinematics? Example: creating a polygon mesh from scratch, adding/removing subcomponents, dealing with clusters, etc... I ask this partly because the ICE SDK docs say to not use the object model....which leads to the question - how do I do anything?

[Raffaele Fragapane]

Matt, is the test case you outlined also your use case?

Reparametrization, even outside of ICE, is non-trivial since if you want equidistant you are basically facing a minimization problem, which is where I assume you went for forward walking technique (repeat with bouncing or decreasing increment until a lowest possible U and V Value is found returning a distance withing tolerance of the discrete interval).

I tried that, and it was prohibitively expensive as it involves whiles and repeates that degrage the graph's threading and inflate memory use enormously.

What, to my surprise, I found out the first time I tackled the problem at its lowest dimensionality is that using a ton of get-closest location and a single repeat (and then ridding myself of that in favour of starting from a set of samples ran through a fixed number of iterations hard-wired) had practically no cost compared to that, and threaded more efficiently across all cores at all times.

Get closest location on its own of course will return data you want to filter, especially in areas where there is considerable discontinuity (high rate of change for the first order derivative), but nothing that filtering by a ruleset wouldn't deal with excellently (exclude precedent location > filter in range > filter by lowest U or V to avoid skipping the entire discontinuity and then a further get closest resized and filtered again).

If you literally are limited to cases with only a few control vertices and you can guarantee the discontinuity isn't too brutal (IE: first order derivative between subsequent nodes doesn't change by more than 90 degrees minus iota) the problem is a great deal simpler than if you have many knots and the domain of the surface has practically no boundaries other than those of the function. That's why I was asking about the case.

Playing with the arrays for filtering in a safe and fast way was also key, and that is counter-intuitive compared to how you would deal with arrays in traditional programming, especially performance wise, but possible (again, Stephen and Julian's blogs have many gems).

I would also consider using a very dense poly or point cloud conversion of the nurbs plane with data samples from the surface, if this is an on-off tool, over using the surface itself, but that might or might not be possible.

I still don't know what your performance target is. If it's dozens of frames per second, or 60hz across multiple setups, I'd say you're bettter off dropping this like a dead rat and instantly explore other venues.
If it's a conforming tool used in a session with clear entry and exit points, then the average 15-20hz that is perceived as still smooth when operating a tool is more achievable.

Lastly, you always have the option of dealing with the parametrization in your own OP and writing a transform per discrete element to use in ICE for the rest from there, which is probably the sane thing to do if you have dense surfaces and the problem has an unbound domain. ICE just isn't well suited to dealing with a lot of fringe case handling to scale performance (it does best when dealing with the same operation, no matter how big, run many times as widely as possible instead of at variable depth), whereas in an OP that kind of optimization always works well.

[Matt Lind]

This is ‘a’ use case.  There are many others.

 

I didn’t use the slow approach you describe below.  I resorted to an approximation method which involves a reverse lookup to find the nearest NURBS Samples which surround the location on the surface (via a custom binary search on the NURBS Samples collection), then do a barycentric-like computation between those samples to derive the UV coordinate in uniform parameterized space.  The process is done in reverse to apply the mapped location to the other surface.   This works relatively fast in a scripted operator, but the pitfall is Softimage occasionally returns NaN or undefined when querying the NurbsSamples collection - usually when querying a sample which resides on a boundary edge of the surface, but it’s inconsistent.  I have to implement significant error trapping to prevent the operator from crashing Softimage.

 

Anyway, I cannot use the approximation technique in ICE because ICE does not have the capability to query NurbsSamples in that way.  Even if it could, I would have to implement my own binary search and interpolation methods too.  That is where the bloat and performance degradation comes from when applied to production use case.  This is also a driving reason to write a custom ICE Node as I could cut out the middleman of bloat and cut to the chase.

 

The main reason for pursuing ICE is to improve durability of our content.  Scripted and compiled operators have the pitfall of self-deleting when an input is missing.  In the test case, if one of the nulls goes missing, the operator is deleted automatically and any content relying on that operator is now broken.  Since the operator may contain metadata specific to it’s application, it may not be possible to reconstruct the effect after the fact.  This scenario is very common on scene load or model import when the inputs are referenced models and they have been modified externally.  If such a problem arises using an ICE node, it merely complains, turns red, and waits for the user to resolve the situation.  The system is still intact which gives the artist the opportunity to put things right – often with a face palm followed by getting latest version of the missing asset from source control - which is preferable over the artists marching into my office asking me to run diagnostics to figure out why his scene is broken only for me to have to dig back into previous versions of the scene to recognize the problem and determine what input is missing.

 

 

Matt

 

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane
Sent: Wednesday, May 15, 2013 4:24 PM
To: soft...@listproc.autodesk.com
Subject: Re: custom ICENode - questions and request for example source code

 

Matt, is the test case you outlined also your use case?