Hi Roger

On Tue, 17 Nov 2009, Roger Kaufman wrote:
> I have been working on a slight tweak for bravais and lat_util which
> will allow the radius to be taken directly from the polyhedral container
> specified by -k.
>
> While I was in there, I was changing lattice_grid.cc and noticed I
> hadn't removed color_vef and the "point in plane" functions! These are
> now in the base directory. I would have thought this would have caused a
> compiler error or warning. Maybe it is because the lattice_grid.h does
> have the lines removed.

The color_vef() function has changed so that is okay. I am not
sure why the others don't cause a problem, but it may be because
they are contained in separate libraries.


> I am mentioning this because I will probably keep most modifications I
> make in code until you do the next build. That way if they are modified
> again I will not have to keep sending them. But if you want to take that
> could out it might stop potential problems for you.

I'll take them out here.


> Taking the radius from the OFF file specified by -k is very convenient.
> Then elements can be sized by off_trans. If some element is made unit
> sized by off_trans (in this case, this could be the prime container),
> any subsequent sizing of that element can then just be made by off_trans
> -S to the whole container.
>
> I don't suggest making off_trans overly complex but one case I could see
> using elements as parameters might be to make them unit sized. e.g While
> we can make edges an average of unit size, we can't make a specific one
> unit sized without a few lookups and calculations.

I am thinking of adding in the ability to use values from
individual elements in off_trans, so it shouldn't take much
extra to also add this in.

Adrian.
--
Adrian Rossiter
adrian@...
http://antiprism.com/adrian

Update (in which we find a 'Catch-22'....)
(S'scuse, Adrian, Roger; I'm talking to myself a bit here....)

-- I have a filewriter function which takes a pointer to the start of
'pdb[]' (my points database, the structure of the program's memory where
XYZs are stored).

-- I have a *functionally identical* 'MyDisplay' function with (void) in the
parentheses (takes no arguments).

Both are "above" the main() function (as expected; I have lots of functions
up there, prior to main()).

The compiler has no problem with the filewriter function using pdb inside
itself.
The compiler *does* have a problem with using pdb --exactly the same way--
inside MyDisplay(void).  (The compiler says "pdb" is an undeclared variable
when it sees it in the MyDisplay(void) function, but not when it sees the
same identical thing in the filewriter(*pdb ...) function.  The two function
declarations are right next to each other in the source code.)

Interestingly, if, in my stripped-down testing version of my packer program,
I move the declaration of pdb out of main() (tell you why it's there, below)
and up above the function declarations where all the other declarations and
initializations are, the compiler doesn't complain about pdb being
undeclared within MyDisplay(void), *and* runs the program the way I want
(more or less; there is another bug), displaying all of the points in the
database (pdb) in the glut window.  (IOW, I almost have the OpenGL solved
this way.)

HOWever (here's the catch-22): the rest of the program then doesn't work,
because:
1) pdb is "  double *pdb=new double[pNum*5]  ". (Memory allocation, in other
words.)
2) It is in the main() function because I have to take user input there
(cout<<;cin>>), so creating the memory (pdb is the memory allocation, which
has to be exact) must come *after* the user input, not before, because until
the program gets the user-input number of pionts to pack (pNum), the program
doesn't *know* the value of pNum --which has to be put into the brackets of
double *pdb=new double[pNum*5] .

Therefore the declaration of pdb must come *after* the user inputs pNum, not
before, so I can't put the pdb declaration up in front of everything else
where MyDisplay(void) likes it, and I can't put the pdb declaration where
it's always been (inside main(), after the user inputs pNum), 'cause the
compiler doesn't like to see it being used in MyDisplay (void) before it's
declared 'way up top where it should be.
(Problem arises 'cause I have no *sensible* choice but to use dynamically
allocated memory (with "new").)

(*chuckle*)
Danged if I do, and danged if I don't.

I really really don't want to have to rewrite the entire program in some
other way, just so that OpenGL will work with it: the operation I want to do
is so simple in principle that it shouldn't be necessary to break the
program in order to get it to do it.  I ought to be able to simply stick the
OpenGL write-the-pionts-list-to-screen where it will do that, and leave the
rest of the program alone.

(However, the fact that I can do *either* of these (just not both at once).
and that *something* I do puts all the points into the window where they
belong, and all in one glFlush() shot, implies that I'm gradually focussing
in on the method I'll end up using, so I don't really need help.)

(Tanks for letting me rant....  (*g*))


Peace
jb
web: http://tetrahedraverse.com

Hi Roger

On Tue, 17 Nov 2009, Roger Kaufman wrote:
>> I have included an example program below that uses a C approach.
>
> How would one compile just a standalone program like this? I compiled it
> by putting it into my Makefile but I think there should a command line
> way, or perhaps with a short script.

If Antiprism is built in a directory called anti you can build
a program against it from a neighbouring directory like this

     g++ -W -Wall -o prog prog.cc ../anti/base/.libs/libantiprism.a -lGL -lGLU

Adrian.
--
Adrian Rossiter
adrian@...
http://antiprism.com/adrian

> Hi John

Hi Adrian

> On Mon, 16 Nov 2009, John Brawley wrote:
>> free Visual Express C++ 2008), and don't myself entirely understand what
>> a
>> "callback" is.  (I think it means "call the thing back again after
>> something's been changed)...)
>
> A normal situation is that there is a framework that will
> carry out particular tasks in particular situations. You write
> a function that carries out one of these tasks and let the
> framework know about it. Then, when it is time to perform
> the task the framework comes back to the function in your
> code to carry it out.

Yes I suppose so....  With the OpenGL, the "callback function" seems to be
what "calls back" the operation of redrawing the screen....

>> I thought it would be easy to feed the 'mydisplay' function() --the one
>> with
>> the glVertex3ds in it-- with my point database, in exactly the same
>> manner
> ...
>> access to the database-- into the function.  But when I try to feed the
>> 'mydisplay()' function the same way ( mydisplay(*pdb, ...)  ), all sorts
>> of
>> errors appear.  It *ought* to work, since I can put most anything
>
> The function has to take particular arguments (specified
> by the framework) then you pass just the function name
> with no parenthesis or arguments. When the framework
> calls your function it will supply the arguments.

That's utterly new to me, except for a mention that it's bad practice, in a
forum I saw....
If that's the case, I could save an awful lot of argument-passing through
parenthetical 'doors' all *over* the place in my program....

This problem is that the function needed (by the example I found and got to
work) is
glutDisplayFunc(Mydisplay), where glutDisplayFunc() is not visible (it's one
of the functions in one of the headers, and is used in main()   ).
Mydisplay() is the argument passed to glutDisplayFunc().
But (void)Mydisplay(void) is the written function where the openGL drawing
commands are, so to draw points from my database all at once (write out all
of my pdb[] XYZs, one for each
glVertex3d(x,y,z); , I have to supply MyDisplay() with those (it will take
singles, but rejects ' x=pdb[i]' in a for loop, compiler complaining that
'pdb' is an undeclared variable, which it is not (pdb is declared in global
scope, so should be available to anything of lesser scope).)

(I'm still trying various things; thanks for the unasked input from you; I
was mostly just griping to no one in particular....)

I don't understand about calling a function without its 'front door' (its
parentheses) and without anything sent into its 'front door' (arguments it
needs or wants or could take).  I'll research that.  Coincidentally I ran
across some comment in some forum somewhere that said this very thing
(calling a function by name only with no parentheses and no arguments) was
not a good idea...)

