What attributes are you setting in your SetData nodes?
Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Grahame Fuller Sent: Wednesday, May 15, 2013 2:05 PM To: softimage@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: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Wednesday, May 15, 2013 03:15 PM To: softimage@listproc.autodesk.com<mailto:softimage@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: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane Sent: Wednesday, May 15, 2013 3:36 AM To: softimage@listproc.autodesk.com<mailto:softimage@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: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>] On Behalf Of Raffaele Fragapane [raffsxsil...@googlemail.com<mailto:raffsxsil...@googlemail.com>] Sent: Tuesday, May 14, 2013 9:00 PM To: softimage@listproc.autodesk.com<mailto:softimage@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.cia...@gmail.com<mailto:moloney.cia...@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? 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 2nd 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 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!
