ac_object_get_triangle_surfaces vs ac_object_get_surfacelist

[Thaellin]

Hi,

I'm working on a modification to my boolean plugin and notice that, for some tests, I am getting different results when fetching all triangulated surfaces from an object versus getting all surfaces then iterating them and triangulating as I go.

Example:

List * pObjectSurfaces = ac_object_get_surfacelist( (ACObject *)pSource );
List *pObjectTriangles = ac_object_get_triangle_surfaces((ACObject *)pSource );

List * pSingleSurface = 0;
list_for_each( pObjectSurfaces, pSingleSurface ) {
   List *pTriangulatedSurfaces = surface_get_triangulations( (Surface *)pSingleSurface->data );            

   for ( List *pTriListIterator = pTriangulatedSurfaces; 
          pTriListIterator; 
          pTriListIterator = pTriListIterator->next) 
   {
      // DO "SOMETHING"
   }
   ac_surfacelist_free(&pTriangulatedSurfaces);
}

Now, as presented, I'm triangulating each surface as it comes through. This is causing slightly different results that if I were to use "pObjectTriangles" in place of "pObjectSurfaces". Using the whole object triangulation output causes the correct result - using the per-surface triangulation causes a couple of my test cases to incorrectly classify some surfaces (in/out) later in the logic.

I don't understand why this is happenning, and am pretty much out of ideas. Any information or theories would be welcome.

Thanks,
-- Jeff

[Andy]

Hi Jeff,

Sorry about the delay, the office moving is almost complete now.

ac_object_get_triangle_surfaces uses surface_get_triangulations so I can't only think that there may be non-poly or surfaces with < 3 vertices.
Remember that the triangulation of a surface may fail fail (you get an empty list returned).

ac_object_get_triangle_surfaces looks like this:

Prototype List *ac_object_get_triangle_surfaces(ACObject *ob)  // free with ac_surfacelist_free(&result)
{
List *tri = NULL;
int n = 0;

	for (List *sp = ob->surfacelist; sp != NULL; sp = sp->next, n++)
		{
		Surface *s = (Surface *)sp->data;

		if ((s->numvert < 3) || (s->type != SURFACE_POLYGON) )
			continue;

		if (s->numvert > 3)
			{
			List *slist = (List *)surface_get_triangulations(s);
			list_prepend_list(&tri, slist);			
			}
		else
			{
			Surface *ns = surface_clone(s, ob);
	
			list_add_item_head(&tri, (void *)ns);
			}

		} // end for all surfaces in object

	return(tri);
}

[Thaellin]

Well, I'm afraid I found the difference between our logics. When you get triangulated surfaces from the object the surface listing is in opposite order from the list you get if you just get 'surfaces'.

This seems to indicate that I have an input order dependency in my code, but I can't actually rely on the surfaces coming in in an order that works.

What surprises me is that this hasn't been reported from the field, yet.

Is there any magic behind internally tracked surface listings which has protected me from these problems, or has it just been luck that no-one has reported them?

-- Jeff

[Andy]

The only orders that are retained and are important inside AC3D are the order of the children of an object and the order of the vertices within a surface.

The order of other lists e.g. vertices in an object, surfaces in an object may be altered during editing.

Will copying the above function and altering the list_prepend cure your problem? (note that it may slow down since adding to the start of a list is generally faster)

Andy

[Thaellin]

Hi Andy,

No - altering the function is no good. I think I'll need to revisit my BSP tree building process and ensure that splitting surfaces (when chosen from the actual geometry) meet certain characteristics. This is mostly in place anyway... just figuring out exactly which characteristics I need to look for.

-- Jeff