Hi Dick,

>octahedron/cuboctahedron honeycomb. I'm building a new model from >sticks and
rubber tubes.

Since I am in synergeo, and didn't see them there, I thought maybe there was yet
another group somewhere.

I like Adrian's jitterbug models as they are always quite facinating to watch.

Roger

Yes, email. I was asking Adrian about jitterbugging the octahedron/cuboctahedron
honeycomb. I'm building a new model from sticks and rubber tubes.

> Hi Dick,
>
> > Did you see Adrian's new work on the ivm-jitterbug
> transformation?
> >
>
> > > Here are these animations (fixing the front
> axial
> > > octahedron) (3Mb, 6Mb)
> > >
> > >    http://www.antiprism.com/misc/jit_cubo_oct3c.gif
> > >    http://www.antiprism.com/misc/jit_cubo_oct4c.gif
>
> I didn't. What list did this come from? Or is this an
> offline discussion with Adrian?
>
> Roger

Hi Adrian,

> I just seemed to me that for any cuboid, there can be at most 3 different
space or body diagonals. In order for there to be a 4th distance it can no
longer be a cuboid. And in fact, I think it can have nothing higher than Ci
symmetry.

Nix this! I wouldn't have thought this, but it appears that for any cuboid all
the body diagonals are the same!

Roger

Hi Adrian,

> > You mentioned diagonal D but actually there could be three diagonals
> > from which to choose. Perhaps the shortest D?
>
> I was thinking of the body diagonal. It is chosen just as a
> length that makes a reasonable "cone" with the base.

Could I just use max_width() for D, as it appears to be the calculation of the
longest D.

I should have said 4 diagonals. Mathworld calls than space diagonals.

I just seemed to me that for any cuboid, there can be at most 3 different space
or body diagonals. In order for there to be a 4th distance it can no longer be a
cuboid. And in fact, I think it can have nothing higher than Ci symmetry.

This gives me some things to work with. As I mentioned, I have yet to have the 3
random point system fail and I have run it a number of times with some very
extreme data. However, it would be go to know that it cannot fail.

Roger

Hi John

On Tue, 1 Dec 2009, John Brawley wrote:
>> You mentioned problems running your program on another
>> machine. I don't think you can count on binary
>> compatibiliy between different GLUT libraries so you
>> will probably always have to distribute the GLUT DLL
>> that came with the headers and import library that you
>> used in the build.
>
> Rats.  Kinda defeats the idea behind "cross platform"....

In general you won't get binary compatibility between
platforms anyway (although it would be a bonus between
different versions of libraries on the same platform.)

What GLUT does is to provide the same services on a
lot of platforms, which then allows your code to
build on all those platforms.


> But at least that's better than having to require entire installations
> (Python; VPython) on the user's machine.  I had hoped for an .exe that could
> just be downloaded and double-clicked, without having to either write an
> installer that auto-inserted the new glut stuff in, or having to ask the
> user to stick it, into his/her windows32 directory.

You can link statically against GLUT. That means that the code
that would be in the DLL is added into your executable and the
DLL is then not needed. You will have to check your compiler
documentation for how to do this, and the GLUT package you
are using will need a form of the library that you can
link to statically.


> with only two pieces of data, to boot (pNum and gRad).  Are you aware of
> anything that differs so dramatically to operation of a program, between
> (say) "packdemo 333 3.5" and "packdemo (opens, asks user for stuff, user
> manually enters 333, then 3.5)"  ??

No, it should be fine. You could check that you have converted
the strings to numeric values correctly by printing out the
numeric values as soon as you have converted them.

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

Hi Roger

On Tue, 1 Dec 2009, Roger Kaufman wrote:
>> Did you see Adrian's new work on the ivm-jitterbug transformation?
...
> I didn't. What list did this come from? Or is this an offline discussion
> with Adrian?

I wrote to Dick directly. Dick forwarded the messages to
Synergeo, so they are available there, but I could include
them here for reference.

------------------------------------------------

> On Sun, 8 Nov 2009, Dick Fischbeck wrote:
> Do you know of a dynamic model of an octahedron and cuboctahedron space
> filling honeycomb?

I guess you could aim for an octet truss.

At the beginning you have vertices surrounded by two
octahedra and four cuboctahedra. You want to end
up with vertices surrounded by six octahedra and eight
tetrahedra. That means that you are going to bring
together the original vertices in threes. If you
cut through a vertex perpendicular to a threefold
axis I think the vertices are laid out like a hexagon
and triangle tiling. You can rotate the triangles to
close down the hexagons bringing together three vertices
at the centre of each hexagon. If you can do this on the
similar parallel layers then that may bring about the
transformation.

