SDK: Double Edges

Skip to first unread message

André Adam

Nov 29, 2010, 9:32:19 AM11/29/10

a very quick one, are there any built-in means in the SDK to identify
Softimage's -hmm, let's call it- very unique concept of "double edges"?
Except from building a lookup table with edges and their corresponding
vertex indices?

Thanks in advance for any hint! Cheers!


Stephen Davidson

Nov 29, 2010, 10:46:40 AM11/29/10
This is one that has plagued me for years. I fix them manually but have never had a way to "automatically" fix them.
They do appear a blue edges, though (disconnected edges). 
From a strictly UI method...
I zoom into the suspected edge as far as possible.
This shows the two edges separately.
I select the longer edge
subdivide it
and weld the added point to the nearest end.
that's it.

filter points, polygons or edges will not fix the "double edges"


Best Regards,
  Stephen P. Davidson 
       (954) 552-7956

Check My BLOG

My Website is GREEN, Is yours?


Stephen Davidson

Dec 3, 2010, 11:39:07 AM12/3/10
I just stumbled across this in the Softimage Wiki...

"A good way to fix many types of problem is to select all polygons, extract them to a new mesh using one of the Create > Poly. Mesh > Extract Polygons commands, and then freeze the result."

I have not tried this but it sounds good. :)

On Mon, Nov 29, 2010 at 9:32 AM, André Adam <> wrote:


André Adam

Dec 3, 2010, 2:08:53 PM12/3/10
Thanks, but unfortunately not what I'm after. Double edges are a legitimate topology feature in Softimage, therefore built-in tools do not filter this structure. I've wrapped some functionality around the Unfold UV tool a few days ago and need to run a double-edge check on the mesh beforehand since Unfold will simply crash out on double-edges. The problem is that testing for double-edges is dead-slow. An edge has no idea if it is a double-edge or not; this seems to be nowhere marked down on the components level. The only possibility I have found to identify them is to check all edges' vertices against all edges' vertices and see if a given edge comes with the same points as an edge which was previously scanned:

function fFindDoubleEdges(oObj){
  var cDoubles = new ActiveXObject("XSI.Collection");
  var aAllEdgePoints = new Array();
  var eEdges = new Enumerator(oObj.ActivePrimitive.Geometry.Edges);
    var aPoints = eEdges.item().Points.IndexArray.toArray();
    var oNoDouble = true;
    for(var i=0; i<aAllEdgePoints.length; i+=2){
      if(((aPoints[0] == aAllEdgePoints[i]) && (aPoints[1] == aAllEdgePoints[i+1])) || ((aPoints[1] == aAllEdgePoints[i]) && (aPoints[0] == aAllEdgePoints[i+1]))){
        oNoDouble = false;
      aAllEdgePoints.push(aPoints[0], aPoints[1]);
  return cDoubles;


Even with all the shortcuts in place to avoid unnecessary loops, it still is not feasable to run this routine on large meshes. If anyone knows a smarter approach, I'd love to learn about it!



Kai Wolter

Dec 3, 2010, 2:38:57 PM12/3/10
Hi Andre,
Here is another way in pseudo code:

loop over each edge e:
pair = (min(e.vertex1, e.vertex2), max(e.vertex1, e.vertex2))
if pair in dictionary:
found a double edge
add pair to dictionary 

In C++ it works well with map or better hash_map and a std::pair as the key, in python a dictionary and a tuple of integers (as the key) should do the trick, dunno if that'd work in JScript though.


André Adam

Dec 3, 2010, 3:13:20 PM12/3/10
Not sure if this will be a lot faster though I'll be happy to give it a try next week. Looping arrays is pretty fast in JScript and your Python example is doing nothing else internally, though the wrapping looks nicer and more shiny. You are sorting the indices beforehand, I think I like that part, that will certainly help.

But comparing the vertices really and actually *is* the only way to find these silly structures, yes? Oh, if only Unfold would not crash on them, if UnfoldApply() would return something useful (perhaps the op or the prop, anything, really, except from true/false, which is what it does...), if UnfoldSetCut() would accept XSI Collections of edges as input and if we could just pack uv islands of existing texture projections without ever having to Unfold in the first place - then perhaps all of this would be breeze to work with. [Taking a deep breath] Ok, and now back to reality.

And thanks for the hint, will give it a try! Cheers!


Kai Wolter

Dec 3, 2010, 3:29:51 PM12/3/10
Using a map instead of the nested loop should speed it up considerably, but it depends on the language used, of course. The runtime of your version is ranging from O(nm) to O(n*n) - depending on connectivity (m = point count, is rather large so I just included it here). Using a map should yield O(nlogm) and a hash map should take only O(n) time - that is as fast as it can get - given that there is no flag for it hidden in the SDK somewhere :-)

Have a great weekend everybody!

Reply all
Reply to author
0 new messages