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 <[email protected]> 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:* [email protected] [ > [email protected]] On Behalf Of Raffaele Fragapane [ > [email protected]] > *Sent:* Tuesday, May 14, 2013 9:00 PM > *To:* [email protected] > *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 > <[email protected]>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 <[email protected]>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 2ndpolygon >>> 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 2nd polygon mesh in relation to the 2nd 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! > -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