I made a model of this transformation. There are
pauses at the octahedron/tetrahedron stage and the
cuboctahedron/octahedron stage (4Mb)

http://www.antiprism.com/misc/jit_cubo_oct1.gif

-----------------------------------------------------


The edges are doubled at the octet truss stage.

The cuboctahedra collapse down volumetrically into an
hour-glass-like pair of tetrahedra. There are three zero
volume diamond "fins" that spiral down the side of these.
You can make this shape from a jitterbug model. Place it
on a triangular face. Halfway up is a hexagon of vertices.
Push three alterate vertices into the centre. Make the six
vertical slanting triangles into three slanting diamonds.

The loss of volume then is 6 tetrahedra and 6 half-octahedra
per cuboctahedron.

There is originally one octahedron per cuboctahedron so the
ratio of original to transformed volume is

1 octahedron + 1 cuboctahedron : 1 octahedron + 2 tetrahdera
4 + 20 : 4 + 2
24 : 6
4 : 1

Another way to see this is by considering that the transformation
was created by jitterbugging the (6363) trihexagonal tiling

http://en.wikipedia.org/wiki/Trihexagonal_tiling

The triangle to hexagon ratio is 2 : 1. When you jitterbug it
to close down the hexagons the ratio of areas before and after is

1 hexagon + 2 triangles : 2 triangles
6 + 2 : 2
4 : 1

In the cuboctahedron/octahedron to octahedron/tetrahedron
transformation there is no contraction normal to the plane
of trihexahedral jitterbugging and so this ratio is also
the ratio of volumes before and after the transformation.

I have made another video from a different angle that
makes it easier to appreciate the cuboctahedron/octahedron
stage

http://www.antiprism.com/misc/jit_cubo_oct2.gif

--------------------------------------------------------


I made another animation that is clearer again (7Mb)

     http://www.antiprism.com/misc/jit_cubo_oct4.gif

Here is an individual cuboctahedron clossing down (3Mb)

     http://www.antiprism.com/misc/jit_cubo_oct3b.gif

---------------------------------------------------------


It might help to make an animation that stops the outer
axial octahedra rotating. This would make the edges of
the cubo/oct stage a subset of the edges of the oct/tet
stage and show better how the pairs of half-octahedra
(where cuboctahedra join) end up filled by the octahedra.

Here are these animations (fixing the front axial
octahedron) (3Mb, 6Mb)

     http://www.antiprism.com/misc/jit_cubo_oct3c.gif
     http://www.antiprism.com/misc/jit_cubo_oct4c.gif

The second might give you some ideas for supporting
elements if you want to make a physical model of this
particular transformation.

-----------------------------------------------------

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

Hi Roger

On Sun, 29 Nov 2009, Roger Kaufman wrote:
> In n_icons, line 1739 was a printf for debug. This is flagged as a
> warning in the Ubuntu build and is how I found it. It can be removed.

I have removed this.

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

Hi Roger

