actc-devel — Discussion about internals and improvement of ACTC

[Actc-devel] Gouranga

[Neateye <nit...@ao...>]

Call out Gouranga be happy!!!
Gouranga Gouranga Gouranga ....
That which brings the highest happiness!!

re: [Actc-devel] Setting a Triangle Angle Tolerance in strip algorith

[Brad G. <gra...@ta...>]

Forwarded message:
> I'm new to this list so first off a BIG HOWDY!!!

I believe yours is is actually the second message ever sent to the list.

> Second off, a HUGE note of thanks to Brad Grantham for his excellent work.

Thanks.

> I was wondering if anyone had put in an angle tolerance to be used when
> determining the next triangle to choose in the strip.  Basicly what I'm
> looking for is a way to set the tolerance to something like 30 degrees

So you basically want to force seams where the difference is large enough?
What kind of data set do you have that would need this?  Some modelers
and modeling languages (e.g. VRML, although calling it a "modeling language"
is giving it a complement) use a "crease angle" to force sharp edges
(i.e. flat shading across an edge) between triangles.  TC is not involved
in any of that.  Per-vertex normals and sharing edges is a result of
triangles sharing vertex indices, which is already done when the data is
passed to TC.

If you really have a triangle set where one triangle is adjacent to two
or more triangles (like the tail of a dart), and you want to choose
the "best" one, then I imagine you and others desiring similar
functionality might be well suited by the following:

	- Associate a value with a triangle (perhaps a void*)

	- Give "GetNextVert" a function which compares the values of two
	  triangles and yields a floating point "suitability number".
	  Something like "typedef float (*valCompareFunc)(void *v1, void *v2);"

	- Have "GetNextVert" run the comparison function between the current
	  triangle and all the candidates, and choose the highest number.

	- For your case, the void* can point to the surface normal and the
	  compare func would, say, find the angle between the normals and
	  return -angle, so the triangle most "flat" compared to the current
	  one is chosen.

This would require some implementation in GetNextVert and in the triangle
structures.

		-Brad
-- 
Brad Grantham, gra...@pl..., http://plunk.org/~grantham/

[Actc-devel] Setting a Triangle Angle Tolerance in strip algorithm

[Steve G. <st...@ge...>]

Hi All,

I'm new to this list so first off a BIG HOWDY!!!

Second off, a HUGE note of thanks to Brad Grantham for his excellent work.

Now to business....

I was wondering if anyone had put in an angle tolerance to be used when
determining the next triangle to choose in the strip.  Basicly what I'm
looking for is a way to set the tolerance to something like 30 degrees and
when the algorithm is searching for the next triangle to output from the
strip it would first look at the angle between the adjacent triangles and
choose the one (if any) that was less then the tolerance.  I realize that
the co-ordinate geometry isn't there for the algorithm to determine it but
what if I where able to pass it in somehow???

Anyway, just looking to see if anyone has done this or pointers on how I'd
go about accomplishing it.

Thanks,

Steve Goyette

[Actc-devel] 1.1 Gold available + what's next?

[Brad G. <gra...@ta...>]

I just uploaded the final 1.1 to sourceforge and plunk.org.  The
main page is still "http://plunk.org/~grantham/public/actc/" and the
sourceforge project page is "http://sourceforge.net/projects/actc/".
All the final really does is update the manual to match the API and
adds a few more manual sections regarding ranges, errors, and file
formats.

I'm soliciting new ideas for the next release.  I'm targeting the end
of February for 1.2-alpha.  Here's my list so far, including ideas
that *might* make the release date but might be dropped, in decreasing
order of combined ease and priority:

    - verify no warnings on 32-bit Linux, 64-bit Linux, 64-bit IRIX out-of-box

    - verify compilation on Win2K, Win98, WinME, release Visual C makefile

    - benchmark against:
        * Meshifier
	* STRIPE
	* David Blythe's optimized Haeberli stripper
	* IRIS Performer's stripper
	* OpenGL Optimizer's stripper
	* NVtristrip 

    - add texture coordinates to tcsample file format

    - release OpenGL viewer that uses tcsample format (used to make images
      on the actc page
        * add texturing
	* D3D version?

    - improve performance to beat some other strippers in performance,
      memory use, and triangles per strip
        * Meshifier
	* STRIPE
	* NVtristrip

    - make MAX_STATIC_VERTS a dynamic parameter settable through actcParam,
      but perhaps not as that quantity

    - add Meshifier-compatible API (almost done) for lazy people

    - option for stitching strips together with degenerate triangles
        * in TC itself or as a post-process?

    - optimize for vertex cache hits (e.g. Radeon, GeForce hardware transform)
        * pass previous N vertices to new function actcOptimizeForCoverage?
	  then ACTC tries to build tristrip hitting those vertices?
	* is screen/texture coherence (to optimize framebuffer/texture
	  cache hits) also important?

    - add a simple multithreading sample program; try to break up dataset
      in simple way into n pieces, run n TCs

    - add prototype vertex hashing API (something like glBegin-glVertex-glEnd
      goes in, and an indexed vertex array comes out)
        * Intention is to solicit feedback, not write a final API

    - try to walk triangle strip backwards (like Meshifier did) to pick up
      more orphaned triangles

    - add quad and polygon primitives so ACTC can make polygon-to-triangle
      decisions on its own if possible (I think this one might be hard
      to integrate into the current code base)

    - add sample marching cubes program outputting in tcsample format

I don't think all of these can be done (I have a day job, as I suspect
the rest of you do) but I think it will be fun to try.  Please let me
know what your priorities are and what you'd like to see first. 
Anyone who wants to help me with these is welcome, but I'd prefer to
know you're working on it so we don't duplicate effort.

		-Brad
-- 
Brad Grantham, gra...@pl..., http://plunk.org/~grantham/