> If you need your database available then you could make
> it globally available and then it will be accesible
> from the callback function.

That's what confuses me.  It *is* globally available: I call it for use,
from within at least eight other functions (mostly filewriters), of  the
form:

double filewriter(*pdb, ... ) {  //iostream stuff before....
for (i=0; i<pNum*5; i+=5) {
x=pdb[i];
y=pdb[i+1];
z=pdb[i+2];
pRad=pdb[i+3];
pCol=pdb[i+4]
     //and then use x,y,and z within the function//
} }

IOW, I explicitly send pdb into the filewriter function with
"filewriter(pdb);")
But that doesn't work inside MyDisplay(), no matter what.
I should be able to go:
glBegin();
for (i=0; i<pNum*5; i+=5) {
a=pdb[i]; b=pdb[i+1]; c=pdb[i+2];   //and then:
glVertex3d(a,b,c);  }
glEnd();
glFlush();
}
..........which ought to let the MyDisplay() function draw *all* the points'
XYZs from the pdb database into the buffer, and then flush them all at once
to the screen...  ...but my (new, finally under control) compiler complains
that 'pdb' is an undeclared variable....
I can get the same thing to work, with *one* glVertex(x,y,z)  and no
reference to pdb, by calling Mydisplay with other global already variables
in it, whose values are those of pdb's XYZs extracted from pdb *outside* of
the MyDisplay() function....
Yet, " glutDisplayFunc(MyDisplay(pdb)) also makes no sense to the
compiler....  It wants to see "glutDisplayFunc(MyDisplay);" with no
arguments passed.  ( <---This is what you mean by 'no parentheses or
arguments' ?)

"It's a puzzlement."

I'll get it; thanks again for comments, but don't let *my* amateurish coding
problems take time away from anything you're doing.  I learn best by beating
my way through the bushes with my own machete anyway.... (*g*)
I'm far from having tried everything it's possible to try.


Peace
jb
web: http://tetrahedraverse.com

Hi John

On Mon, 16 Nov 2009, John Brawley wrote:
> free Visual Express C++ 2008), and don't myself entirely understand what a
> "callback" is.  (I think it means "call the thing back again after
> something's been changed)...)

A normal situation is that there is a framework that will
carry out particular tasks in particular situations. You write
a function that carries out one of these tasks and let the
framework know about it. Then, when it is time to perform
the task the framework comes back to the function in your
code to carry it out.


> I thought it would be easy to feed the 'mydisplay' function() --the one with
> the glVertex3ds in it-- with my point database, in exactly the same manner
...
> access to the database-- into the function.  But when I try to feed the
> 'mydisplay()' function the same way ( mydisplay(*pdb, ...)  ), all sorts of
> errors appear.  It *ought* to work, since I can put most anything

The function has to take particular arguments (specified
by the framework) then you pass just the function name
with no parenthesis or arguments. When the framework
calls your function it will suppy the arguments.

If you need your database available then you could make
it globally available and then it will be accesible
from the callback function.

Adrian.
--
Adrian Rossiter
adrian@...
http://antiprism.com/adrian

Hi Adrian,

I have been working on a slight tweak for bravais and lat_util which will allow
the radius to be taken directly from the polyhedral container specified by -k.

While I was in there, I was changing lattice_grid.cc and noticed I hadn't
removed color_vef and the "point in plane" functions! These are now in the base
directory. I would have thought this would have caused a compiler error or
warning. Maybe it is because the lattice_grid.h does have the lines removed.

I am mentioning this because I will probably keep most modifications I make in
code until you do the next build. That way if they are modified again I will not
have to keep sending them. But if you want to take that could out it might stop
potential problems for you.

Taking the radius from the OFF file specified by -k is very convenient. Then
elements can be sized by off_trans. If some element is made unit sized by
off_trans (in this case, this could be the prime container), any subsequent
sizing of that element can then just be made by off_trans -S to the whole
container.

I don't suggest making off_trans overly complex but one case I could see using
elements as parameters might be to make them unit sized. e.g While we can make
edges an average of unit size, we can't make a specific one unit sized without a
few lookups and calculations.

Roger

Hi Adrian,

> The symmetry code currently fails when the vertices don't
> have a a three dimensional convex hull. I need to add
> handling for this.

I the "do_convex_hull" I could only test if there were less than 4 points. But
that is enough in most cases. Occasionally I will get a polygon, but it only
causes warning text to the screen.

Roger

Hi Adrian,

> > class, but this means that the sort_merge class has to know about the
> > callback function(s) before hand.
>
> I have included an example program below that uses a C
> approach.

How would one compile just a standalone program like this? I compiled it by
putting it into my Makefile but I think there should a command line way, or
perhaps with a short script.

I see what it is now. The callback function would work as long as it had the
expected parameter list.


> I changed the generation of the HTML documentation to add the
> program help directly as preformatted text. That means that any
> changes are included automatically.

This is good because any time a feature is added or altered, it almost always
involves the helps.

Roger

Hi Roger

On Sun, 15 Nov 2009, Roger Kaufman wrote:
> This is fairly trivial but I found a case where off_color can crash when
> using symmetry color. Here are a couple of examples.
>
> echo -e "OFF\n1 0 0\n0 0 0\n" | off_color -e S | antiview

The symmetry code currently fails when the vertices don't
have a a three dimensional convex hull. I need to add
handling for this.

I think I mentioned before that for finding symmetry alignments
I probably need to be able to work with non-finite symmetry types,
as would occur in your example above. In which case, these could
also be added in for symmetry reports and for display in Antiview.

Adrian.
--
Adrian Rossiter
adrian@...
http://antiprism.com/adrian

Hi Roger

On Sun, 15 Nov 2009, Roger Kaufman wrote:
>>     geom_if::merge(merge_elems, eps, blend_callback);
>
> I see the merits of having a callback function, and I don't have a
> problem setting a pointer to a function. The problem comes in with the
> variables of the that function. (I have no experience in callback style
> coding, other than using callbacks already written for e.g. GUI
> building!) The function variables could all be set as members of the
> class, but this means that the sort_merge class has to know about the
> callback function(s) before hand.

I have included an example program below that uses a C
approach.

I imagine you would include the most useful blend functions
in the library, but a custom program could define its own and
pass the function pointer to the library blending control function
and it would be used for the blend in exactly the same way.


>> I updated the development tools by building a recent GCC,
>> which took 30 hours! Unfortunately, I couldn't build Antiprism
>> with it as the OpenGL headers were incompatible (which
>
> Whoa! You need another decent computer! I was looking around for sites
> such that they have reused computers or laptops available, there might
> be some hope there. But then again they probably wouldn't be very
> powerful.
>
> Perhaps there might be a laptop on Ebay or something.

I did think about whether I might get something second hand,
but it should only be for two or three months so I decided to
make do with the old machine for now.

I managed to change the system OpenGL headers and Antiprism
builds with the modern GCC now, so that is something.


>> will feel a lot happier about adding new material knowing that
>> I won't have to go through and reformat it or mark it up
>> differently later.
>
> I have been wondering how you can keep up with the documentation. I
> sometimes feel guilty that I am updaing the helps too fast for you to
> keep up.

I changed the generation of the HTML documentation to add the
program help directly as preformatted text. That means that any
changes are included automatically.

I don't distribute the documentation sources but they are
included in the Sourceforge Git repository. I added a make rule
called prepare_release. This builds the program documentation
and also the library documentation. I run this before I make a
snapshot and it updates all the documentation.

Adrian.
--
Adrian Rossiter
adrian@...
http://antiprism.com/adrian


#include "../anti/base/antiprism.h"

#include <stdio.h>

typedef col_val (*ptr_blend_func)(const vector<col_val> &);

col_val blend_cols_first_col(const vector<col_val> &cols)
{
     return (cols.size()>0) ? cols[0] : col_val();
}

col_val blend_cols_last_col(const vector<col_val> &cols)
{
     return (cols.size()>0) ? cols.back() : col_val();
}


void get_cols_and_blend(ptr_blend_func blend_func)
{
     //find some colours
     vector<col_val> cols;
     cols.push_back(col_val(1.0,0.0,0.0));
     cols.push_back(col_val(0.0,1.0,0.0));
     cols.push_back(col_val(0.0,0.0,1.0));

     //blend them with the supplied blend function
     col_val col = blend_func(cols);
     if(col.is_val())
        printf("blended colour is (%d, %d, %d)\n", col[0], col[1], col[2]);
}

int main()
{
     ptr_blend_func p_func;

     printf("blend_cols_first_col\n");
     p_func = blend_cols_first_col;
     get_cols_and_blend(p_func);

     printf("blend_cols_last_col\n");
     p_func = blend_cols_last_col;
     get_cols_and_blend(p_func);

     return 0;
}

Adrian and Roger,

Just found this....a way to number the 230 crystal classes
from a J. D. Bernal in 1923.  Long paper...but look after page 113
in particular.  Just food for thought.

download the pdf...here

http://www.iucr.org/education/teaching-resources/bernal-essay

steve

From: "Roger Kaufman" <vortexswirling@...>

Hi Roger, Adrian
(Commenting; not expecting return ("callback") comment...)

>> For the blending a callback approach would give a lot
>> of flexibility. The function could look like
>>     geom_if::merge(merge_elems, eps, blend_callback);
>
> I see the merits of having a callback function, and I don't have a problem
> setting a pointer to a function. The problem comes in with the variables
> of the that function. (I have no experience in callback style coding,
> other than using callbacks already written for e.g. GUI building!) The
> function variables could all be set as members of the class, but this
> means that the sort_merge class has to know about the callback function(s)
> before hand.

I'm still fighting with OpenGL (fixed the glut.h hatred by moving to the now
free Visual Express C++ 2008), and don't myself entirely understand what a
"callback" is.  (I think it means "call the thing back again after
something's been changed)...)

I thought it would be easy to feed the 'mydisplay' function() --the one with
the glVertex3ds in it-- with my point database, in exactly the same manner
as I feed my filewriters with the database: filewriter(*pdb, ...);  where
'pdb' is the database, and call the filewriter from any point in the program
with filewriter(pdb);  .  This works to feed the database --or, rather,
access to the database-- into the function.  But when I try to feed the
'mydisplay()' function the same way ( mydisplay(*pdb, ...)  ), all sorts of
errors appear.  It *ought* to work, since I can put most anything
*directly*inside* the 'mydisplay()' function (for example write a
random-number operation *inside* the function, which gives me changing
displays).  But for some reason I can't yet fathom, I can't put something
into the 'mydisplay' function through the function's "front door" (the
parentheses ( )  ).

I've just finished stripping everything but the absolutely-necessary from a
version of my program, and am about to try turning the *whole*program* into
"an OpenGL program", and see if that makes any difference.  I have no real
choice but to be able to read-out the points database (each point's XYZs)
all at once, to draw the points into the OpenGL display window and then
flush() it to the screen.  The only other choice is to call the
'mydisplay()' function once for *each*point*, which would be ridiculously
video-card intensive.

(Ignore; just griping, triggered by your mention of "callbacks" and how your
issue *seems* similar to my own troubles thereabouts....)
(*g*)


Peace
jb
web: http://tetrahedraverse.com

Roger,

> > is this possible ?
> >
> > take a lattice that MUST enclose a given convex hull and get a point set by
removing those points exterior to that hull ?
> > then we just always make that convex hull of that new point set.
> > I have  other coding troubles still.  I cannot get a lattice of spheres with
a transparent rd container...and cannot really tell what I am doing. So, i
cannot test anything really, since i cannot see any interior spheres nor the
lattice. A working line of code would aid tremendously. A transparent edge 1 rd
in some lattice...

> I think this is what you want. If not let me know.

Yes sir....exactly.

> You may want the container displayed transparently over the product. In that
case we must pass that through off_color. Here is the unit edge rd in
transparent yellow. -r A0.5 is half transparent. Valid values are 0 to 1.

Yes.  (i think the documentation has -T at 0-256...and should be removed then.)



> pol_recip cuboctahedron | off_trans -S 1.0886621079036354650642525108502 |
off_color -f yellow -r A0.5 > rd_unit_edge.off
>
> Then take a scoop of (I will use) sc. -C c makes just the convex hull. Right
now you have to control the rd with the radius using -r. Basically this means
that right now, the rd can be any size to begin with and it is scaled by -r in
bravais. -O is needed so that the final product of the lattice will be aligned
with container. This is only if you are going to display them together.
>
> bravais sc -g 10 -k rd_unit_edge.off -r 1.1547005383792519 -C c -O > scoop.off
>
> antiview scoop.off rd_unit_edge.off
>
> Actually this is a nice model.

Indeed...i like this a lot too.

>
> It will be sometime this week before I can make and test the new option so you
can control the size of the container with off_trans -S

i have some stuff to work with now...thanks. i believe that like series can be
obtained akin to packed spheres using "their" radial parameter.

  what would be cool...is if we could add an integer to -k signifying the edge
sqrt MULTIPLIER value ( of a unit edged rd in this case) to be used.  i am
concerned too, about keeping the lattice large enough to handle larger -k
integer values. I thank you for your help in this.  My mental algorithm is still
a bit fuzzy; as before, the point set WAS derived from the radius. Now the
radius, as I see it, is not really required - though it may be useful.

The parameters are inherent to the inputted convex hull scooper. I am trying to
manifest different v,f,e based/controlled/sqrtted/incremented unlimited series
per scooper shape in bravais.  I see larger scoops  as becoming more rd-like the
higher the sqrt value....just as packing spheres makes a more approximate sphere
at high values.

steve

Hi Steve,

> is this possible ?
>
> take a lattice that MUST enclose a given convex hull and get a point set by
removing those points exterior to that hull ?
>
> then we just always make that convex hull of that new point set.
>
> I have  other coding troubles still.  I cannot get a lattice of spheres with a
transparent rd container...and cannot really tell what I am doing. So, i cannot
test anything really, since i cannot see any interior spheres nor the lattice. A
working line of code would aid tremendously. A transparent edge 1 rd in some
lattice...

I think this is what you want. If not let me know.

You may want the container displayed transparently over the product. In that
case we must pass that through off_color. Here is the unit edge rd in
transparent yellow. -r A0.5 is half transparent. Valid values are 0 to 1.

pol_recip cuboctahedron | off_trans -S 1.0886621079036354650642525108502 |
off_color -f yellow -r A0.5 > rd_unit_edge.off

Then take a scoop of (I will use) sc. -C c makes just the convex hull. Right now
you have to control the rd with the radius using -r. Basically this means that
right now, the rd can be any size to begin with and it is scaled by -r in
bravais. -O is needed so that the final product of the lattice will be aligned
with container. This is only if you are going to display them together.

bravais sc -g 10 -k rd_unit_edge.off -r 1.1547005383792519 -C c -O > scoop.off

antiview scoop.off rd_unit_edge.off

Actually this is a nice model.

It will be sometime this week before I can make and test the new option so you
can control the size of the container with off_trans -S

Roger

Roger,

is this possible ?

take a lattice that MUST enclose a given convex hull and get a point set by
removing those points exterior to that hull ?

then we just always make that convex hull of that new point set.

I have  other coding troubles still.  I cannot get a lattice of spheres with a
transparent rd container...and cannot really tell what I am doing. So, i cannot
test anything really, since i cannot see any interior spheres nor the lattice. A
working line of code would aid tremendously. A transparent edge 1 rd in some
lattice...

steve



--- In antiprism@yahoogroups.com, "Roger Kaufman" <vortexswirling@...> wrote:
>
> Hi Steve,
>
> >gonna make allow an -r for the lattice AND an -r k option for the >container
?
> >
> > say I want an fcc -r 10,2 with a rd container of unit edge ?
>
> To make an rd of unit edge would be done this way.
>
> pol_recip cuboctahedron | off_trans -S 1.0886621079036354650642525108502 >
rd_unit_edge.off
>
> off_report -C E rd_unit_edge.off
> [edge_lengths_cnts]
> 0.99999999999999989 = 24
>
> -r k would tell bravais to use -K rd_unit_edge.off as is. There would be no
scaling of the container.
>
> -r 10,2 would say scale the container to a radius of sqrt(10) instead of
keeping it as 1.1547005383792519 as it is with a unit edged rd.
>
> off_report -S D rd_unit_edge.off
> [distances]
> given_center = (0 0 0)
> vert_min = 0.99999999999999978 (11)
> vert_max = 1.1547005383792519 (1)
> ...
>
> > All that will happen is either some radii will be duplicated or some skipped
depending on how the size corresponds to the lattice points that are swept.
> >
> > i am unsure about this...and need to do some testing.
>
> All that is happening by increasing the model based on edge length size is
that a different progression of radii. For instance as in the last example,
instead of setting radii by sqrt(1),sqrt(2),sqrt(3)... if the edges are
increased by 1,2,3... then the radius is be set at
sqrt(4/3),sqrt(8/3),sqrt(12/3)...
>
> > The documentation says -K not -k
>
> It is -k now.
>
> > -C a in bravais to work either.
>
> Now use -A to include the original lattice.
>
> Roger
>

Hi Steve,

>gonna make allow an -r for the lattice AND an -r k option for the >container ?
>
> say I want an fcc -r 10,2 with a rd container of unit edge ?

To make an rd of unit edge would be done this way.

pol_recip cuboctahedron | off_trans -S 1.0886621079036354650642525108502 >
rd_unit_edge.off

off_report -C E rd_unit_edge.off
[edge_lengths_cnts]
0.99999999999999989 = 24

-r k would tell bravais to use -K rd_unit_edge.off as is. There would be no
scaling of the container.

-r 10,2 would say scale the container to a radius of sqrt(10) instead of keeping
it as 1.1547005383792519 as it is with a unit edged rd.

off_report -S D rd_unit_edge.off
[distances]
given_center = (0 0 0)
vert_min = 0.99999999999999978 (11)
vert_max = 1.1547005383792519 (1)
...

> All that will happen is either some radii will be duplicated or some skipped
depending on how the size corresponds to the lattice points that are swept.
>
> i am unsure about this...and need to do some testing.

All that is happening by increasing the model based on edge length size is that
a different progression of radii. For instance as in the last example, instead
of setting radii by sqrt(1),sqrt(2),sqrt(3)... if the edges are increased by
1,2,3... then the radius is be set at sqrt(4/3),sqrt(8/3),sqrt(12/3)...

> The documentation says -K not -k

It is -k now.

> -C a in bravais to work either.

Now use -A to include the original lattice.

Roger

roger,

I appreciate your feedback into this.

(dels)

> OK, great. But the problem again is that if we want a container this size in
bravais or lat_util, it has to be sized by the -r parameter so we have to know
the pesky radius. We think in terms of radius because we are thinking in terms
of radial sweeps, emphasis on radial.
>
> In order to make this easier I will just add "-r k" which will mean take the
radius from the container as is. Then one can control them by element sizes
easer with off trans and use them for containers in bravais and lat_util.

i am confused.  i will want to have an -r for the lattice. Are you gonna make
allow an -r for the lattice AND an -r k option for the container ?

say I want an fcc -r 10,2 with a rd container of unit edge ?


> But I don't think that this will lead to anything new.

i do...but am having troubles trying to manifest any new series.

  All that is happening is that the size of the container is being controled in
other ways. There are still a progression of radial sweeps.

That should be okay.

All that will happen is either some radii will be duplicated or some skipped
depending on how the size corresponds to the lattice points that are swept.

i am unsure about this...and need to do some testing.

The documentation says -K not -k...and i cannot get either -T nor
-C a in bravais to work either.

I quite like the idea to scale down the container to "unit" value.

steve

Hi Steve,

> r = sqrt of 4n/3 ...then for this rd sequence.

This one would have two edge lengths.

bravais fcc -g 10 -r 18,2 -c s -C c | off_color -e S > container.off
antiview container.off

off_report -C E container.off

[edge_lengths_cnts]
2 = 24
2.4494897427831774 = 48

The edges are lenght 2 and sqrt(6).

If one wanted to make a sequence based on progressive edge lengths of the longer
edges, it could be done this way.

First scale the container by 1/sqrt(6). This makes these edges 1.

off_trans -S 0.40824829046386301636621401245098 container.off > container2.off

off_report -C E container2.off

[edge_lengths_cnts]
0.81649658092772759 = 24
1 = 48

Now at this point container2.off is prime for scaling by any value to
increase/decrease the unit edges accordingly. The whole model will
increase/decrease by the same proportion, as in any bubble. e.g. the radius
can't increase faster than the surface without explosive catastrophy, but this
is common sence!

So for instance to get a container where those edges are the sqrt(2) simply have

off_trans -S sqrt2 container2.off > container3.off

off_report -C E container3.off

[edge_lengths_cnts]
1.1547005383792532 = 24
1.4142135623730956 = 48

or by the sqrt(5)

off_trans -S sqrt5 container2.off > container3.off

off_report -C E container3.off

[edge_lengths_cnts]
1.8257418583505594 = 24
2.2360679774997902 = 48

Likewise we could do this with a face center. e.g. find the face center of one
of the hexagons (I chose face 32).

off_query Fd -I 32 container.off

32,20.784609690826525

Then to start with a unit distance to that face center we need to make
container2 be of scale 1/20.784...

off_trans -S 0.048112522432468819547821093046623 container.off > container2.off

To see this worked

off_report -S D container2.off

and see container2 has a face max distance of 1. Then that distance can be
scaled as simply as using off_trans -S as before.


OK, great. But the problem again is that if we want a container this size in
bravais or lat_util, it has to be sized by the -r parameter so we have to know
the pesky radius. We think in terms of radius because we are thinking in terms
of radial sweeps, emphasis on radial.

In order to make this easier I will just add "-r k" which will mean take the
radius from the container as is. Then one can control them by element sizes
easer with off trans and use them for containers in bravais and lat_util.

But I don't think that this will lead to anything new. All that is happening is
that the size of the container is being controled in other ways. There are still
a progression of radial sweeps. All that will happen is either some radii will
be duplicated or some skipped depending on how the size corresponds to the
lattice points that are swept.

Roger

Hi Adrian,

This is fairly trivial but I found a case where off_color can crash when using
symmetry color. Here are a couple of examples.

echo -e "OFF\n1 0 0\n0 0 0\n" | off_color -e S | antiview

echo -e "OFF\n2 0 0\n0 0 0\n1 1 1\n" | off_color -v S | antiview

The way I found this is that I had output from bravias that only had one vertex
in it. That is when such a call might occur. Symmetry coloring would make no
sence and the result could be sent right to output.

Roger

Hi Adrian,

> As another approach, maybe it just needs a function
> added to geom_if, which can then call the current
> function (with any blending parameters you add) e.g.
>
>     geom_if::merge(merge_elems, eps);

This is another possibility. It will be a little time before I am ready to
experiment.

> For the blending a callback approach would give a lot
> of flexibility. The function could look like
>
>     geom_if::merge(merge_elems, eps, blend_callback);

I see the merits of having a callback function, and I don't have a problem
setting a pointer to a function. The problem comes in with the variables of the
that function. (I have no experience in callback style coding, other than using
callbacks already written for e.g. GUI building!) The function variables could
all be set as members of the class, but this means that the sort_merge class has
to know about the callback function(s) before hand.

> blend_callback could default to RGB (presumably applied
> only if 'f' is specified). A null pointer could turn off
> blending.

Any element type can be blended. I am, so far, presuming all the blending would
occur the same way for all elements specified in elems. If not, the calling gets
a bit complex. Instead call blending for one element, and another blending for
the next. e.g blend for edges, then faces if those blending methods are wanted
to be different.

> If you mean that your code should filter out multiple edges
> between two vertices then that is probably a good idea for
> now, as it means that if the current geometry is written out
> and then read back in and procesed it gives the same result.

The only reason there were duplicate explicit edges is because I printed out the
result to the screen. Had the data been read into anything else they would have
been reduced to one.

In fact in order to blend edge colors it had to be two or more models merged
with off_util -M e as the first thing that happens. But that alone is useful.

> > This should add some unique functioning to Antiprism. My schedule is so
> > tight lately that it could take some time to develop. However, instead

> Sounds good, but if you want to add in functionality
> bit by bit as you get it going then that is good too.

Going forward it will probably be that. I am not sure I will get the time to
work on something as grand as the n_icons program for a while. But I find coding
recreational and will continue to work on it as time permits.

I have a bit of daily commute now that is taking up quite a bit of time I used
to be able to relax at the screen. I rather miss the old schedule!

> I updated the development tools by building a recent GCC,
> which took 30 hours! Unfortunately, I couldn't build Antiprism
> with it as the OpenGL headers were incompatible (which

Whoa! You need another decent computer! I was looking around for sites such that
they have reused computers or laptops available, there might be some hope there.
But then again they probably wouldn't be very powerful.

Perhaps there might be a laptop on Ebay or something.

> will feel a lot happier about adding new material knowing that
> I won't have to go through and reformat it or mark it up
> differently later.

I have been wondering how you can keep up with the documentation. I sometimes
feel guilty that I am updaing the helps too fast for you to keep up.

Roger

Roger,

For the rd the sequence will be
edge sqrtN radius sequence
1 1.1547...
2 1.6329...
3 2
4 2.3094...
and so on. You have to know the progression of the radius which is probably a
forumla I don't have time to figure. But that is the point, and why you have a
beef about the way it works. You have to figure out what to plug into -r to get
the edge lengths (or various other lengths) that you want.


r = sqrt of 4n/3 ...then for this rd sequence.

steve

Hi Steve,

I don't have much time but will try to explain.

> r But bravais then resizes the container based on -r so you lose that control.
>
> sw Why ?
> Let's start with an edge one rd.  I want to make a series then,
> of containers for rd of edge sqrt1,sqrt2,sqrt3...
> now, i do not care if the NEW container is NOT integer friendly, as those
points WITHIN will be.

Say you want rds in that sequence. These can be created with the command

pol_recip cubo | off_trans -s e -S sqrt1 | antiview

and so forth.

If you use the size of the rd as a container, the only way to control it
presently is with the radius -r x. There are corresponding radii for each edge
length. This is vert_max and can be seen by

pol_recip cubo | off_trans -s e -S sqrt1 | off_report -S D

For the rd the sequence will be

edge sqrtN  radius sequence
1           1.1547...
2           1.6329...
3           2
4           2.3094...

and so on. You have to know the progression of the radius which is probably a
forumla I don't have time to figure. But that is the point, and why you have a
beef about the way it works. You have to figure out what to plug into -r to get
the edge lengths (or various other lengths) that you want.

And this is a tame one. When there are several different edge lengths, face
types, etc, it becomes way difficult to know what the radius sequence is.

> sw Do not need the radius, necessarily.

Actually because radius is the only thing to work with it is the only thing you
can use.

Then it would internally find vert_max. Then you could manipulate the container
all you wanted and bravais would use it as is.
>
> sw Why not via the edge parameter ?

because I don't want to do it that way.

that way, only you then have to be very careful the container doesn't miss the
lattice!
>
> sw WHY ?  So what if it misses the lattice ?

Because if the container misses the lattice you get an empty geometry. Of course
if that is what you expect, great. Otherwise it seems like a program error.

>edges now all the sqrt of the inputted value.  Would you be up to this "e"
feature programming request ( or others as above ) for the bravais -k ?

So no I am not up to it.

However, it is not impossible to do what you are asking with what exists, it is
just that you have to figure out how the sequence of element sizes corresponds
to the radius of the polyhedra. This is probably almost always a formula of some
kind. Perhaps the radius sequence can be found via a spreadsheet.

Roger

Hi Roger

On Fri, 13 Nov 2009, Roger Kaufman wrote:
>>> = face(2), does face(3) = face(4)... Also then, if any element list size
>>> is odd then pairing cannot be the case? (An orient geom would have to be
>>> done after this).
>>
>> Those checks would work (I am not sure about orienting afterwards
>> as the geometry can be discarded after the check.) The original
>> index numbers need to accessible at the time of the check though
>> as they will be stored in the equivalent elements list.
>
> What actually does this do? How would I test I didn't break it.

The equivalent elements are the sets of orbits of elements.
These are used for colouring by symmetry, so you could check
visually that the colouring by symmetry still works.


> If sort_merge were a class, the actual sort merge would then be called
> as this
>
> sm.sort_merge_elems(geom, merge_elems, eps, equiv_elems);
>
> In the case of equiv_elems it might be
>
> vector<map<int, set<int> > > orig_equivs;
> sm.set_equiv_elems(&orig_equivs);
> sm.sort_merge_elems(geom, merge_elems, eps, equiv_elems);
>
> I think the interface for check_congruence I would leave be and not make part
of the class, but inside it would use the class.

There is some freedom. You could hold merge_elems and eps
as class members.

The congruence check needs eps and equiv_elems, so the only
overlap is eps, and it could be a completely unrelated to the
sort_merge class from an external perspective.

As another approach, maybe it just needs a function
added to geom_if, which can then call the current
function (with any blending parameters you add) e.g.

     geom_if::merge(merge_elems, eps);

of if you use a class it could be

     geom_if::merge(sm);


> I see setting the color function as
>
> sm.set_blending_type(1) ;0 would be the default and be RGB
> sm.sort_merge_elems(geom, merge_elems, eps, equiv_elems);
>
> The color blending function would not be set as a callback, but would
> use the blending type parameter.

For the blending a callback approach would give a lot
of flexibility. The function could look like

     geom_if::merge(merge_elems, eps, blend_callback);

blend_callback could default to RGB (presumably applied
only if 'f' is specified). A null pointer could turn off
blending.

With the callback it would be easy to supply custom blending.
For example, to use the first colour of the blend list, or a
constant colour for overlaps, or to colour according to
the number of times a region is overlapped, etc.


>> The way things currently work there is only supposed to be one
>> edge in the edge list that joins two vertices. This is enforced
>> by geom::add_edge, which is called when reading an off_file
>> (although this should be changed for efficiency) and so
>> applies to all the programs that accept OFF input e.g.
>>
>>     echo -e "OFF\n2 2 0\n0 0 0\n1 1 1\n2 1 0\n2 0 1\n"
>>     echo -e "OFF\n2 2 0\n0 0 0\n1 1 1\n2 1 0\n2 0 1\n" | off_util
>
> The interesting thing here is that sort_merge takes an 'e'! Then that
> means that duplicate edges might be expected to occur, but in the end
> they are not used. (antiview appears to use the last one encountered).

There aren't supposed to be multiple edges between two vertices
in the input but you might have coincident edges which have
different vertices. These wouldn't be stripped on reading so
sort_merge would deal with those.


> I am going to let the code above in and make reducing edges explicit.
> Color blending of edges is valid and a sort_merge would be the way to do
> that.

If you mean that your code should filter out multiple edges
between two vertices then that is probably a good idea for
now, as it means that if the current geometry is written out
and then read back in and procesed it gives the same result.


> This should add some unique functioning to Antiprism. My schedule is so
> tight lately that it could take some time to develop. However, instead
> of thinking of it a race I am hoping to be able to add value to
> Antiprism for some time to come.

Sounds good, but if you want to add in functionality
bit by bit as you get it going then that is good too.

I am very limited in what I can do at the moment as well.
I don't have much access to the computer I normally use,
and this will probably be the case until the new year.

I dug out my old desktop machine last week but I don't
think I will be able to use it much for development. It is
a PIII-450Hz, but it only has 96Mb of memory. Also, its
operating system is out of date so I can't get binaries for
it and when I build a package I generally have to build all
the package dependencies too.

I updated the development tools by building a recent GCC,
which took 30 hours! Unfortunately, I couldn't build Antiprism
with it as the OpenGL headers were incompatible (which
appears to be a bug in the headers.) I can build Antiprism
with the older supplied GCC, but it takes a long time. I
can't enable "long long" for g++ (this also appears to be
a bug) and so I can't build waterman. It also errored on
the missing include for ctype.h when using isspace and
tolower. I will add the includes in and I should really add
in the check for "long long" to build waterman.

As development isn't going to be much fun I might devote
some time to the manual and documentation instead. I have
been looking at DocBook XML and I think I can use this (with
some other XML) to produce a single source that I can use to
generate standalone documentation, online documentation,
website pages and program help. If I can get this set up I
will feel a lot happier about adding new material knowing that
I won't have to go through and reformat it or mark it up
differently later.

Adrian
--
Adrian Rossiter
adrian@...
http://antiprism.com/adrian

Roger,

r I hope all this work wasn't useless!

sw It is good that you have gotten Antiprism to employ other containers  and
useful. I spoke improperly. It was not what i was going for completely here.  i
believe that some flexibilty/options could be ever so useful...for the singular
container that now os applied.

  Let's take the VE as a container for example...

r What is the VE?

sw Sorry...the Vector Equilibrium aka cuboctahedron aka w1 aka fcc 1.
[ Fuller's naming ]

> > Currently, the -k option does not tap into this huge potential...
> >
> > I should think that one could always use sqrt integer value to discern
v,f,or e elements to generate difference unlimited series.

r > The main problem is that the design of bravais containers is all based on
radius. So to change it to handle something else would break a lot of things.

> Also manipulation based on a polyhedron's own elements is something that would
be put in off_trans, perhaps some day. This was talked about a while back but I
can't find the thread.

> But I hear what you are saying. Say you have isolated edge type 1 and how to
scale it (with off_trans) so that edge is a series of values.


r But bravais then resizes the container based on -r so you lose that control.

sw Why ?
Let's start with an edge one rd.  I want to make a series then,
of containers for rd of edge sqrt1,sqrt2,sqrt3...
now, i do not care if the NEW container is NOT integer friendly, as those points
WITHIN will be.

r You could find the radius using off_report -S D (it would be vert_max), and
feed that into bravais using -r but that becomes quite cumbersome.

sw Do not need the radius, necessarily.


r > What could be done is to allow -r to take a parameter such that it instructs
bravais to take the radius from the container itself. Then it would internally
find vert_max. Then you could manipulate the container all you wanted and
bravais would use it as is.

sw Why not via the edge parameter ?


r > Remember that bravais honors where the container is on XYZ. That is why my
examples always make sure both the lattice and container begin centered on the
origin. But it does not have to be that way, only you then have to be very
careful the container doesn't miss the lattice!

sw WHY ?  So what if it misses the lattice ?

r > It should also be noted the -q will offset the -k container as it does with
the spherical one.

sw Good...the container could be offset...not a problem.  A criteria then for
the point set/convex hull...could even be symmetry biased.

r > > It would be nice to say ask for a spread..like 20-40...and it would
> > run through that series ( well someday perhaps for that ).
>
> A loop could be written in Python, for example, which could make a number of
them.

sw Sounds good.

r Antiprism has no GUI to step through OFF files yet, but as I remember, you
have Stella which could do it.

You can just press the right arrow button to go through all the OFF files in a
directory. If you do it this way, leave the vertices and edges uncolored or you
get a warning in Stella which you have to keep pressing an 'ok' button.

sw That is interesting.  However, I could as easily step through them in
antiprism without the need for any inventory.

Thinking out loud...
what i need as input is some  given container AND to be able to generate another
equally shaped container; but incremented somehow.

in each event, an integer is used as the sqrt value.

v = closest  vertex
V = furthest Vertex

f = closest face center
F = furthest Face center

e = smallest edge
E = largest Edge

m = mid-point of smallest edge
M = Mid-point of largest edge

example -

-k input.off V 13

this would take whatever lattice and take a chunk
in the shape of the convex hull in input.off, having
a container now the size of the sqrt 13 times the
furthest vertex distance from the centroid of the input hull.


Indeed, even if -k could do just the e option...that be would be quite useful,
as "series of series of series" now become possible with that feature alone*!

[* without an inventory, viewable, and able to be stepped through by manually
changing the sqrt values ].

I would just love to have say, an rd container to chunk out various lattices
with.  The idea of no inventory...that is, being piping driven, is the
enhancement so desired. So, controlling the container size in the piping line by
the shortest edge length, AND given an integer...then -k sub-routines and makes
a clone of itself with its edges now all the sqrt of the inputted value.  Would
you be up to this "e" feature programming request ( or others as above ) for the
bravais -k ?
[ no hurries no worries ]

steve

Hi Steve,

its size.  The size happens to be a radial component based upon the sqrt of
incremental integers.
>
> So, having a single sized container is useless pretty much.

I hope all this work wasn't useless!

> Let's take the VE as a container for example...

What is the VE?

> Currently, the -k option does not tap into this huge potential...
>
> I should think that one could always use sqrt integer value to discern v,f,or
e elements to generate difference unlimited series.

The main problem is that the design of bravais containers is all based on
radius. So to change it to handle something else would break a lot of things.

Also manipulation based on a polyhedron's own elements is something that would
be put in off_trans, perhaps some day. This was talked about a while back but I
can't find the thread.

But I hear what you are saying. Say you have isolated edge type 1 and how to
scale it (with off_trans) so that edge is a series of values. But bravais then
resizes the container based on -r so you lose that control. You could find the
radius using off_report -S D (it would be vert_max), and feed that into bravais
using -r but that becomes quite cumbersome.

What could be done is to allow -r to take a parameter such that it instructs
bravais to take the radius from the container itself. Then it would internally
find vert_max. Then you could manipulate the container all you wanted and
bravais would use it as is.

Remember that bravais honors where the container is on XYZ. That is why my
examples always make sure both the lattice and container begin centered on the
origin. But it does not have to be that way, only you then have to be very
careful the container doesn't miss the lattice!

It should also be noted the -q will offset the -k container as it does with the
spherical one.

> It would be nice to say ask for a spread..like 20-40...and it would
> run through that series ( well someday perhaps for that ).

A loop could be written in Python, for example, which could make a number of
them. Antiprism has no GUI to step through OFF files yet, but as I remember, you
have Stella which could do it. You can just press the right arrow button to go
through all the OFF files in a directory. If you do it this way, leave the
vertices and edges uncolored or you get a warning in Stella which you have to
keep pressing an 'ok' button.

Roger

Roger,

re The -k option in bravais

The way the sphere container works, is that it takes a shape,
a sphere, and it keeps that shape and uses a parameter to control its size.  The
size happens to be a radial component based upon the sqrt of incremental
integers.

So, having a single sized container is useless pretty much.

Let's take the VE as a container for example...

I want/need a routine to take an off file ( convex hull ) and
MODIFY the container/the chunk maker.  For a VE, one could again
take incremental chunks based upon a sqrt integer of the edge.

Thus an entire unlimited series can be generated...(in ANY lattice)

Take a w10, for example,  it has two edge types.  Either could be a factor used
to generate an unlimited series again.

Additionally, the container could be parametered by face center(s), vertex
distance(s), edge mid-point(s) as well.

Currently, the -k option does not tap into this huge potential...

I should think that one could always use sqrt integer value to discern v,f,or e
elements to generate difference unlimited series.
Granted, that duplicates would appear, however, the series of series of series
would all still be unlimited.

It would be nice to say ask for a spread..like 20-40...and it would
run through that series ( well someday perhaps for that ).

steve

Hi Adrian,

> > = face(2), does face(3) = face(4)... Also then, if any element list size
> > is odd then pairing cannot be the case? (An orient geom would have to be
> > done after this).
>
> Those checks would work (I am not sure about orienting afterwards
> as the geometry can be discarded after the check.) The original
> index numbers need to accessible at the time of the check though
> as they will be stored in the equivalent elements list.

What actually does this do? How would I test I didn't break it.

If sort_merge were a class, the actual sort merge would then be called as this

sm.sort_merge_elems(geom, merge_elems, eps, equiv_elems);

In the case of equiv_elems it might be

vector<map<int, set<int> > > orig_equivs;
sm.set_equiv_elems(&orig_equivs);
sm.sort_merge_elems(geom, merge_elems, eps, equiv_elems);

I think the interface for check_congruence I would leave be and not make part of
the class, but inside it would use the class.

I see setting the color function as

sm.set_blending_type(1) ;0 would be the default and be RGB
sm.sort_merge_elems(geom, merge_elems, eps, equiv_elems);

The color blending function would not be set as a callback, but would use the
blending type parameter.

In the past I experimented with materials. Materials can be made translucent and
the colors (if there are any) can be seen underneath. So I am thinking that
color blending would always be wanted.

Blending of materials isn't something I thought of and I'm not sure it can be
done! But if so a function could be provided.

Let me know if any of this seems contrary to what you have in mind.

> > if ( (elem=='e' && strchr(delete_elems.c_str(), 'e')) || (elem=='f' &&
strchr(delete_elems.c_str(), 'f')) ) {
> >
> > Then the edges are not reduced, but the index numbers are

>
> The way things currently work there is only supposed to be one
> edge in the edge list that joins two vertices. This is enforced
> by geom::add_edge, which is called when reading an off_file
> (although this should be changed for efficiency) and so
> applies to all the programs that accept OFF input e.g.
>
>     echo -e "OFF\n2 2 0\n0 0 0\n1 1 1\n2 1 0\n2 0 1\n"
>     echo -e "OFF\n2 2 0\n0 0 0\n1 1 1\n2 1 0\n2 0 1\n" | off_util

The interesting thing here is that sort_merge takes an 'e'! Then that means that
duplicate edges might be expected to occur, but in the end they are not used.
(antiview appears to use the last one encountered).

I am going to let the code above in and make reducing edges explicit. Color
blending of edges is valid and a sort_merge would be the way to do that.

I was looking at off_util and I am not sure I like that I chose 1e-8 as the
epsilon when all the rest of the apps use the default. I will look at making
off_util work the same as the other apps I wrote such that it takes the value of
epsilon from the global. I might have to add a merge color method parameter.

I have a lot of the app I will initally develop as a sort of "planar_util". In
early testing I will try coloring planar faces and will let that in as a
feature. In the end it will also include the deplanarization procedure which was
talked about earlier this year.

This should add some unique functioning to Antiprism. My schedule is so tight
lately that it could take some time to develop. However, instead of thinking of
it a race I am hoping to be able to add value to Antiprism for some time to
come.

Roger

Hi John

On Tue, 10 Nov 2009, John Brawley wrote:
> RGB to HSV should be in *some* C header file: Python enables this conversion

There is a C function in Antiprism that converts from RGB to
HSV, but it is only currently used within its source file and
so it doesn't appear in any header. Instead it is wrapped by
a member function of the class that handles colour values, and
the conversion is accesible from there.

Adrian.
--
Adrian Rossiter
adrian@...
http://antiprism.com/adrian

Hi Roger

On Wed, 11 Nov 2009, Roger Kaufman wrote:
> I was reading the comments for the equiv elems. If I understand it
> correctly, you are looking for a case where all elements are in pairs.
> Would it have been as simple as calling sort_merge with 's', and seeing
> if each odd element is equal to each even element? That is, does face(1)
> = face(2), does face(3) = face(4)... Also then, if any element list size
> is odd then pairing cannot be the case? (An orient geom would have to be
> done after this).

Those checks would work (I am not sure about orienting afterwards
as the geometry can be discarded after the check.) The original
index numbers need to accessible at the time of the check though
as they will be stored in the equivalent elements list.


> sort_merge was one of my first programs so it is old. (So I don't
> remember why everything is the way it is). There is a comment that it
> always reduces congruent edges. When this was written I am not sure
> edges were done the same way they are now.
>
> What it means is, if it was called with just 'v', then edges are reduced
> even though 'e' has not been specified.
>
> To test this, I change the line so it would only reduce edges if 'e' had
> been specified. In line 153 of the current sort_merge.cc I changed it to
>
> if ( (elem=='e' && strchr(delete_elems.c_str(), 'e')) || (elem=='f' &&
strchr(delete_elems.c_str(), 'f')) ) {
>
> Then the edges are not reduced, but the index numbers are remapped. But
> antiview only shows the one edge it encounters of each pair. Is this the
> way antiview would work? Only one edge is allowed to traverse two
> vertices? If antiview is suppose to work this way, it may be the reason
> I was always reducing faces when vertices alone are reduced.

The way things currently work there is only supposed to be one
edge in the edge list that joins two vertices. This is enforced
by geom::add_edge, which is called when reading an off_file
(although this should be changed for efficiency) and so
applies to all the programs that accept OFF input e.g.

     echo -e "OFF\n2 2 0\n0 0 0\n1 1 1\n2 1 0\n2 0 1\n"
     echo -e "OFF\n2 2 0\n0 0 0\n1 1 1\n2 1 0\n2 0 1\n" | off_util

Adrian.
--
Adrian Rossiter
adrian@...
http://antiprism.com/adrian

Hi Adrian,

I was reading the comments for the equiv elems. If I understand it correctly,
you are looking for a case where all elements are in pairs. Would it have been
as simple as calling sort_merge with 's', and seeing if each odd element is
equal to each even element? That is, does face(1) = face(2), does face(3) =
face(4)... Also then, if any element list size is odd then pairing cannot be the
case? (An orient geom would have to be done after this).


sort_merge was one of my first programs so it is old. (So I don't remember why
everything is the way it is). There is a comment that it always reduces
congruent edges. When this was written I am not sure edges were done the same
way they are now.

What it means is, if it was called with just 'v', then edges are reduced even
though 'e' has not been specified.

To test this, I change the line so it would only reduce edges if 'e' had been
specified. In line 153 of the current sort_merge.cc I changed it to

if ( (elem=='e' && strchr(delete_elems.c_str(), 'e')) || (elem=='f' &&
strchr(delete_elems.c_str(), 'f')) ) {

Then the edges are not reduced, but the index numbers are remapped. But antiview
only shows the one edge it encounters of each pair. Is this the way antiview
would work? Only one edge is allowed to traverse two vertices? If antiview is
suppose to work this way, it may be the reason I was always reducing faces when
vertices alone are reduced.

Here is how I tested this.

off_color cube -e yellow -v yellow | off_util -s > yellow_cage.off

off_color cube -e blue -v blue | off_util -s > blue_cage.off

off_util -M v -d 2 blue_cage.off yellow_cage.off | antiview

To see the outcome without doing the change, you can view the following OFF
file.

Roger

OFF
8 32 0
-0.5 -0.5 -0.5
-0.5 -0.5 0.5
-0.5 0.5 -0.5
-0.5 0.5 0.5
0.5 -0.5 -0.5
0.5 -0.5 0.5
0.5 0.5 -0.5
0.5 0.5 0.5
2 0 1 0.00000 0.00000 1.00000
2 0 1 1.00000 1.00000 0.00000
2 0 2 0.00000 0.00000 1.00000
2 0 2 1.00000 1.00000 0.00000
2 0 4 0.00000 0.00000 1.00000
2 0 4 1.00000 1.00000 0.00000
2 1 3 0.00000 0.00000 1.00000
2 1 3 1.00000 1.00000 0.00000
2 1 5 0.00000 0.00000 1.00000
2 1 5 1.00000 1.00000 0.00000
2 2 3 0.00000 0.00000 1.00000
2 2 3 1.00000 1.00000 0.00000
2 2 6 0.00000 0.00000 1.00000
2 2 6 1.00000 1.00000 0.00000
2 3 7 0.00000 0.00000 1.00000
2 3 7 1.00000 1.00000 0.00000
2 4 5 0.00000 0.00000 1.00000
2 4 5 1.00000 1.00000 0.00000
2 4 6 0.00000 0.00000 1.00000
2 4 6 1.00000 1.00000 0.00000
2 5 7 0.00000 0.00000 1.00000
2 5 7 1.00000 1.00000 0.00000
2 6 7 0.00000 0.00000 1.00000
2 6 7 1.00000 1.00000 0.00000
1 0 0.50196 0.50196 0.50196
1 1 0.50196 0.50196 0.50196
1 2 0.50196 0.50196 0.50196
1 3 0.50196 0.50196 0.50196
1 4 0.50196 0.50196 0.50196
1 5 0.50196 0.50196 0.50196
1 6 0.50196 0.50196 0.50196
1 7 0.50196 0.50196 0.50196