On Mon, 9 Nov 2009, Roger Kaufman wrote:
> This is the smaller file created showing the UC28 intersection. I used
> off_util -x V on the previous file. (-x V isn't in the help).

I have added this in now.

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

Hi Adrian

> Hi John
>
> On Fri, 27 Nov 2009, John Brawley wrote:
>> Yow!
>> More than a week's worth (probably 20 man-hours) of fighting and studying
>> and exampling and modifying and bastardizing-the-hell-out of my existing
>> program, and as of ten minutes ago I finally got a completely
>> out-of-control
>> OpenGL function rendering 'live' pionts blithering about (PACKING !) in
>
> Well done on getting the OpenGL working. Now that is done
> further development will hopefully be more straightforward.

Thanks, and yes, now that I can actually _see_ the effects of code changes,
it's much easier to alter things.  I've been playing with it quite a bit
lately.

> You mentioned problems running your program on another
> machine. I don't think you can count on binary
> compatibiliy between different GLUT libraries so you
> will probably always have to distribute the GLUT DLL
> that came with the headers and import library that you
> used in the build.

Rats.  Kinda defeats the idea behind "cross platform"....

But at least that's better than having to require entire installations
(Python; VPython) on the user's machine.  I had hoped for an .exe that could
just be downloaded and double-clicked, without having to either write an
installer that auto-inserted the new glut stuff in, or having to ask the
user to stick it, into his/her windows32 directory.

I *almost* gave up and was about to try using Windows' native windowing
system which would have made the program Windows-only (no glut at all), but
the program suddenly decided to work (I still don't know exactly what I did;
maybe changing the location of *one* line of code), so I'll stick with glut
for now, look for the glut that's most likely to be the one found on users'
machines, and try to make that one work.  (Interestingly, the program coded
for Microsoft's VC compiler doesn't work with Borland's.  That same
irritating __exit function incompatibility with glut shows up if I try to
compile the otherwise working program with the Borland compiler.)

As an added note: I got a test program working for using main(int argc, char
**argv){  , so I now know how to use command line variables, but when I
stuck it into the program (I thought maybe let the user do things the way
you ask him to, was going to make the "packdemo.exe" program take in data
that way), but when I did, it froze the program (disconnected the window
from the console window; killed user keyboard control), and nothing I tried
would get the program back the way it was (except going back to no command
line data entry).  --And as far as I could tell, *all* that I did was
substitute command-line variable entry for 'live' user variable entry, and
with only two pieces of data, to boot (pNum and gRad).  Are you aware of
anything that differs so dramatically to operation of a program, between
(say) "packdemo 333 3.5" and "packdemo (opens, asks user for stuff, user
manually enters 333, then 3.5)"  ??

Thanks for the comments.
Good luck with your own stuff.  (I've been following your conversations with
Roger but can only remotely understand them.)


Peace
jb
web: http://tetrahedraverse.com

Hi Roger

On Tue, 1 Dec 2009, Roger Kaufman wrote:
> You mentioned diagonal D but actually there could be three diagonals
> from which to choose. Perhaps the shortest D?

I was thinking of the body diagonal. It is chosen just as a
length that makes a reasonable "cone" with the base.


> Then you state chosing a point "D from c in the direction of e0". Since
> e0 is an edge, perhaps this means in the direction of mid-edge e0?

No, it is in the direction of the line of the edge (a free vector)
from c. As the box is aligned with the coordinate axes e0 will be
in the direction of the x, y, or z axis. Say the box centre is
(Cx, Cy, Cz) and e0 is aligned with the x-axis the point will be
added at (Cx, Cy, Cz) + (D, 0, 0) = (Cx+D, Cy, Cz)


> The edge sizes could be determined zero within epsilon. This doesn't
> exactly coincide with the distance between vertices but would be close
> enough.

If it is within epsilon it is probably fair enough to call it
zero. It might also be reasonable to call it zero if it is
less than D*epsilon.


> I didn't know that the bounding box would contain the points exactly. I
> thought that it had a minimum size. Is this why one point won't show up
> in antiview, that the bounding box is zero size?

Yes, it need special handling because the camera is placed relative
to a sphere that contains the points, and because the element size is
based on the smallest distance between two points (again, relative to
the container size).


> Since it does, the logic about box size could help. However, just
> determining that the points are a line does not rid the interior points
> of that line. But I could connect the end points of that line which
> could then be the result. If append, then also include the interior
> points.

After adding the second point the hull should be a tetrahedron.
There is only one edge that doesn't include either of the
newly added points, and that edge is the hull of the original
points.

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

Hi Adrian,

> > If the points are a line the hull will fail again. If you
> > place a second point at distance D from c in the direction
> > of e1 then it is clear that this second point cannot
>
> e0 and e1 could both have "zero" length.

I will look at the bounding box again. I had looked at it before but was
perplexed on how to use it. For example.

echo -e "OFF\n4 0 0\n0 0 0\n1 1 1\n2 3 4\n5 6 7\n"

would have a min of 0,0,0 and max 5,6,7. Therefore, both corners would lie on
the polygon.

But you are suggesting not using these raw points, which is good!

You mentioned diagonal D but actually there could be three diagonals from which
to choose. Perhaps the shortest D?

Then you state chosing a point "D from c in the direction of e0". Since e0 is an
edge, perhaps this means in the direction of mid-edge e0?

The edge sizes could be determined zero within epsilon. This doesn't exactly
coincide with the distance between vertices but would be close enough.

I didn't know that the bounding box would contain the points exactly. I thought
that it had a minimum size. Is this why one point won't show up in antiview,
that the bounding box is zero size?

Since it does, the logic about box size could help. However, just determining
that the points are a line does not rid the interior points of that line. But I
could connect the end points of that line which could then be the result. If
append, then also include the interior points.

Determining the box had no volume would mean a point or points at all one
coordinate. If append, return them all or if not just the first vertex.

If all the edges are non-zero then the second make_hull has to be done. But
there may be no need for any other make_hull(). This will come out in testing.

I realize that the way I am doing it now, if the test for a line fails, it must
be a point. I would not have to be concerned with a third point, and assume
there is a point or many points at one coordinate.

Roger

Hi John

On Fri, 27 Nov 2009, John Brawley wrote:
> Yow!
> More than a week's worth (probably 20 man-hours) of fighting and studying
> and exampling and modifying and bastardizing-the-hell-out of my existing
> program, and as of ten minutes ago I finally got a completely out-of-control
> OpenGL function rendering 'live' pionts blithering about (PACKING !) in

Well done on getting the OpenGL working. Now that is done
further development will hopefully be more straightforward.

You mentioned problems running your program on another
machine. I don't think you can count on binary
compatibiliy between different GLUT libraries so you
will probably always have to distribute the GLUT DLL
that came with the headers and import library that you
used in the build.

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

Hi Roger

On Tue, 1 Dec 2009, Adrian Rossiter wrote:
> has three kinds of edge vector. By increasing order of length
> call them  e0, e1, e2, the diagonal of the box has length D
> and the centre is at c
>
> The points may lie on a plane. Add a point at distance
> D from c in the direction of e0. As e0 is the shortest
...
> If the points are a line the hull will fail again. If you
> place a second point at distance D from c in the direction
> of e1 then it is clear that this second point cannot

e0 and e1 could both have "zero" length.

If both are zero then the result is a line (or point
if e2 is zero).

If e0 is zero but not e1 then use a vector perpendicular
to e1e2 for the direction of the first added point (could
do this in all cases where e1 is not zero).

For the second point, in all cases, just use a vector
perpendicular to e2 and the vector from the box centre
to the first added point for the direction of the second
point.

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

Hi Roger

On Sat, 28 Nov 2009, Roger Kaufman wrote:
>>> potential of it happening it must be extremely rare.
>>
>> The bounding box approach makes sure that it can't happen,
>> but also the extra points will be placed well away from
>> the plane or line which will help with precision.
>
> I don't use the bounding box. I am curious as to how you think this
> would work. Right now I just define my points by
>
> vec3d point1 = vec3d::random()*100;
>
> While I know this could be problematic, I've yet to have seen it fail.
> However if it were known that it could not fail that would be better.

If the initial hull fails then calculate the bounding box. It
has three kinds of edge vector. By increasing order of length
call them  e0, e1, e2, the diagonal of the box has length D
and the centre is at c

The points may lie on a plane. Add a point at distance
D from c in the direction of e0. As e0 is the shortest
vector the plane of the points makes a shallower angle
with the plane e1e2 than with any other plane of the box,
this means that the new point is clearly above the plane,
and has coordinates the same order as those in the model.
This should avoid precision errors in the hull
calculation.

If the points are a line the hull will fail again. If you
place a second point at distance D from c in the direction
of e1 then it is clear that this second point cannot
lie in the plane of the original points and the first
added point, but will always lie at a reasonable distance
from it, leading to a good hull calculation again.

That just leaves the problem of when two points
that do not have exactly the same coordinates
are considered to be coincident.

>> The naming isn't that important at the moment. In the end it
>> should replace the make_hull() function.
>
> It might be a replacement but make_hull_or_polygon can call make_hull
> potentially three times. It also makes a copy of the geom up to verts =
> 1025. I was thinking the former set_hull() would probably be faster for
> most cases.

By replacement I meant that add_hull and set_hull would call this
function rather than the existing make_hull().


> I also put the error messages in the errmsg variable instead of printing
> to stderr. More or less all works as before with set_hull and add_hull.

That is good. I need to make sure there is no printing to stderr
in the library.

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

Hi Roger

On Wed, 25 Nov 2009, Roger Kaufman wrote:
> I found one problem in the integration. I have taken out the color geom
> from the arguments and was passing geom as geom_if. So then for
> example...
>
> geom_v tgeom = geom;
> geom.clear_all();
> geom = tgeom;
>
> But geom was then empty. However
>
> geom_v tgeom = geom;
> geom.clear_all();
> geom.append(tgeom);
>
> works.

This is a bug. It looks like the default geom_if copy assignment
was being called. As geom_if has no data members to copy the
result is an empty geometry.

I have fixed this, and with the fix in place you can just do

     geom = (geom_v)geom;


> While I was at it, I took out the color geom from the
> test_points_vs_hull() items. As I am thinking
>
> col_geom_v in function call --> geom_if or v_geom specfied in function
>
> is allowed, but
>
> v_geom in function call --> col_geom_v specified in function
>
> is not allowed. Is this correct?

I believe so. It probably works for passing by value, but not
for the usual case of passing as a reference or pointer.

As a general rule, if a function does geometric processing and
doesn't require colours (even if it can optionally use them),
then use geom_if &/*. If a function requires colours then
use col_geom_v &/*. (Also pass the geometry as a const if the
function won't change it.)

In the end it may be that all the library functions will take
a geom_if to give more flexibility to custom geometry classes.

I am finding that I want to assign sizes to elements when
making models programatically, and so I will be adding that
into the library. That will be an opportunity to look at
how the geometry classes are set up.

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

Hi Dick,

> Did you see Adrian's new work on the ivm-jitterbug transformation?
>

> > Here are these animations (fixing the front axial
> > octahedron) (3Mb, 6Mb)
> >
> >    http://www.antiprism.com/misc/jit_cubo_oct3c.gif
> >    http://www.antiprism.com/misc/jit_cubo_oct4c.gif

I didn't. What list did this come from? Or is this an offline discussion with
Adrian?

Roger

Hi Roger

Did you see Adrian's new work on the ivm-jitterbug transformation?

Dick

--- On Mon, 11/30/09, Adrian Rossiter <adrian@...> wrote:


> Hi Dick
>
> On Mon, 30 Nov 2009, Adrian Rossiter wrote:
> > It might help to make an animation that stops the
> outer
> > axial octahedra rotating. This would make the edges
> of
> > the cubo/oct stage a subset of the edges of the
> oct/tet
> > stage and show better how the pairs of half-octahedra
> > (where cuboctahedra join) end up filled by the
> octahedra.
>
> Here are these animations (fixing the front axial
> octahedron) (3Mb, 6Mb)
>
>    http://www.antiprism.com/misc/jit_cubo_oct3c.gif
>    http://www.antiprism.com/misc/jit_cubo_oct4c.gif
>
> The second might give you some ideas for supporting
> elements if you want to make a physical model of this
> particular transformation.

(Update: can't guarantee operation: chokes on my other machine's
glut32.dll )

----- Original Message -----
From: "John Brawley" <jb@...>
To: "synergeo" <synergeo@yahoogroups.com>
Cc: <antiprism@yahoogroups.com>
Sent: Saturday, November 28, 2009 7:47 PM
Subject: [antiprism] coming soon simple demo


> This OpenGL packing picture now present with my program is so impressive
> (to
> me, anyway) that I'll be trying to make a command-line-driven simpleton
> demo
> for download, so's my various correspondents and friends can *see* it
> working, BUT :
>
> a) I'm not going to try to alter my whole program to do this, since more
> than about 500 pionts produces a flicker-besotted animated image.
> (Therefore, the graphic's usefulness to large-piont-number packing (or
> ball
> packing) users is limited.  All that's really needed is to give a user a
> sense of what's 'actually going on' inside the program (inside the
> packing)), so:
>
> b) I'll make a bare-bones hardcoded demo, taking very limited (or no) user
> input, that just throws a decent number (333 looks *real* nice) of pionts
> onto the screen and shows their behaviour over time.  I *will* allow a
> certain amount of compressing and expanding (through use of a very few
> keyboard keys), because the reaction of the pack to being smashed and
> let-up-on is a joy to watch.
>
> Peace
> jb
> web: http://tetrahedraverse.com
>
>
>
> ------------------------------------
>
>
> _____  Antiprism Site:  http://www.antiprism.com  _____
>
>
> Yahoo! Groups Links
>
>
>

Epiphany in the morning....

Stereo 3D for an object (in my case a ball of pionts) only requires two
things:
1) Two images of the same thing, separated laterally in space, and
2) One of them rotated slightly around the upright (Y, on a screen) axis.

Since 100% of the stereo effect depends only on changes in the (pionts, in
my case) locations in the X plane (horizontal motions only, no Y vertical,
no Z depth), separation is merely a matter of....

(X + somenumber,Y,Z)  and  (X - somenumber,Y,Z)

...., getting the needed two images is mathematically trivial.
(It's also true that only one of the Xs *needs* to be thus shifted; the
above is just the "balanced" way of doing this, which leaves 0,0,0 in the
middle of the picture instead of inside one of the images.)

Since the other need (a rotation in the X plane, around the Y axis) depends
only on adjusting the above X+ and X- separations variably according to
depth (how far + or - a piont is in the Z direction), it ought to be a
simple
matter of modifying the X+ and X- coordinates by some factor derived from
the Z coordinate, which is of course both + and - .

Turns out (kludgy so far, but consistent for all object sizes (piont
numbers) so far tested), that that is exactly the case:

http://tetrahedraverse.com/tverse/engine/packdemost.gif

(160 kb or so; 1366x768)
(Know also, that the pionts seen here are *moving* constantly.)

(Ignore the " *.25 " attached to the x, y, and z params; that's just a
"sizing" kludge needed to keep the images inside the window until I can
figure out how to control the OpenGL Viewpoint.)

How sweet it is, in my limited case, *not* to have to use any camera moves,
"stereo" functions, OpenGL tricks, or other object-independent
'complicatednesses', to get the needed perceptual depth. All I had to do was
double the glVertex(x,y,z) point being drawn, in the same place as the
single I was using (see the code, visible in the .gif), and play with the X
coordinates only.

(Offered for a) possible informative purposes and b) 'cause it's *neat* and
I'm proud O'meself fer figgering it out, at my age....)

Peace
jb
web: http://tetrahedraverse.com

Hi Adrian,

In n_icons, line 1739 was a printf for debug. This is flagged as a warning in
the Ubuntu build and is how I found it. It can be removed.

I have removed it here and can included it for the next build in case you are
away from your build machine.

Roger

Hi Adrian,

Enough has changed that merits and update.

I now check for just one point as part of the algorithm. I was doing this as a
pre-check but realized a geom could have a number of vertices all at one
coordinate. So now the method is

with no random points, first check for polyhedron (dimensions = 3)
with one random point, check for polygon (dimensions = 2)
with two random points, check for line (dimensions = 1)
with three random points, check for one point (dimensions = 0)

I had been trying to make it backwards compatible by having a return of 0 be
error, but I've given up on that. It is possible for the geom to be dimension 0
and still have multiple vertices in it (possible with add_hull). Now a return of
-1 is an error. I found that set_hull() isn't being used as much as I thought so
if it were decided to change to this algorithm, it would only change a few lines
of code in the other apps.

I have the limit of polygon size hard coded as 1024. But this seem arbitrary. It
would be better to be able to send the limit, and if not set it would be zero.
This would make the default to operate as a plain convex hull function, or be
able to check for polygons of a finite size at the asking of the calling
program.

In testing I also found out that that sort_merge crashes if sent an empty geom.
This is not possible in off_util, but is possible if used internally and I just
finally did it today. I just put a return of false from sort_merge_elems if
there are no vertices in the geom.

Roger

This OpenGL packing picture now present with my program is so impressive (to
me, anyway) that I'll be trying to make a command-line-driven simpleton demo
for download, so's my various correspondents and friends can *see* it
working, BUT :

a) I'm not going to try to alter my whole program to do this, since more
than about 500 pionts produces a flicker-besotted animated image.
(Therefore, the graphic's usefulness to large-piont-number packing (or ball
packing) users is limited.  All that's really needed is to give a user a
sense of what's 'actually going on' inside the program (inside the
packing)), so:

b) I'll make a bare-bones hardcoded demo, taking very limited (or no) user
input, that just throws a decent number (333 looks *real* nice) of pionts
onto the screen and shows their behaviour over time.  I *will* allow a
certain amount of compressing and expanding (through use of a very few
keyboard keys), because the reaction of the pack to being smashed and
let-up-on is a joy to watch.

Peace
jb
web: http://tetrahedraverse.com

Hi Adrian,

> I have fixed it so that for a geom that comes in with one point, or after
reduction (I do a sort_merge on vertices before trying 2 or 1 dimensional
tests), then it doesn't destroy the geom but returns the

After writing this I realized the sort_merge will make add_hull not work. For
some reason I thought this would be a speed up. Now I do no changes to the
original geom before calling make_hull.

Roger

Hi Adrian,

> > potential of it happening it must be extremely rare.
>
> The bounding box approach makes sure that it can't happen,
> but also the extra points will be placed well away from
> the plane or line which will help with precision.

I don't use the bounding box. I am curious as to how you think this would work.
Right now I just define my points by

vec3d point1 = vec3d::random()*100;

While I know this could be problematic, I've yet to have seen it fail. However
if it were known that it could not fail that would be better.

> > I can't turn it back on.
>
> That is strange. Does the dup2() not work? (I have written below
> that this code might not be needed though.)

> make_hull() sets the Qhull error stream to /dev/null if it can.
> Are you seeing messages because you are on a machine without
> /dev/null, or because there are Qhull error messages not being
> directed there?

Over that past few days I looked at make_hull and saw how stderr was being
diverted. I thought it wasn't working correctly. But when I transfered the
changes over to Ubuntu, there, things were working as expected. There is a
/dev/null in Cygwin. I don't know if it is a problem with dup2 or /dev/null. But
it appears it may be both!

Making it go to a file probably wouldn't have helped and it would have make
things slower.

I commented out the function for silent_make_hull and don't use it, but left it
in the source for future reference.

> The naming isn't that important at the moment. In the end it
> should replace the make_hull() function.

It might be a replacement but make_hull_or_polygon can call make_hull
potentially three times. It also makes a copy of the geom up to verts = 1025. I
was thinking the former set_hull() would probably be faster for most cases.


I have fixed it so that for a geom that comes in with one point, or after
reduction (I do a sort_merge on vertices before trying 2 or 1 dimensional
tests), then it doesn't destroy the geom but returns the one point. But the
dimension is still 0 which is also the return error code. I think this is
trivial but worth the mention.

For that reason, if a one point result was allowed it could still be caught with
verts() == 1. For bravais, lat_util, etc... it prints the warning (I don't error
out on convex hull errors but just don't use it) and still continues to the next
program such as antiview. antiview still doesn't display just one point, but it
doesn't error out.

I also put the error messages in the errmsg variable instead of printing to
stderr. More or less all works as before with set_hull and add_hull.

Roger

Hi Roger

On Wed, 25 Nov 2009, Roger Kaufman wrote:
> The second example in the first note of this thread I found that the two
> "random" points I added were on a straight line with one of the other
> vertices! I didn't realize how easy this is to do. The two random
> vectors in the code are better than that and while there is the
> potential of it happening it must be extremely rare.

The bounding box approach makes sure that it can't happen,
but also the extra points will be placed well away from
the plane or line which will help with precision.


> The only thing I can't get to work is "silent_make_hull()". I found the
> code which I originally found on the net. It redirects stderr to null
> but it won't return to stderr. In other words, once stderr is turned off
> I can't turn it back on.

That is strange. Does the dup2() not work? (I have written below
that this code might not be needed though.)


> Maybe instead I can redirect it to a temporary file and then delete that
> file.

I don't know whether this can introduce a significant delay.
Maybe nothing ever gets written though so there would be little
delay.

I can imagine the screen writes could cause a delay which might
be noticeable if the hull function was called in a loop.


> For now it just make a lot of ouput when it finds a polygon or line.
> Since lines and polygons happen rarely it might be just as wise not to
> mess with this. I don't know how portable it is.

make_hull() sets the Qhull error stream to /dev/null if it can.
Are you seeing messages because you are on a machine without
/dev/null, or because there are Qhull error messages not being
directed there?

The code with the dup2 shouldn't be needed unless Qhull
prints errors to a hardcoded stderr.


> I am going to put this convex hull in chull.cc. I don't know what to
> call it. It was "do_convex_hull" but perhaps "set_hull_or_poly". I broke
> out the convex hull "report" that comes out in bravais and waterman, it
> will remain there as that is the only place that it is used.

The naming isn't that important at the moment. In the end it
should replace the make_hull() function.

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

Yow!
More than a week's worth (probably 20 man-hours) of fighting and studying
and exampling and modifying and bastardizing-the-hell-out of my existing
program, and as of ten minutes ago I finally got a completely out-of-control
OpenGL function rendering 'live' pionts blithering about (PACKING !) in
barely-distinguishable(*) superfast color in a 400x400 OpenGL/glut window !
Yow!

((*)Dam', this OpenGL rendering is fast.)

(please pardon uncontrollable joy.  I hate programming.  I like very much
what can be done with it.  I'm not even sure what one thing I did that made
it work at last.)

Break time....

(*HUGE *sigh* of relief*.  Now at least I can figure out what has to be done
to get my poor program *back* the way it was, but now with a working
viewport.)

Thanks for everyone's help --especially Adrian's (but I did this without
reference to your (Adrian's) jitterbug OpenGL implementation).

Thanks, all, for ignoring this totally offtopic and unnecessary message....
(*broad-grin*)

Peace
jb
web: http://tetrahedraverse.com

Hi Adrian,

I integreated the make/add_hull_or_polygon into the base code. They are along
side the set_hull/add_hull except they return the dimension of the found object.
Except for a point which still returns dimension 3 instead of 0.

They are also integrated into the geom class the same way.

If it turns out you are working on these, you could send me what you have before
the next build and I could integrate what I have.


I found one problem in the integration. I have taken out the color geom from the
arguments and was passing geom as geom_if. So then for example...

geom_v tgeom = geom;
geom.clear_all();
geom = tgeom;

But geom was then empty. However

geom_v tgeom = geom;
geom.clear_all();
geom.append(tgeom);

works.

While I was at it, I took out the color geom from the test_points_vs_hull()
items. As I am thinking

col_geom_v in function call --> geom_if or v_geom specfied in function

is allowed, but

v_geom in function call --> col_geom_v specified in function

is not allowed. Is this correct?

Roger

----- Original Message -----
From: "Adrian Rossiter" <adrian@...>
To: <antiprism@yahoogroups.com>
Sent: Tuesday, November 24, 2009 12:20 PM
Subject: Re: [antiprism] Re: sort_merge subjects


> Hi John
>
> On Mon, 23 Nov 2009, John Brawley wrote:
>> double *pdb;
>> crashes the program, but
>> double *  pdb;
>> doesn't.
>> (I see the difference as "double, pointer-to-pdb;" and "double, pointer,
>
> It shouldn't matter. Maybe you had some intermittant or
> conditional error that just happend to show itself when you
> used the first form.

I don't know: it was repeatable.  Perhaps result of my strange way of
writing a program (and maybe related to the fact that I can't establish a
vector[] until the *user* tells it how big to be...).

>> Ok thanks, but it's really a nasty thing to do, to disallow adding input
>> to
>> the called function.  In C++  I thought you were supposed to be able to
>
> It would be better to be able to access to your data without
> having to use globals. The GLU tesselation functions (used to
> break a polygon into triangles) also work with callbacks, but
> they allow an extra pointer parameter in the callbacks for
> accessing data. You tell the tesselator where your data is and
> then when it calls the callback functions it passes this as the
> pointer argument.

Thanks.
I'm about to decide to rewrite the whole program in a form that's primarily
OpenGL, instead of trying to fit OpenGL into it piecewise.  Either way, it's
obvious I need to study much more deeply into how to use OpenGL.


Peace
jb
web: http://tetrahedraverse.com

Thought that might be the case.
Oh well, 't'was just an idea.

Have a happy!

JBw

----- Original Message -----
From: "Adrian Rossiter" <adrian@...>
To: <antiprism@yahoogroups.com>
Sent: Tuesday, November 24, 2009 12:43 PM
Subject: Re: [antiprism] "slicing" concentrically


> Hi John
>
> On Mon, 23 Nov 2009, John Brawley wrote:
>> Antiview has a "slice" function, which sends a plane through the object
>> onscreen, front-to-back.
>> Do you think it would be useful to add a similar function to
>> antiview.exe,
>> which 'slices' concentrically?
>
> It might have some uses, but would likely be too much work
> to consider. The slicing plane is handled just by moving the
> front face of the viewing volume, but I don't think this
> technique can be adapted to carve out a sphere.
>
> Adrian.
> --
> Adrian Rossiter
> adrian@...
> http://antiprism.com/adrian
>
>
> ------------------------------------
>
>
> _____  Antiprism Site:  http://www.antiprism.com  _____
>
>
> Yahoo! Groups Links
>
>
>

Hi Adrian,

I was able to get it to work. The intent was much as you described in the other
thread. One vertex or two vertices depending on the how often make_hull fails.
It works for lines with embedded vertices as well as polygons, which I output as
dihedrons.

The second example in the first note of this thread I found that the two
"random" points I added were on a straight line with one of the other vertices!
I didn't realize how easy this is to do. The two random vectors in the code are
better than that and while there is the potential of it happening it must be
extremely rare.

So for instance these two command work, the first giving one segment and the
next gives the same dihedron which was input. This works for polygons up to and
including a 1024-gon. (It could be anything, I just chose 2^10). It is pretty
much a circle at this point.

polygon -t dihedron 2 | off_util -M vef -x ef | lat_util -C c | antiview -v 0.5

polygon -t dihedron 20 | off_util -M vef -x ef | lat_util -C c | antiview -v 0.5

The only thing I can't get to work is "silent_make_hull()". I found the code
which I originally found on the net. It redirects stderr to null but it won't
return to stderr. In other words, once stderr is turned off I can't turn it back
on.

Maybe instead I can redirect it to a temporary file and then delete that file.

For now it just make a lot of ouput when it finds a polygon or line. Since lines
and polygons happen rarely it might be just as wise not to mess with this. I
don't know how portable it is.

I am going to put this convex hull in chull.cc. I don't know what to call it. It
was "do_convex_hull" but perhaps "set_hull_or_poly". I broke out the convex hull
"report" that comes out in bravais and waterman, it will remain there as that is
the only place that it is used.

Roger