Re: [OctDev] convhulln options.

[Paul K. <pki...@us...>]

On Dec 18, 2003, at 5:05 AM, Pedro Tarrafeta wrote:
>
>> Are these two cases different enough that we need different functions?
>>
>> I think you are going to need an interface layer above the QHull 
>> options
>> so that users can ask for them nicely:
>>
>> [X,Y,Z] = convhulln(cube,'output',{'simplicial','ideal','geomview'})
>>
>> This says that X will contain the simplicial output (as a full 
>> matrix),
>> Y will contain a cell array of facet sizes, and Z will contain a 
>> string
>> used to control geomview.  The default for output must be 'simplicial'
>> for compatibility.
>>
>> That means you will need other options for controlling the QHull
>> algorithm,
>> such as 'qhull','QJ' to feed a raw option string, or if you are 
>> feeling
>> creative, meaningful names for all the options.
>
> I think so.
> In fact. Maybe we should use convhulln for matlab compatibility if 
> this is an
> issue. Some of the important info that I think should be accesible from
> octave is stored in qh struct in qhull. What I mean is:
> 	- A polyhedron is just an ordered list of facets.
> 	- A facet should contain:
> 		- id number
> 		- normals and offset (hyperplane supporting the facet)
> 		- area
> 		- set of vertices (n if simplicial, >n if non-simplicial)
> 		- set of neighbours (again n  if simplicial...). Here's the need for 
> the id.
> 		- set of ridges. (?)

Maybe you want a structure array?

	x(id).normal = <normal>
	x(id).offset = <offset>
	x(id).area = <area>
	x(id).vertices = [v1,...,vn]
	x(id).neighbors = [id1,...,idn]
	x(id).ridges = <?>

My only question is, are there relevant vector operations you want to
do on the returned information?  Or do you need a for loop to process
each id?  Since the octave interpreter is slow, I prefer to avoid for 
loops
as much as possible.

Paul Kienzle
pki...@us...