ToDo

[Roger Kaufman]

Hi Adrian,

(I am going to use this thread for things that I have on my list)

Now that I have my development environment set up I can now move forward.

I have various programs that aren't for the main Antiprism build but I
could include them in my fork. The question is how to do it that it
works well for you since the programs will be mixed together.

The way I do it now is a separate directory next to src and src_extra,
addons, which works well to keep the work sectioned off but I had to add
it Makefile.am and configure.ac. Either you could be aware not to bring
those files into the main Antiprism fork, or you could have an addons
directory with one stub program in it.

Once a method is established, for any programs you don't want in the
main Antiprism build, I could put them in my fork. One program which
this can be done now is src_extra/off2txt.cc.

Do you have any ideas on how we could make this work easily?

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 6 Oct 2023, Roger Kaufman wrote:
> I have various programs that aren't for the main Antiprism build but I could
> include them in my fork. The question is how to do it that it works well for
> you since the programs will be mixed together.

...

> Do you have any ideas on how we could make this work easily?

You could use a separate repository for your programs, and then
provide instructions for building against a system installed Antiprism
library and also one installed into a user directory. This would mean
setting up a build sytem, but you could use whichever one you wanted.

If you want to keep the setup you have now, you could create a new branch
or repository and then synchronise it with the latest Antiprism code.

In either case, if your binaries are dynamically linked with the library
then a later Antiprism install could overwrite the installed library and
may stop your program binaries from working. This is because the Antiprism
library is not currently versioned.

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

[Roger Kaufman]

Hi Adrian,

On 10/6/2023 2:58 PM, Adrian Rossiter wrote:
> In either case, if your binaries are dynamically linked with the library
> then a later Antiprism install could overwrite the installed library and
> may stop your program binaries from working. This is because the
> Antiprism
> library is not currently versioned.

I don't know a lot about git yet. Other people have asked this same
question about not forking all the subdirectories with rather convoluted
solutions.

I think it would be easier to just make a new fork, and then remove the
src and src_extra subdirectories and add a new subdirectory. This would
make it so that all the build procedures are the same as the full version.

I would have to be responsible for keeping base up to date. Otherwise
the libraries could go out of sync as you mention.

But I wonder what happens if I try to do a git pull from the master with
missing directories in the fork. There is more research to do.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/7/2023 3:13 PM, Roger Kaufman wrote:
> I think it would be easier to just make a new fork, and then remove
> the src and src_extra subdirectories and add a new subdirectory. This
> would make it so that all the build procedures are the same as the
> full version.
>
> I would have to be responsible for keeping base up to date. Otherwise
> the libraries could go out of sync as you mention.
>
> But I wonder what happens if I try to do a git pull from the master
> with missing directories in the fork. There is more research to do.

I have made an initial fork of my fork of antiprism for addons. It has
and addons directory with one program in it. After setup, I did a git
clone and it built to finish.

https://github.com/ThatOtherSpock/antiprism_addons

A few notes...

Much of the root directory is the same as yours.
The configure.ac glut echo statements have been commented out, otherwise
it is the same as original minus some of the former directories (src,
src_extra, etc)
I don't generate an documents or man, rather, I'm going to create a doc
directory with a readme with example commands for each program

Now if there are programs you don't want within antiprism, I can
maintain them here. I was thinking of programs you've removed from
antiprism like minmax, I might add as well. I haven't decided on this
yet, the merit being that old commands listed in the archives might
still work.

I will move off2txt in this manor soon.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/21/2023 10:36 PM, Roger Kaufman wrote:
> I don't generate an documents or man, rather, I'm going to create a
> doc directory with a readme with example commands for each program

I rolled back on this. I think it is useful.

I tried man2html and it does make a web page, but I noticed your web
pages look nicer. What do you use?

Roger

[Adrian Rossiter]

Hi Roger

On Sat, 21 Oct 2023, Roger Kaufman wrote:
> Now if there are programs you don't want within antiprism, I can maintain
> them here. I was thinking of programs you've removed from antiprism like
> minmax, I might add as well. I haven't decided on this yet, the merit being
> that old commands listed in the archives might still work.

Perhaps kaleido, as Antiprism will make all its models.

I think poly_form includes all of minmax's functionality, and the option
changes are documented on the poly_form help page.

[Adrian Rossiter]

Hi Roger

I assemble the pages using an old perl program called gtml, which is
bundled with Antiprism in doc_src.

I looked for an alternative modern static site generator, and started
rewriting the site and documentation generation with eleventy, but this
is currently on hold. I think it is the way to go though, the Antiprism
album pages are from a time gone by!

[Roger Kaufman]

Hi Adrian,

On 10/24/2023 2:46 AM, Adrian Rossiter wrote:
> I assemble the pages using an old perl program called gtml, which is
> bundled with Antiprism in doc_src.
>
> I looked for an alternative modern static site generator, and started
> rewriting the site and documentation generation with eleventy, but this
> is currently on hold. I think it is the way to go though, the Antiprism
> album pages are from a time gone by!

I was able to make my some pages from your software in doc_src. This is
the preliminary "alpha page". Since it is your software, the look is
similar so I changed colors to make it look different. I've seen to it
your name or email address are no where in the pages or source. Let me
know if you'd like me to change anything.

https://www.interocitors.com/polyhedra/antiprism_addons/

I will add some python programs I have too. One is a "rotyz" which find
element coordinates from off_query. You had suggest a program that would
take the format

params_from_geom off_trans -R pfg_Vc0,pfg_Vc1,pfg_dirY,pfg_dirZ

I am thinking of writing this as in python. It would just generalized
form of what I've done with rotyz and some string replacement. A subject
for later.

> Perhaps kaleido, as Antiprism will make all its models.

I will move the programs when I'm ready to make a distribution. I had
ported Kaleido as an archaeological project. I'll own it.

> I think poly_form includes all of minmax's functionality, and the option
> changes are documented on the poly_form help page.

You are right. Commands should just be translated. I have developed a
system that has all the /bin directories of everything from packinon
0.08 to antiprism 0.31. Since I wasn't collecting the antiprism windows
64 bit install files I am missing 0.14 to 0.20. Do you still have them?

With the python code I attached I was able to get this very old command
I found to run in version 13. I put the off file output in the attachment.

antiold -v 13 "geodesic 5 | off_color -v CV -f CV -H 0 -S 0 -V 0,1 |
off_color -e C -S 1 -V 1 | antiview -v 0.05 -e 0.03 -E d"

Roger

[Adrian Rossiter]

Hi Roger

On Thu, 2 Nov 2023, Roger Kaufman wrote:
> I was able to make my some pages from your software in doc_src. This is the
> preliminary "alpha page". Since it is your software, the look is similar so I
> changed colors to make it look different. I've seen to it your name or email
> address are no where in the pages or source. Let me know if you'd like me to
> change anything.
>
> https://www.interocitors.com/polyhedra/antiprism_addons/

Looks fine, and makes life easy.

> You are right. Commands should just be translated. I have developed a system
> that has all the /bin directories of everything from packinon 0.08 to
> antiprism 0.31. Since I wasn't collecting the antiprism windows 64 bit
> install files I am missing 0.14 to 0.20. Do you still have them?

I have the zip files that include Windows binaries, are these the files
you mean? There is no installer, there is one zip file per release, and I
think the binaries are 32-bit.

[Roger Kaufman]

Hi Adrian,

On 11/3/2023 9:28 AM, Adrian Rossiter wrote:

You are right. Commands should just be translated. I have developed a system that has all the /bin directories of everything from packinon 0.08 to antiprism 0.31. Since I wasn't collecting the antiprism windows 64 bit install files I am missing 0.14 to 0.20. Do you still have them?

I have the zip files that include Windows binaries, are these the files
you mean? There is no installer, there is one zip file per release, and I
think the binaries are 32-bit.

Up to a time it was just a bin and share directories zipped. For example I have antiprism_bin_0.13.zip (10 thru 13).

Back to version 0.21 I can just put in your (newer) naming convention in your /files and it finds them.

The ultimate goal is to take commands I find in the archive that make interesting models, update them and put them in a gallery.

Roger

[Roger Kaufman]

Hi Adrian,

On 11/3/2023 11:59 AM, Roger Kaufman wrote:

I am missing 0.14 to 0.20. Do you still have them?

I have the zip files that include Windows binaries, are these the files
you mean? There is no installer, there is one zip file per release, and I
think the binaries are 32-bit.

Whatever you have of that span would be fine. I did try to build one and it failed miserably.

The Wayback Machine isn't any help because during that span the files were downloaded from SourceForge and that site is blocked to backup services. But antiprism.com is backed up nicely and I was viewing some jitterbug animations circa 2013.

Trying to share exe files is almost impossible I've found and they need to be downloaded from a link.

Roger

[Adrian Rossiter]

Hi Roger

On Sat, 4 Nov 2023, Roger Kaufman wrote:
> On 11/3/2023 11:59 AM, Roger Kaufman wrote:
>>> I am missing 0.14 to 0.20. Do you still have them?
>>
>> I have the zip files that include Windows binaries, are these the files
>> you mean? There is no installer, there is one zip file per release, and I
>> think the binaries are 32-bit.
>
> Whatever you have of that span would be fine. I did try to build one and it
> failed miserably.

I have managed to track down all the Antiprism project release files
(including the Packinon releases), and have uploaded them to

https://www.antiprism.com/files/releases/

(The file dates might not be the creation dates in some cases)

[Roger Kaufman]

Hi Adrian,

On 11/5/2023 1:25 AM, Adrian Rossiter wrote:
> I have managed to track down all the Antiprism project release files
> (including the Packinon releases), and have uploaded them to

That is good. I knew there were point 1 releases but I didn't know all
of them.

I had named my python library anti_common.py. I'm thinking that might
interfere with your python. I could change it.

Roger

[Adrian Rossiter]

Hi Roger

On Sun, 5 Nov 2023, Roger Kaufman wrote:
> I had named my python library anti_common.py. I'm thinking that might
> interfere with your python. I could change it.

I don't think it conflicts with anything. The antiprism_python library
file is called anti_lib.py.

[Roger Kaufman]

Hi Adrian,

Quick question. I think you work principally in a linux environment.

If I send you new programs (or not the same names as current programs),
could the linux executable run for you assuming I'm using the current
library as you are?

Or would it be better to send standalone exe programs except you'd have
to go to windows.

Roger

[Adrian Rossiter]

Hi Roger

On Tue, 7 Nov 2023, Roger Kaufman wrote:
> Quick question. I think you work principally in a linux environment.
>
> If I send you new programs (or not the same names as current programs), could
> the linux executable run for you assuming I'm using the current library as
> you are?

If everything is linked statically then the binaries may well work.

I share dynamically linked binaries for OSs based on Debian on the
Rasperry Pi, and linking with one version of libc but having a runtime
with a different version won't always work, but for where the binaries
will be installed I am able to manage it.

If you just want to share without a long build time, then setting up
your build to link with a locally built Antiprism library would be
useful.

> Or would it be better to send standalone exe programs except you'd have to go
> to windows.

I only use Windows to test that the Antiprism releases work on Windows!

[Roger Kaufman]

Hi Adrian,

On 11/8/2023 12:45 AM, Adrian Rossiter wrote:
> If you just want to share without a long build time, then setting up
> your build to link with a locally built Antiprism library would be
> useful.

I was able to make a standalone Linux antiprism program that I ran on a
laptop without antiprism present. So it should work. I can zip something
and make a link, if you want to see what I'm about to describe in action.

I've never been happy with my coloring options. e.g if you look at the
coloring options for canonical its a mess! (I'm going to fix this).
Other programs include some options but not others, or they can set an
option but not a color. Also my map handling is a mess in some programs
and are buggy. For example what I'm calling compound map in my programs
isn't the builtin compound map and is completely different.

Last week I got an idea and I wish I had done this way of programing
color from the beginning. It is to put some of off_color main in a
class. Then it is simple to declare the class, set the arguments. Then
only color code esoteric to a program need be maintained. Only when
custom maps are used is when local map code is needed.

The result is, for any program using it, any option not in their own
local code would fall through and do any off_color option or set a color.

Changes in some options letters would happen where they use the same
letter as one in off_color.  There are multiple unused option pairs
available.

I tried it on iso_delta since it doesn't have its own color options, and
it works nicely. The help is as such but that could be colored with
lighting by -F l or -F L for example. Options S and J will take the
sub-options as well.

Coloring Options (run 'off_util -H color' for help on color formats)
(run 'off_color -h' for help on other color options). Lowercase letters
color
using index numbers and uppercase letters color using color values.
keyword: none - sets no color

  -F <col>  color the faces according to: (default: K)
                 k,K - sets of faces connected by face edges
  -E <col>  color the edges according to: (default: F)
                 F   - color with average adjacent face color
  -V <col>  color the vertices according to: (default: E)
                 E   - color with average adjacent edge color
  -T <tran> face transparency. valid range from 0 (invisible) to 255
(opaque)
  -m <maps> a comma separated list of color maps used to transform color
            indexes (default: compound), a part consisting of letters from
            v, e, f, selects the element types to apply the map list to
            (default 'vef').

I have a converted conway program and for consistency it institutes the
lower, upper case system off_color uses for indexes vs values.

-F <col>  color the faces according to: (default: N)
                 n,N - color by number of sides
                 b,B - color faces by convexity using all dihedral angles
                 o,O - newly created faces by operation
                 w,W - use wythoff colors (overrides -V and -E)

Maps are another subject I need to touch on but I want to get your
thoughts without have too much at once. I have included the color_common
library I'm working on.

Roger

[Roger Kaufman]

Hi Adrian,

On 11/10/2023 11:59 AM, Roger Kaufman wrote:
> I was able to make a standalone Linux antiprism program that I ran on
> a laptop without antiprism present. So it should work. I can zip
> something and make a link, if you want to see what I'm about to
> describe in action.

Here is some static executable and code.

https://www.interocitors.com/tmp/code/color_class.zip

iso_delta is as was described and this command will color using the
default lighting.

./iso_delta -c o -s 1 -F l -E F -V E | antiview

Of course it could be colored the same way piped to off_color. The
object is that instead of having to choose which color options to use by
cut and pasting code, all color options are available and a relevant
option is listed in the help.

a ported conway is included too. There are less color options are listed
than now but all are still available, and more. (is off_color -f A
working it seems like it just colors by sides number)

./conway jgjdGD -F l | antiview -v 0.01
./conway jgjdGD -F S | antiview -v 0.01
./conway jgjdGD -F P | antiview -v 0.01
./conway jgjdGD -F A | antiview -v 0.01

The off color class is a more orderly way to code, but one down side is
some letter options will change but just one time.

The maps would be listed in this manor. The compound map is renamed
'colorful'.

-m <maps> a comma separated list of color maps used to transform color

            indexes (default: colorful), a part consisting of letters from

            v, e, f, selects the element types to apply the map list to
            (default 'vef').

               colorful:
red,darkorange1,yellow,darkgreen,cyan,blue,magenta,
                           white,gray50,black
               ghart: red,blue,green,yellow,brown,magenta,purple,grue,
                           gray,orange (from George Hart's original applet)
               convexity:  white,gray50,gray25 (for -F B, -E B)
               (built in maps start at index 3 when using operator N)
               (no effect when using -f w which uses internal wythoff maps)

The wythoff colors are made into indexes with lower case 'w' with the
code you provided in off_color 'color_vals_to_idxs'. The wythoff mapping
wouldn't be available for color indexes later, but the wythoff color
pattern would be there for other maps.

./conway GD -F W | antiview -v 0.01
./conway GD -F w | antiview -v 0.01 -m spread

These maps are coded internally to the program and not available to use
to color externally later if the the model was output as indexes. I have
around 6 or so small maps I've done this way over the years. The options
to make them available are

put them in shared maps.
put them in the library code but don't necessarily document it. This
guarantees they exist.
don't do anything and if we want these colors generate the model when
using the program.

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 10 Nov 2023, Roger Kaufman wrote:
> The result is, for any program using it, any option not in their own local
> code would fall through and do any off_color option or set a color.
>
> Changes in some options letters would happen where they use the same letter
> as one in off_color.  There are multiple unused option pairs available.
>
> I tried it on iso_delta since it doesn't have its own color options, and it
> works nicely. The help is as such but that could be colored with lighting by
> -F l or -F L for example. Options S and J will take the sub-options as well.

My preference is for programs with only the options that are really
needed. There are a lot of options that could be added to every program,
taken from off_color, off_trans, off_util, and even the export programs,
but I think it keeps things simpler to run an extra program in the chain,
rather than have programs with options and parameters outside of their
focus. However, if an unnecessary option provides a clear benefit for a
particular program then there is a case for including it.

> I have a converted conway program and for consistency it institutes the
> lower, upper case system off_color uses for indexes vs values.

...

>                w,W - use wythoff colors (overrides -V and -E)

I chose the scheme with upper and lower case letters a long time ago, but
it isn't so useful now. Any program that colours by index initially, and
has a map option, can output index numbers with "remap" (which could be
given the synonym "index", for more intuitive use in this way). For
example, the wythoff program colours by value, and there is no specific
option for colouring by index, but index numbers can still be output
with "remap"

wythoff -c a -m remap tet

Similarly,

off_color -f N -m remap std_tet

For conway, for example, I think the current letters are fine, and don't
need letter case to output index numbers. There is some redundancy with
off_color colouring, but the colouring methods are convenient for the
program. The wythoff colouring is also repeated, but might not offer much
in conway, and requires the lengthy -C option text to be included in the
conway help. I have also seen from your followup message that the index
coloring doesn't match the wythoff index numbers, which relate directly
to the pattern string.

[Adrian Rossiter]

Hi Roger

On Sat, 11 Nov 2023, Roger Kaufman wrote:
> Here is some static executable and code.
>
> https://www.interocitors.com/tmp/code/color_class.zip

The executables work for me.

> These maps are coded internally to the program and not available to use to
> color externally later if the the model was output as indexes. I have around
> 6 or so small maps I've done this way over the years. The options to make
> them available are
>
> put them in shared maps.
> put them in the library code but don't necessarily document it. This
> guarantees they exist.
> don't do anything and if we want these colors generate the model when using
> the program.

If there are only a few small maps, and you thought any of the maps might
be used externally to the program where it is usually used, then it would
probably be most convenient to add it to the lirary and document it.

[Roger Kaufman]

Hi Adrian,

On 11/11/2023 2:16 PM, Adrian Rossiter wrote:
> Hi Roger
>
> On Sat, 11 Nov 2023, Roger Kaufman wrote:
>> Here is some static executable and code.
>>
>> https://www.interocitors.com/tmp/code/color_class.zip
>
> The executables work for me.

This is good.

> If there are only a few small maps, and you thought any of the maps might
> be used externally to the program where it is usually used, then it would
> probably be most convenient to add it to the lirary and document it.

It would make coding easier for me so that is what I will do. I use the
'colorful' map in several programs.

> I think it keeps things simpler to run an extra program in the chain,
> rather than have programs with options and parameters outside of their
> focus.

This is why I passed this by you. It makes more sense than what I've
proposed. I am going to retain the color class code but will use an
if/then/else function for color options I use instead of the
off_color_main() idea. This will also centralize the sub symmetry code I
have in several programs. color_common will be new and stellate_common
can be removed.

> I chose the scheme with upper and lower case letters a long time ago, but
> it isn't so useful now. Any program that colours by index initially, and
> has a map option, can output index numbers with "remap" (which could be
> given the synonym "index", for more intuitive use in this way). For
> example, the wythoff program colours by value, and there is no specific
> option for colouring by index, but index numbers can still be output
> with "remap"

I won't do the index output and retain the lower case letter options I
have. I can make "index" work as well. Its a more universal method too.
I forgot about it, maybe it could be mentioned it in the program help if
indexes are desired.

> The wythoff colouring is also repeated, but might not offer much
> in conway, and requires the lengthy -C option text to be included in the
> conway help. I have also seen from your followup message that the index
> coloring doesn't match the wythoff index numbers, which relate directly
> to the pattern string.

You made a convenience function for the -C text. It could remain or it
could be -C tile colouring method (see wythoff -h for options) . There
should probably be an example of using it in the conway documentation.
We should find an interesting one. I found one that starts a radial
pattern but I don't know enough about it. Maybe a spiral radial of some
kind I'm imagining.

conway bebI -F W -C association,e:association,f | antiview -v 0.01

I have noticed what is happening with the colors. Some operations return
from wythoff with digons. When digons were input for the next operation,
the model would return with disconnected tilings. This of course
wouldn't result in a polyhedron. To stop that, I have code that removes
the digons and replaces them with edges. In the end any edge with no
color gets the edge color given in the command (or default edge color).
I could have an option not to replace the digons if desired as it is the
only way to make such models (they'll also have some 3 faces to an
edge). Unless it causes a segfault... they can be interesting.

Roger

[Adrian Rossiter]

Hi Roger

On Sun, 12 Nov 2023, Roger Kaufman wrote:
>> If there are only a few small maps, and you thought any of the maps might
>> be used externally to the program where it is usually used, then it would
>> probably be most convenient to add it to the lirary and document it.
>
> It would make coding easier for me so that is what I will do. I use the
> 'colorful' map in several programs.

In that case, if you are adding a map, perhaps you could also add in
"index" as a synonym for "remap". base/colormap.cc line 1312 (untested)

else if (strcmp(name, "remap") == 0) {
->
else if (strcmp(name, "index") == 0 || strcmp(name, "remap") == 0) {


and src/help.cc line 1552

remap
->
index, remap

And "index" could be the prefered name from now now on.

> know enough about it. Maybe a spiral radial of some kind I'm imagining.
>
> conway bebI -F W -C association,e:association,f | antiview -v 0.01

wythoff patterns may include five kinds of path, which are used to
generate faces (tiles). A path can necesarily circle a vertex, edge or
face, it can close after one step (local tile), or it can step around the
polyhedron.

The colour used for the first three cases is the base element colour.
Local tiles are coloured using the element type specified for the
association colouring, taken from the meta triangle where they start.
Paths that step around the polyhedron are left uncoloured.

off_color ico -f red -v yellow -e U | wythoff -c e4 -C a,f |antiview
off_color ico -f red -v yellow -e U | wythoff -c e3 -C a,e |antiview

In conway, the base vertices and elements are uncoloured, and so the
colouring that results might be largely uncoloured. Here is how it could
look

off_color ico -f red -v yellow -e orange | wythoff -c b -C a,f | wythoff -c e -C a,f | wythoff -c b -C a,f |antiview

This still includes uncoloured faces, as wythoff does not colour edges
and so after the first operator any element associated with an edge will
be uncoloured.

off_color ico -f red -v yellow -e orange | wythoff -c o -C a,f | antiview
off_color ico -f red -v yellow -e orange | wythoff -c o -C a,f | wythoff -c j -C a,f |antiview

> I have noticed what is happening with the colors. Some operations return from
> wythoff with digons. When digons were input for the next operation, the model
> would return with disconnected tilings. This of course wouldn't result in a
> polyhedron. To stop that, I have code that removes the digons and replaces
> them with edges. In the end any edge with no color gets the edge color given

I think it is right to convert the digons, but it affects the resulting
model, and hence the association colouring. In the following example there
is a join quadrilateral that circles a an orange edge, but if this was a
digon there would be two join quadrilaterals circling the edges of the
digon, and they would be uncoloured

off_color ico -f red -v yellow -e orange | wythoff -c o3 -C a,f |antiview -v 0.05
off_color ico -f red -v yellow -e orange | wythoff -c o3 -C a,f | wythoff -c j -C a,f |antiview

Anyway, digons generally are problem!

[Roger Kaufman]

Hi Adrian,

On 11/12/2023 9:38 AM, Adrian Rossiter wrote:
> In that case, if you are adding a map, perhaps you could also add in
> "index" as a synonym for "remap". base/colormap.cc line 1312 (untested)
>
>    else if (strcmp(name, "remap") == 0) {
>    ->
>    else if (strcmp(name, "index") == 0 || strcmp(name, "remap") == 0) {

I'm having a weird problem with adding a map. I've added this code in
colormap.cc right after the compound map. It is identical to that code
except for the list of colors.

 else if (strcmp(name, "colorful") == 0) {
    auto *multi = new ColorMapMulti();
    auto *overrides = new ColorMapMap;
    ColorMap *spread_map = colormap_from_name("spread+2");
    if (multi && overrides && spread_map &&
        (*stat = multi->read_params(map_name))) {
      // RK - a map used in RK's programs. Here for external use.
      // for using with coloring n faces shift as 'colorful+-3'
      // use nicer color values for green and orange
      overrides->set_col(0, Color(255, 0, 0));     // 3-sided red
      overrides->set_col(1, Color(255, 127, 0));   // 4-sided
darkoranage1 (X11)
      overrides->set_col(2, Color(255, 255, 0));   // 5-sided yellow
      overrides->set_col(3, Color(0, 100, 0));     // 6-sided darkgreen
(X11)
      overrides->set_col(4, Color(0, 255, 255));   // 7-sided cyan
      overrides->set_col(5, Color(0, 0, 255));     // 8-sided blue
      overrides->set_col(6, Color(255, 0, 255));   // 9-sided magenta
      overrides->set_col(7, Color(255, 255, 255)); // 10-sided white
      overrides->set_col(8, Color(127, 127, 127)); // 11-sided gray50
      overrides->set_col(9, Color(0, 0, 0));       // 12-sided black
      multi->add_cmap(overrides);
      multi->add_cmap(spread_map);
      if (map_size >= 0)
        multi->set_map_sz(map_size);
      cmap = multi;
    }
    else {
      delete multi;
      delete overrides;
      delete spread_map;
      cmap = nullptr;
    }
  }

But it isn't appending the spread map like 'compound' does.

e.g  This colors every face

off_color ico -f U -m compound | antiview

But this ends at black and then begins adding map indexes starting with 10.

off_color ico -f U -m colorful | antiview

But if I add spread to the command line it works to color all faces

off_color ico -f U -m colorful,spread | antiview

There must be something missing.

Roger

[Roger Kaufman]

Hi Adrian,

On 11/12/2023 4:00 PM, Roger Kaufman wrote:
> I'm having a weird problem with adding a map.

I found why. I still had a colorful map file in my path so it was using
that one.

Roger

[Roger Kaufman]

Hi Adrian,

On 11/12/2023 9:38 AM, Adrian Rossiter wrote:

> In that case, if you are adding a map, perhaps you could also add in
> "index" as a synonym for "remap". base/colormap.cc line 1312 (untested)
>
>    else if (strcmp(name, "remap") == 0) {
>    ->
>    else if (strcmp(name, "index") == 0 || strcmp(name, "remap") == 0) {

I ran into a problem I don't see the solution for. I have a statement
like this

print_status_or_exit(read_colorings(off_color.clrngs, map_file.c_str()),
'm');

But say they put in a map 'vga,f'. Now only clrngs[2] will be set. But
clrngs 0 and 1 won't be set. I was trying to see clrngs[1] was set, but
it responds with indexes. e.g clrngs[1].get_col(1) is 1.

I could keep track of this myself, but I was wondering if there was a
way to check if it was set.

Roger

[Roger Kaufman]

Hi Adrian,

On 11/15/2023 9:42 PM, Roger Kaufman wrote:
> print_status_or_exit(read_colorings(off_color.clrngs,
> map_file.c_str()), 'm');
>
> But say they put in a map 'vga,f'. Now only clrngs[2] will be set. But
> clrngs 0 and 1 won't be set. I was trying to see clrngs[1] was set,
> but it responds with indexes. e.g clrngs[1].get_col(1) is 1.
>

I think I remember this being discussed once. In n_icons I have a
special map to allocate a map of Color::maximum_index (that is why
set_wrap).

ColorMapMap *alloc_no_colorMap()
{
  auto *col_map = new ColorMapMap;
  // index INT_MAX as unset edge color
  col_map->set_col(0, Color::maximum_index);
  col_map->set_wrap();
  return col_map;
}

So then I used that to do this

// mark maps as unset. index at 0 will be Color::maximum_index
for (unsigned int i = 0; i < 3; i++)
    clrngs[i].add_cmap(alloc_no_colorMap());

... do default map assignments or
... do user entered map(s)

then check if any colorings have not been touched

for (unsigned int i = 0; i < 3; i++) {
    if (off_color.clrngs[i].get_col(0) == Color::maximum_index) {
        off_color.clrngs[i].del_cmap();
off_color.clrngs[i].add_cmap(colormap_from_name("colorful"));
    }
}

I tested this and it seems to do what I need and I don't think it breaks
anything.

Roger

[Adrian Rossiter]

Hi Roger

On Wed, 15 Nov 2023, Roger Kaufman wrote:
> I ran into a problem I don't see the solution for. I have a statement like
> this
>
> print_status_or_exit(read_colorings(off_color.clrngs, map_file.c_str()),
> 'm');
>
> But say they put in a map 'vga,f'. Now only clrngs[2] will be set. But clrngs
> 0 and 1 won't be set. I was trying to see clrngs[1] was set, but it responds
> with indexes. e.g clrngs[1].get_col(1) is 1.
>
> I could keep track of this myself, but I was wondering if there was a way to
> check if it was set.

I don't have time to fully look at this right now, but you can probably
check how many colormaps were set for each element with, e.g.
clrngs[1].get_cmaps().size().

The colouring with no maps will do nothing with indexes. The "null"
colormap is an actual colormap that can be added to a colouring, and
does nothing with indexex. The "remap"/"index" map is like "null", but
also allows index numbers to remapped with the map modifiers.

[Roger Kaufman]

Hi Adrian

On 11/16/2023 1:16 AM, Adrian Rossiter wrote:
> I don't have time to fully look at this right now, but you can probably
> check how many colormaps were set for each element with, e.g.
> clrngs[1].get_cmaps().size().

Yes, I see now where it is used.

I had been using the 'null' map when I didn't want any maps, but I've
updated the class not to do anything if the string is empty. I think
read_colorings() could handle and empty string but there is no reason to
call it. When done like the size() will be 0 until maps are added.

In testing I found a few bugs and there were a few improvements made.
e.g off_color_radial would also be able to make a range of color with
gray, rnd and deal so those were added. I have pushed the changes and it
included all the programs I own, except canonical. NEWS has been updated.

I will do canonical next, and the color handling can be similar to the
way it is done in bravais. That is, there are 4 (I think) entities to
color and an extra parameter can tell which one(s) to color. This will
be a lot more readable that the parameters and help is now. I'll
probably just be able to borrow that code.

There was one segfault I made happen out of improper code. At one point
I had this hardcoded with ",f" included which shouldn't be sensible.
colormap_from _name() stripped the name to colorful, but cmap is
returned as null so it didn't find the map name. In any case the ',f'
shouldn't have been there. Maybe it saw it as a second map name.

off_color.clrngs[2].add_cmap(colormap_from_name("colorful+-3,f"));

Roger

[Roger Kaufman]

Hi Adrian,

On 11/17/2023 9:52 PM, Roger Kaufman wrote:
> off_color.clrngs[2].add_cmap(colormap_from_name("colorful+-3,f"));
>

I noticed the call has a status parameter. This is the problem, '3,f' is
trying to be read a the integer.

error: could not open colour map file 'compound+-3,f': shift size: not
an integer

Everything is right with the code, its just that most of the time we
don't bother with the status because we have hard coded map names we
know exist. Again, the vef of the map needed be specified in this type
of call since its going to a specific coloring index.


One other thing I did was, with off_color_radial, finite maps can be
reversed so I added a parameter to do it. So then

off_color_radial geo_9_4 -m rainbow -E f -V e | antiview -v 0.01
off_color_radial geo_9_4 -m rainbow -E f -V e -r | antiview -v 0.01

So the reverse map is calculated like

off_color_radial: option -m: default map used is rainbow8
off_color_radial: option -m: reversed map is rainbow8+7*-1

So then make a grid with rainbow8 wrapping is ok

col_util -d 3 -m rainbow8% | antiview

But there is no way to wrap the reverse map so it has a lot of unset colors

col_util -d 3 -m rainbow8+7*-1% | antiview

I don't need to have the reverse map wrap in the program. But I was
wondering if there is a way to do it. There is no other place to put '%'
than the end of the string.

Roger

[Roger Kaufman]

On 11/18/2023 12:13 PM, Roger Kaufman wrote:
> the vef of the map needed be specified in this type of call since its
> going to a specific coloring index.

That should have read

the vef of the map  is not  needed  to  be specified in this type of

call since its going to a specific coloring index.

Roger

[Adrian Rossiter]

Hi Roger

On Sat, 18 Nov 2023, Roger Kaufman wrote:
> On 11/17/2023 9:52 PM, Roger Kaufman wrote:
>> off_color.clrngs[2].add_cmap(colormap_from_name("colorful+-3,f"));
>
> I noticed the call has a status parameter. This is the problem, '3,f' is
> trying to be read a the integer.
>
> error: could not open colour map file 'compound+-3,f': shift size: not an
> integer
>
> Everything is right with the code, its just that most of the time we don't
> bother with the status because we have hard coded map names we know exist.
> Again, the vef of the map needed be specified in this type of call since its
> going to a specific coloring index.

The "vef" is a fake map name, interpreted by read_colorings(), to specify
which elements the real colormaps will be applied to. It is a hack, but
it is convenient and fairly intuitive.

> One other thing I did was, with off_color_radial, finite maps can be reversed
> so I added a parameter to do it. So then

...

> So then make a grid with rainbow8 wrapping is ok
>
> col_util -d 3 -m rainbow8% | antiview
>
> But there is no way to wrap the reverse map so it has a lot of unset colors
>
> col_util -d 3 -m rainbow8+7*-1% | antiview
>
> I don't need to have the reverse map wrap in the program. But I was wondering
> if there is a way to do it. There is no other place to put '%' than the end
> of the string.

You could increase the range that is reversed using remap

col_util -d 3 -m remap+127*-1,rainbow8% | antiview

[Adrian Rossiter]

Hi Roger

On Sat, 18 Nov 2023, Roger Kaufman wrote:
> One other thing I did was, with off_color_radial, finite maps can be reversed
> so I added a parameter to do it. So then
>
> off_color_radial geo_9_4 -m rainbow -E f -V e | antiview -v 0.01
> off_color_radial geo_9_4 -m rainbow -E f -V e -r | antiview -v 0.01

If reversing colormaps is something you use, you could add a special
index to index colormap that does this, e.g. reverseN:I, where I is the
base index for the reversal (default 0) and N is the number of elements,
(starting at I) for the flip, such that I and N-1 will be exchanged. With
this, your second command above would be

off_color_radial geo_9_4 -m reverse256,rainbow -E f -V e | antiview -v 0.01

I think the map is index i -> N-1 + 2*I - i

Adrian

[Roger Kaufman]

Hi Adrian,

(Note: none of what I mention here has been pushed)

On 11/19/2023 5:42 AM, Adrian Rossiter wrote:
> If reversing colormaps is something you use, you could add a special
> index to index colormap that does this, e.g. reverseN:I, where I is the
> base index for the reversal (default 0) and N is the number of elements,
> (starting at I) for the flip, such that I and N-1 will be exchanged. With
> this, your second command above would be
>
>    off_color_radial geo_9_4 -m reverse256,rainbow -E f -V e | antiview
> -v 0.01
>
> I think the map is index i -> N-1 + 2*I - i

I was wondering there could be a general operation for this. I've looked
that colormap code for a bit and I can't see how this would be coded.
(and I haven't seen the format you are showing where the first map would
alter the second map).

As for the program, doing it as a shift and step (which -r will
calculate) works now and it prints the map used in case.

off_color_radial geo_3_1 -m rng -r | antiview
off_color_radial: maximum ridges formed is 3
off_color_radial: option -m: default map used is rng3
off_color_radial: option -m: reversed map is rng3+2*-1

I've updated the program to do the same with 'index'. Now as long as the
suffix used (here is 3+2*-1) on the 'index' map, in this case 'rng',
will give the same pattern as if 'rng' had been in the command. The '3'
and the '2' in antiview could both be raised (but not lowered or some of
the map values won't resolve). Then other color ranges would happen.
This suggests the program should be able to raise the values.

off_color_radial geo_3_1 -m index -r | antiview -m rng3+2*-1
off_color_radial: maximum ridges formed is 3
off_color_radial: option -m: default map used is index3
off_color_radial: option -m: reversed map is index3+2*-1

I have canonical done (not pushed). There are 12 entities (and 3
elements per entity) which can be colored and only a few had been
available. Now they are all available and there are a few operations in
the mix. A command might look like

-F blue,d,128  would mean color the faces of dual blue with a
transparency 128. Transparency values could be set within the color but
then a color value would be used so it is a convenience. Also it is
there to set transparency for the results of operations. Because of this
apply_tranparency is changed in base to be able to take edges and
vertices as well as faces (the default).

Status apply_transparency(const int opacity, const int elem = FACES);

I'm going to change the -T parameter in my programs from -T <trans> to
-T <elem>,<trans>. There have been a number of parameter changes made
and so this is the iteration to do it. But I think I'm coming near the
end of any features I was planning to add most programs.

Roger

  -F <col>  face color/operation, assignment (required), transparency
(optional)
              assignments to are: b - base, d - dual, i - intersection
points
                edge nearpoints, n - base, m - dual; c - base/dual
convex hull
                edge nearpoints centroid, p - base, q - dual; o -
origin point
                u - tangent sphere, incircles (or rings), s - base, t -
dual
                (one element, required; multiple -F as needed)
              defaults: b - unchanged, d - 'b' take color from base
vertices,
                i - yellow, n,p - red, m,q - darkgreen, c - white,
                o - yellow, u - white, s,t - 'f' color of face
  -E <col>  edge color (same format as for faces) (defaults: unchanged)
  -V <col>  vertex color (same format as for faces) (defaults: unchanged)
             transparency: valid range from 0 (invisible) to 255 (opaque)

[Adrian Rossiter]

HYi Roger

On Mon, 20 Nov 2023, Roger Kaufman wrote:
> On 11/19/2023 5:42 AM, Adrian Rossiter wrote:
>> If reversing colormaps is something you use, you could add a special
>> index to index colormap that does this, e.g. reverseN:I, where I is the
>> base index for the reversal (default 0) and N is the number of elements,
>> (starting at I) for the flip, such that I and N-1 will be exchanged. With
>> this, your second command above would be
>>
>>    off_color_radial geo_9_4 -m reverse256,rainbow -E f -V e | antiview -v 0.01
>

> I was wondering there could be a general operation for this. I've looked that
> colormap code for a bit and I can't see how this would be coded. (and I
> haven't seen the format you are showing where the first map would alter the
> second map).

I have appended some example code that adds in a "reverse" map. The
two parameter form is different to what I say above (which I didn't
write correctly anyway!)

reverseN - reverses a map, switching index numbers 0 and N-1
reverseI:J reverses a map, switching index numbers I and J

The one parameter form reverses a map with N entries (but also will
process index numbers outside that range). The second form provides
easy to understand parameters for a reflection at any point.

The following are equivalent

reverse256
reverse0:255

I considered that the first parameter could be N in both cases, but
it made the two parameter form very difficult to use. Anyway, if the
code is of interest, feel free to change the parameter meaning.

Adrian.

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

======== colormap.cc, after ColorMapDeal definition

/// A colour map that reverses index numbers
class ColorMapReverse : public ColorMap {
private:
vector<int> switch_idxs = {0, 16};

public:
/// Initialise from a string
/**\param map_name the map name.
* \return status, evaluates to \c true if the map could be initialised
* (possibly with warnings) otherwise \c false. */
virtual Status init(const char *map_name);

/// Get a copy of the map
/**\return a pointer to the dynamically allocated copy,
* which must be freed by the caller with \c delete, 0 indicates
* that the clone failed. */
ColorMap *clone() const { return new ColorMapReverse(*this); }

/// Get the colour value for an index number.
/**\param idx the index.
* \return The colour. */
virtual Color get_col(int idx) const;
};

Status ColorMapReverse::init(const char *map_name)
{
// Make a copy for parsing
string name_str(map_name);
char *name = &name_str[0];

Status stat = init_strip(name);
if (stat.is_error())
return stat;

Split vals(name, ":", true);

if (vals.size() > 2)
return Status::error("map_name contains more than one ':'");

// Formats:
// N - Reverse to switch N-1 and 0
// I:J - Reverse to switch I and J
vector<int> params;
int param;
for(size_t i=0; i<vals.size(); i++) {
if (vals.size() > i && *vals[i]) {
if (!(stat = read_int(vals[i], &param))) {
const vector<string> param_names = {"first", "second"};
return Status::error(msg_str("%s parameter: '%s' %s",
param_names[i].c_str(), vals[i],
stat.c_msg()));
}
else
params.push_back(param);
}
}

if(vals.size()==2) // format I:J
switch_idxs = params;
else if (vals.size()==1) // format N
switch_idxs = {0, params[0]-1};
else // default
switch_idxs = {0, 16};

return Status::ok();
}

Color ColorMapReverse::get_col(int idx) const
{
int eff_idx = get_effective_index(idx);
int new_idx = switch_idxs[0] + switch_idxs[1] - eff_idx;
return Color(new_idx);
}


======== colormap.cc, colormap_from_name_generated, after "deal" check

else if (strcmp(name, "reverse") == 0) {
auto *cmr = new ColorMapReverse;
if (cmr) {
if ((*stat = cmr->init(map_name + name_len)))
cmap = cmr;
else
delete cmr;
}
}

[Roger Kaufman]

Hi Adrian,

On 11/22/2023 12:59 AM, Adrian Rossiter wrote:
> I considered that the first parameter could be N in both cases, but
> it made the two parameter form very difficult to use. Anyway, if the
> code is of interest, feel free to change the parameter meaning.

It works but it segfaults with no N. Split's vals.size() will be 1 for
"reverse" and "reverseN" both. But vals[0] will be empty . Code snippet
below.

I'd consider raising the default higher than 16, but its probably most
useful parameterized. How to describe it in the help I'm not sure.

I was going to mention this case where the first color is always color
0, then the rest is reversed. There doesn't seem to be a way to
eliminate it.

./col_util -d 3 -m remap-256*-1,rainbow8% -Z 256 | antiview

However it works ok with reverse. So maybe that is the way to go.

./col_util -d 3 -m reverse256,rainbow8% -Z 256 | antiview


To test no N, which works now, only the first row is reverse.

./col_util -d 3 -m reverse,rainbow8% -Z 256 | antiview

Roger


  // if no N

  // default
  switch_idxs = {0, 16};

  if (*vals[0]) {

    // Formats:
    // N - Reverse to switch N-1 and 0
    // I:J - Reverse to switch I and J
    vector<int> params;
    int param;

    for (size_t i = 0; i < vals.size(); i++) {

      if (vals.size() > i && *vals[i]) {
        if (!(stat = read_int(vals[i], &param))) {
          const vector<string> param_names = {"first", "second"};
          return Status::error(msg_str("%s parameter: '%s' %s",
                                       param_names[i].c_str(), vals[i],
                                       stat.c_msg()));
        }
        else
          params.push_back(param);
      }
    }

    if (vals.size() == 2) // format I:J
      switch_idxs = params;
    else if (vals.size() == 1) // format N

      switch_idxs = {0, params[0] - 1};
  }

Roger

[Adrian Rossiter]

Hi Roger

On Wed, 22 Nov 2023, Roger Kaufman wrote:
> On 11/22/2023 12:59 AM, Adrian Rossiter wrote:
>> I considered that the first parameter could be N in both cases, but
>> it made the two parameter form very difficult to use. Anyway, if the
>> code is of interest, feel free to change the parameter meaning.

...

> I'd consider raising the default higher than 16, but its probably most useful
> parameterized. How to describe it in the help I'm not sure.

I thought 256 originally, but then if a small colormap is used then
the default will reverse color indexes out of range, and the smaller
default might at least show some colour reversal. However, I don´t think
there is a natural or useful default, so it might be better to insist on
at least one parameter.

> I was going to mention this case where the first color is always color 0,
> then the rest is reversed. There doesn't seem to be a way to eliminate it.
>
> ./col_util -d 3 -m remap-256*-1,rainbow8% -Z 256 | antiview

There is a bug here. The map parameters are supplied as

map_name+shift*step%wrap

And the following works

col_util -d 3 -m remap+-256*-1,rainbow8% -Z 256 | antiview

The + is not a redundant plus sign, but simply a separator (and not
really looking like something that would be followed by a minus sign!).

The bug is that the map name is processd forwards, and the parameters
are processed backwards, and there can be an invalid section of
characters in the middle that are ignored, in this case -256, but also

col_util -d 3 -m remap$$$$*-1,rainbow8% -Z 256 | antiview

I'll review this when you have finished looking at the colormap code.

[Adrian Rossiter]

Hi Roger

On Thu, 23 Nov 2023, Adrian Rossiter wrote:
> On Wed, 22 Nov 2023, Roger Kaufman wrote:
>> I was going to mention this case where the first color is always color 0,
>> then the rest is reversed. There doesn't seem to be a way to eliminate it.
>>
>> ./col_util -d 3 -m remap-256*-1,rainbow8% -Z 256 | antiview
>
> There is a bug here. The map parameters are supplied as
>
> map_name+shift*step%wrap
>
> And the following works
>
> col_util -d 3 -m remap+-256*-1,rainbow8% -Z 256 | antiview
>
> The + is not a redundant plus sign, but simply a separator (and not
> really looking like something that would be followed by a minus sign!).

I have just noticed the the remap isn't reversing the numbers in the map
range, but is giving the right results because the rainbow map has a
%. The remap that does reverses the map is remap+255*-1

col_util -d 3 -m remap+-256*-1,rainbow8% -Z 256 | antiview

col_util -d 3 -m remap+255*-1,rainbow8% -Z 256 | antiview

col_util -d 3 -m remap+-256*-1,rainbow8 -Z 256 | antiview
col_util -d 3 -m remap+255*-1,rainbow8 -Z 256 | antiview

[Roger Kaufman]

Hi Adrian,

On 11/23/2023 4:46 AM, Adrian Rossiter wrote:
> I have just noticed the the remap isn't reversing the numbers in the map
> range, but is giving the right results because the rainbow map has a
> %. The remap that does reverses the map is remap+255*-1
>
>    col_util -d 3 -m remap+-256*-1,rainbow8% -Z 256 | antiview
>    col_util -d 3 -m remap+255*-1,rainbow8% -Z 256 | antiview
>
>    col_util -d 3 -m remap+-256*-1,rainbow8 -Z 256 | antiview
>    col_util -d 3 -m remap+255*-1,rainbow8 -Z 256 | antiview

I can't believe I forgot the '+'. That would make a difference.

> The bug is that the map name is processd forwards, and the parameters
> are processed backwards, and there can be an invalid section of
> characters in the middle that are ignored, in this case -256, but also
>
>    col_util -d 3 -m remap$$$$*-1,rainbow8% -Z 256 | antiview
>
> I'll review this when you have finished looking at the colormap code.

I have pushed all programs with modified map and transparency code.
Canonical now has a better coloring system. Of the programs I've worked
on, I've tested the help examples and corrected where necessary. n_icons
was the only program that set transparency for edges and now it can do
so with -T n,e and not needing the separate -U parameter. -T n still
works on faces by default as before.

I noticed in my offview python program the -T 0..1 means the opposite
that as done in Antiprism. It is also opposite alpha value. I am going
to reverse that in the next release.

For the Reverse map I changed it to 256, but I agree it isn't of much
use without N. We can make N required if it seems better. I don't call
it anywhere and haven't described it in help.h as of yet.

I think I should run a 'clang-tidy' at some point as it hasn't been done
for a while.

e.g. I went through and everywhere I used clrngs[2] and changed to
clrngs[FACES]. I know that 2 means FACES but it is knows to be safe and
more readable this way.

Roger

[Roger Kaufman]

Hi Adrian,

I'm having trouble with my Git fork the way I'm doing it. I'm not able
to do a pull from master because I've made so many deletions and changes.

In my situation, I only ever want to work downstream only. What I think
I should do is start the whole fork over again and not delete or change
anything from the original fork. All my work would be done in new
folders in the fork. Then the hope is, any thing I pull from the master
will never conflict with the original fork files.

Here is a blog on how someone describes downstream only work. But I
should never have to merge anything if I do it as described above.

https://medium.com/@snsavithrik1/how-to-keep-a-downstream-git-repository-current-with-upstream-repository-changes-98fd6351d6ac

Roger

[Roger Kaufman]

Hi Adrian,

On 11/26/2023 9:19 PM, Roger Kaufman wrote:
> I'm having trouble with my Git fork the way I'm doing it. I'm not able
> to do a pull from master because I've made so many deletions and changes.

I think I found a way to do this and if it works its pretty slick.

On github.com a branch can be created and it can be made the default
branch. I made the branch "antiprism_addons" (it is same name as the
repostitory). Now there are two branches, master and that one.

Before I started the following, I changed and committed on file in the
antiprism_addons branch.

I did a commit today in antiprism_rk (which only has master). Then over
in antiprism_addons folder on my pc I switch to the master branch with
"git checkout master". Then I did a "git pull antiprism_rk master".

Now when I switch over to the antiprism_addons branch the update isn't
there yet. On github.com there is a sync fork button. After that the
update is available and just do a "git pull" into the antiprism_addons
branch on my pc.

As a test, the one file I committed in the branch is still the new file,
and the master still has the old file. If I switch back and fourth
between branches on the pc, all the files change to their branch owner.

This should be the solution to my syncing problem.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/24/2023 2:34 AM, Adrian Rossiter wrote:
> Perhaps kaleido, as Antiprism will make all its models.

I removed kaleido and off2txt from antiprism_rk. I think i found all the
places it is referred to, in doc_src, .gitignore and the gtm files

I will put out an alpha build of the addons programs soon.

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 24 Nov 2023, Roger Kaufman wrote:
> I have pushed all programs with modified map and transparency code. Canonical

I have been reviewing the various named maps, and making sure they won't
allow any extra characters when specified.

I created a function for all the "override" maps, to reduce code
duplication and ensure common behaviour. There is a potential for
undesired changes to colormaps of this kind, although I haven't noticed
any in testing. The function handles for a map size for all these maps.

The new "axes" and "convexity" maps (which correspond to single colormaps)
were set to wrap at their size, and would ignore a specific wrap set by
the user. Rather thn have special handling, I have changed these to not
to wrap by default, but to wrap by adding "%". If your programs depend on
the wrap, you will need to add the "%" to the name. [I just noticed I
didn't update help.h to remove where the wrap is documented, I will do
this now].

For the other internal maps, some take a map size and some take
map-specific parameters. I have tried to make sure there is an error
produced if either of these are provided for a map that doesn't handle
them. I also documented the maps that don't accept a map size.

The index/remap map does not accept a map size, but it could be supported
if it served a purpose.

I documented that the "none" colour cannot be used in maps.

The resources page has a colour map section that is out of date. I removed
the details of individual maps and referred to 'off_util -H col_map'
instead. This help is also not fully up to date, as there are some maps
supplied as files (e.g. 5x5x5) and in alt_names.txt which are not listed.
You might want to review this.

> For the Reverse map I changed it to 256, but I agree it isn't of much use

I changed the higher default index number from 256 to 255, following the
change of meaning of the reverse parameters.

[Adrian Rossiter]

Hi Roger

On Fri, 1 Dec 2023, Roger Kaufman wrote:
> On 10/24/2023 2:34 AM, Adrian Rossiter wrote:
>> Perhaps kaleido, as Antiprism will make all its models.
>
> I removed kaleido and off2txt from antiprism_rk. I think i found all the
> places it is referred to, in doc_src, .gitignore and the gtm files

I have pushed all your changes. I added a followup commit to remove some
extra references to the programs.

[Roger Kaufman]

Hi Adrian,

On 12/5/2023 6:10 AM, Adrian Rossiter wrote:
> The resources page has a colour map section that is out of date. I
> removed
> the details of individual maps and referred to 'off_util -H col_map'
> instead. This help is also not fully up to date, as there are some maps
> supplied as files (e.g. 5x5x5) and in alt_names.txt which are not listed.
> You might want to review this.

I will do the shared maps in a separate push tomorrow. I do know there
are maps such as "jumble" that are no longer there. I'm not sure we need
all the ones that I put there and I will make a decision on those.

I will add something about the reverse map as well. It looks like
reverse can be used by itself and just generates reverse index number.

off_color -f U cube | antiview
off_color -f U cube -m reverse5 | antiview -m spread

I went through testing the programs and I did find one bug. For the
index map there as a segfault. I set the index map (with no N) in
base/planar.cc is how I found it. I don't think you wanted the second
term to be 'not' or it always fired. I pushed that change so you can
review it.

if (num_len || !specific_params_len)

I had to remove handling 'index' from off_color_radial as well. It
didn't make sense that I had that anyway. I've been trying different
shifts and steps to see how it relates to total N of a map .e.g this one
needs an N of 27 to cover all cells.

off_color -e white -v white geo_7_4_d | off_color_radial -m
rainbow27+8*3 | antiview -v 0.01

But I haven't been able to reverse it. If there's a logic to it, I can
control it, otherwise it is just something to do from the command line.

In n_icons I added another error to catch. I've been trying to tighten
up the parameter handling instead of having warnings and then unsetting
parameters to continue which is bad form.

Roger

[Adrian Rossiter]

Hi Roger

On Tue, 5 Dec 2023, Roger Kaufman wrote:
> I will add something about the reverse map as well. It looks like reverse can
> be used by itself and just generates reverse index number.
>
> off_color -f U cube | antiview
> off_color -f U cube -m reverse5 | antiview -m spread

That is right. The index, reverse, and deal maps are index-to-index maps.

> I went through testing the programs and I did find one bug. For the index map
> there as a segfault. I set the index map (with no N) in base/planar.cc is how
> I found it. I don't think you wanted the second term to be 'not' or it always
> fired. I pushed that change so you can review it.
>
> if (num_len || !specific_params_len)

Thanks. Yes, the 'not' needs removing!

> I had to remove handling 'index' from off_color_radial as well. It didn't
> make sense that I had that anyway. I've been trying different shifts and
> steps to see how it relates to total N of a map .e.g this one needs an N of
> 27 to cover all cells.
>
> off_color -e white -v white geo_7_4_d | off_color_radial -m rainbow27+8*3 |
> antiview -v 0.01
>
> But I haven't been able to reverse it. If there's a logic to it, I can
> control it, otherwise it is just something to do from the command line.

I might not have understood, but if you want to reverse the map then find
the last valid lookup entry (greatest idx where 8+idx*3<27), and step back
from it. However, in your example, because the shift is greater than or
equal to the step, you will have a map that is larger, although the
original entries will be reversed in their range

col_util -d 3 -m rainbow27+8*3 -Z 49 | antiview
col_util -d 3 -m reverse7,rainbow27+8*3 -Z 49 | antiview
col_util -d 3 -m rainbow27+26*-3 -Z 49

[Roger Kaufman]

Hi All,

Antiprism Addons Inaugural Event LoL

https://www.interocitors.com/polyhedra/antiprism_addons/index.html

Roger

[Roger Kaufman]

Hi Adrian,

On 12/5/2023 6:10 AM, Adrian Rossiter wrote:

> The resources page has a colour map section that is out of date. I
> removed
> the details of individual maps and referred to 'off_util -H col_map'
> instead. This help is also not fully up to date, as there are some maps
> supplied as files (e.g. 5x5x5) and in alt_names.txt which are not listed.
> You might want to review this.

I haven't pushed the changes to help.h yet so you can review this below.

I will remove the 5x5x5 and 5x5x5o maps. These maps were probably added
as a demonstration for col_util but they are not used in any examples.

I added an entry for reverse...

...
 index, remap
      A map of index numbers to themselves. Use with the map modifiers
      to remap index numbers. Does not accept a map size parameter.
 reverse
      A map of index numbers to themselves. Index number count down from a
      size parameter and once 0 is reached begins to count upward as
needed.
      (default: size 256)
 ...

The jumble map was removed early on because a random feature was added.
But I still have it somewhere. 5level became 5x5x5

grey16, grey64, grey256 are done programmatically

Is there a way to reversal mid range? I can't find any record of this
but it may have been discussed in the Yahoo group...
grey_wrap16, grey_wrap64, grey_wrap256
Grey scales running from black to white and back again.

"spectrum" is an interesting rainbow map. It is reversed and it runs
from deep violet to a darker red, and red is maxed out for a portion
col_util -d 3 -m spectrum -Z 401 | antiview
and there isn't an exact way to reproduce it as our rainbow's don't
start or end with deep violet. If there is a way to do it with
alt_names.txt I could make a rainbow such as this.
col_util -d 3 -m reverse401+80,rainbow401 -Z 401 | antiview

I think spectrum is another map I may have added as a col_util
demostration and I could remove it. For maps I remove I will add them to
an "extra maps package" on my site as I have other maps I have not
distributed.

Lastly there are the map in alt_names.txt which are not listed at all
(except rainbowc and rainbowg were). I have added a section as the
following. These maps actually produce some interesting shade varitions
so they are useful.

Color maps defined in alt_names.txt (in resource directory 'col_maps')
   pastel (224 colours)
       A rainbow map, with lighter colors
   darkened (224 colours)
       A rainbow map, with darker colors
   rainbowc (192 colours)
       A rainbow map, emphasises cyan and lacks green
   rainbowg (192 colours)
       A rainbow map, emphasises green and lacks cyan
   rgb_triangle (192 colours)
       Emphasizing primary colors that forms a triangle in a color cube
   cmy_triangle (192 colours)
       Emphasizing secondary colors that forms a triangle in a color cube
   hexagonal (192 colours)
       Color range that forms a hexagon in a color cube
   heptagonal (192 colours)
       A rainbow map, that adds extra shades of orange

More colour maps are available from Colorzilla Palettes:
http://www.iosart.com/firefox/colorzilla/palettes.html)";

Roger

[Roger Kaufman]

Hi Adrian,

Earlier I wrote...

> I've been trying different shifts and steps to see how it relates to
> total N of a map .e.g this one needs an N of 27 to cover all cells.
>
> off_color -e white -v white geo_7_4_d | off_color_radial -m
> rainbow27+8*3 | antiview -v 0.01
>
> But I haven't been able to reverse it. If there's a logic to it, I can
> control it, otherwise it is just something to do from the command line.

off_color_radial can now control N+shift*step

  -c s,t,n  control map stepping for calculated maps. integers greater
than 0.
              s - shift, t - step, n - map size (default: 1,1,(calculated))

for example

off_color -e white -v white geo_7_4_d | off_color_radial -m rainbow -c
3,5,34 | antiview -v 0.01

In this command the model needs 7 colors. If the number of colors needed
(N) is known then the minimum map size is

minimum map size = N + ((N-1) * (step-1)) + shift

map_size can be set to anything but if its lower then the minimum,
uncolored faces will result. If it is larger then other color ranges
will result.

using the 'reverse' map works in all cases and so that is now it is in
use in the program.

Roger

[Adrian Rossiter]

Hi Roger

On Thu, 7 Dec 2023, Roger Kaufman wrote:
> Antiprism Addons Inaugural Event LoL
>
> https://www.interocitors.com/polyhedra/antiprism_addons/index.html

Well done. I'll add a link in the Antiprism site/documentaion.

[Adrian Rossiter]

Hi Roger

On Thu, 7 Dec 2023, Roger Kaufman wrote:

> I haven't pushed the changes to help.h yet so you can review this below.

> ...
>  index, remap
>       A map of index numbers to themselves. Use with the map modifiers
>       to remap index numbers. Does not accept a map size parameter.
>  reverse
>       A map of index numbers to themselves. Index number count down from a
>       size parameter and once 0 is reached begins to count upward as needed.
>       (default: size 256)

It is a bit difficult to describe these in few words, without using maths.
I have suggested some changes below (including to the existing remap
help), but if these aren't clear then we could review this further.
A dedicated documentation page on colour maps, with some real use
examples, could help clarify what the maps do. I think I will add one in.

 index, remap
      Maps index numbers to index numbers. An index number is mapped to
the same number processed by the map modifiers. Does not accept a
map size parameter.
 reverse
      Maps index numbers to index numbers. The map reverses the order
of a sequence of index numbers, such that the numbers in a
specified range are mapped onto the same numbers in reverse order.
Takes one or two parameters (default: reverse256)
reverseN - reversal that maps 0 onto N-1 (reverses a map of size N)
reverseI:J - reversal that maps I onto J (reverses a custom range)

Also

deal
Maps index numbers to index numbers. The map (default: size 256)
contains a random shuffle of the values 0 to packsize-1, packsize
is the same as size by default, but can be changed by adding _packsize
(sequential deals are used if this is less than size), e.g. deal100,
deal_3

And

null
An empty colour map. Does not accept map modifiers or a map size
parameter.

> Is there a way to reversal mid range? I can't find any record of this but it
> may have been discussed in the Yahoo group...
> grey_wrap16, grey_wrap64, grey_wrap256
> Grey scales running from black to white and back again.

This is with the extra 'w'

col_util -d 3 -m greyw64 -Z 64 | antiview

[Roger Kaufman]

Hi Adrian,

On 12/9/2023 9:36 AM, Adrian Rossiter wrote:

A dedicated documentation page on colour maps, with some real use
examples, could help clarify what the maps do. I think I will add one in.

I used your texts. Having an example page would be helpful as the situations can get a little complex.

I was trying these commands thinking that the second map was appended to the first map. But the behavior is that all maps start from 0, so the first map overwrites the second.
Seeing how the system is supposed to work, it is expected behavior, but I didn't intuit it.

col_util -d 3 -m grayw100,rainbow50 -Z 256 | antiview
col_util -d 3 -m rainbow50,grayw100 -Z 256 | antiview

map files in share/col_maps have numbered indexes. I'm not sure these are needed or perhaps not even desired. They can work without them. I can remove them if needed. An example is

0 = 255 250 250     # snow
to
255 250 250     # snow

Is there a way to reversal mid range? I can't find any record of this but it may have been discussed in the Yahoo group...
grey_wrap16, grey_wrap64, grey_wrap256
Grey scales running from black to white and back again.

This is with the extra 'w'

   col_util -d 3 -m greyw64 -Z 64 | antiview

I glossed right over that. I have added it to off_color_radial. 'spread' works to. Any map that can take an N+shift*step will work. (I suppose even reverse itself would work!)

This text is at the top of alt_name.txt. It should go in the help somehow. In general we don't have examples in the help file but I can describe this.

# map files are of fixed length. but the maps can be repeated via the command
# structure shown in the example:
# off_color -f U geo_12 -m index%224,heptagonal | antiview -x ve
# off_color -f U geo_12 -m index%192,rainbowg | antiview -x ve
# col_util -M rgb -m hexagonal*32 | antiview -v 0.02

Wrapping can be done but it is different. The index% modifier will work with any map of course.

col_util -d 3 -m rainbowc -Z 256 | antiview
col_util -d 3 -m rainbowc% -Z 256 | antiview
col_util -d 3 -m index%192,rainbowc -Z 512 | antiview

I think the map sizes in alt_names.txt should be larger. rainbowc*32 will give 6 colors. But as step gets small, the number of colors rises quickly. I will review this next.

col_util -d 3 -m rainbowc*32 | antiview
col_util -d 3 -m rainbowc*4 | antiview
col_util -d 3 -m rainbowc*2 | antiview

Note: shift, step and map_size can all be 0. I've changed to accept 0's in off_color_radial. (before the lowest manual shift was 1 which was wrong). Having all zero's will just color with the first map color but that is expected behavior.

  -c s,t,n  control map stepping for calculated maps. positive or 0.
              s - shift, t - step, n - map size (default: 0,1,(calculated))

Roger

[Roger Kaufman]

Hi Adrian,

On 12/9/2023 10:37 PM, Roger Kaufman wrote:
> This text is at the top of alt_name.txt. It should go in the help
> somehow. In general we don't have examples in the help file but I can
> describe this.

I think this description works:

These color maps are of fixed size. If one wants less color, the step
operator
can be used. e.g. pastel*32 give 7 colors. Wrapping is done using the index
modifier. e.g. index%7,pastel*32, would wrap these seven colors. To wrap the
entire map would be done as index%224,pastel.


In the help you have

"A map may be given by several maps separated by ',' e.g. 'map1,map2'.
The maps are tried in order until a conversion is found for an index
number"

So I figure there is a way to use two maps in succession somehow.

I agree, an example page would be very helpful!

Roger

[Adrian Rossiter]

Hi Roger

On Sun, 10 Dec 2023, Roger Kaufman wrote:
> On 12/9/2023 10:37 PM, Roger Kaufman wrote:
>> This text is at the top of alt_name.txt. It should go in the help somehow.
>> In general we don't have examples in the help file but I can describe this.
>
> I think this description works:
>
> These color maps are of fixed size. If one wants less color, the step
> operator
> can be used. e.g. pastel*32 give 7 colors. Wrapping is done using the index
> modifier. e.g. index%7,pastel*32, would wrap these seven colors. To wrap the
> entire map would be done as index%224,pastel.

Maybe, "To create a similar map with fewer color entries, the step
operator can be used...".

> In the help you have
>
> "A map may be given by several maps separated by ',' e.g. 'map1,map2'.
> The maps are tried in order until a conversion is found for an index
> number"

I will change this to, "The maps are tried in order until an index
number is successfully converted to a colour value".

> So I figure there is a way to use two maps in succession somehow.

If, after a map, the index numbers are shifted back by the map size,
then the next map will effectively follow this map

col_util -d 3 -m greyw64,index+-64,vga,index+-16,greyw32,index+-32,vga -Z 256 | antiview

[Adrian Rossiter]

Hi Roger

You can also create greyw64 from two copies of grey32

col_util -d 3 -m greyw64 -Z 256 | antiview
col_util -d 3 -m grey32,index+-32,reverse32,grey32 -Z 256 | antiview
col_util -d 3 -m grey32,reverse32:63,grey32 -Z 256 | antiview

[Adrian Rossiter]

Hi Roger

On Sat, 9 Dec 2023, Roger Kaufman wrote:
> map files in share/col_maps have numbered indexes. I'm not sure these are
> needed or perhaps not even desired. They can work without them. I can remove
> them if needed. An example is
>
> 0 = 255 250 250     # snow
> to
> 255 250 250     # snow

The index numbers in the model to be coloured may have a meaning, so it
can be useful to have the index numbers appear in the map file, to easily
know what colour will be used for an element. Also, if a map does not have
sequential entries, then specifying index numbers in the map file allows a
map to have gaps.

However, if a map contains all sequential entries and is also less likely
to be used for specific index mapping, then including the index numbers
in the map file will be less useful.

[Roger Kaufman]

Hi Adrian,

From you recent notes

On 12/10/2023 12:47 PM, Adrian Rossiter wrote:
>> So I figure there is a way to use two maps in succession somehow.
>
> If, after a map, the index numbers are shifted back by the map size,
> then the next map will effectively follow this map
>
>    col_util -d 3 -m
> greyw64,index+-64,vga,index+-16,greyw32,index+-32,vga -Z 256 | antiview

There it is. I was trying things things like that but didn't have the
right numbers. That or something similar would be a good example.

> You can also create greyw64 from two copies of grey32
>
>    col_util -d 3 -m greyw64 -Z 256 | antiview
>    col_util -d 3 -m grey32,index+-32,reverse32,grey32 -Z 256 | antiview
>    col_util -d 3 -m grey32,reverse32:63,grey32 -Z 256 | antiview

Reversing maps similar to greyw could almost be a macro with arguments
of map name and N

col_util -d 3 -m rainbow32,index+-32,reverse32,rainbow32 -Z 64 | antiview

> The index numbers in the model to be coloured may have a meaning, so it
> can be useful to have the index numbers appear in the map file, to easily
> know what colour will be used for an element. Also, if a map does not
> have
> sequential entries, then specifying index numbers in the map file
> allows a
> map to have gaps.

They are sequential. But the index number cause no harm and show the
number of rows there are. I didn't change any of them.

My comment from earlier

> I think the map sizes in alt_names.txt should be larger. rainbowc*32
> will give 6 colors. But as step gets small, the number of colors rises
> quickly. I will review this next.

I decided to make the maps 10 time larger. Now rainbowc*320 would give 6
color. Its a little more flexible and the map can color larger models
with unique colors before having to wrap.

I pushed the changes discussed in these latest notes. The 5x5x5 maps
have been removed.

Feel free to edit the help.h color map section as you see fit.

Roger

[Roger Kaufman]

Hi Adrian,

I've completed the n_icons compound calculation for all model
variations. The numerical patterns were fairly easy until I got to
hybrids of d mod 4 and then it got complicated.

For hybrids, twist needed to be advanced by a factor similar to how it
is advance by 1 when d = 1 (the original model cases before n/d polygons
were introduced).

For non-hybrid cases:
t_mod is the same as with surface counts, no calculation is needed
For hybrid cases:
d is odd: t_mod = d/2
d is even, not d mod 4: t_mod = (de - 2) / 4
d is even, d mod 4: (a calculation depending on d, a sequence which can
be generated by the python below)

The calculation would be wrong with twist + (a modifier to advance the
sequence) would yield a twist 0 which hybrids don't have. In any other
instance I haven't had to compensate for this. The answer was to use a
previous twist T.

I mention what a "case 2" twist is on this page. It is when a surface
color pattern can be derived by taking an earlier twist of the same
pattern and twisting by T where T is the number of surfaces at that
twist. At the time of the study, I was only interested in models where
there were more than one surfaces (or had multiple colors).

https://www.interocitors.com/polyhedra/n_icons/Hybrid/index.html

But technically any model where T > 1 is a case 2 twist, since even
models with one surface (one color) could be twisted by using twist 1's
single coloring. What this means is that instead of using a twist T,
twist could be substituted by the number of surfaces.

This almost worked. I was only doing the substation for when twist plus
the modifier yielded a twist 0. It was working for n = 1-200, d = 1-200
and I thought I had solved it. Then when I increased the range to 300,
the hybrid case 288/96 broke the paradigm. It had multiple errors in the
sequence outside the twist 0 case. What ended up working was to
substitute number of surfaces as a starting point for twist number in
ALL cases. This I didn't anticipate could work.

This leads me to believe there might be a general relationship between
number of surfaces and number of compound in a model. I will look into
this in the future but right now I'm going to rest on this and work on
other things.

Now a command to list compound counts is very fast, when before for
hybrids with d mod 4, I was making a small model and counting the
compounds by brute force.

n_icons -L h -N 300 -D 250 -J -B -K 1,1000

With large models, I've gone to a -l of 9 but in some cases I still get
coloring errors from the lookup of color on the polygon, usually just a
few faces. I was thinking of making function to "heal" those areas based
on adjacent face color.

Instead a more general solution would be to have a utility which would
take an input color and color by a range of element numbers, or to take
a color from another face number and apply that. I think this general
ability to could be useful. I can put the program into the addons or it
could be placed in general Antiprism if you want.

Roger

Special t_mod sequence mentioned above. Interesting note, when d is a
power of two, t_mod is 0.

#!/usr/bin/python3

import os
import sys

d = int(sys.argv[1])

#d_top = 1608 (original value worked)
d_top = d
if (d_top % 8 != 0):
  d_top += 4

answer = 0

for de in range(4, d_top+4, 4):
  t_mod = int((d_top-4)/8);
  for k in range(d_top-4, 8, -8):
    if (de % k == 0):
      break
    t_mod -= 1;

  # try mod 8 or mod 12
  if (de % 4 == 0):
    print('de = %d t_mod = %d' % (de, t_mod));
  if (de == d):
    answer = t_mod

print('\nAnswer is %d' % answer)

[Roger Kaufman]

Hi Adrian,

On 12/25/2023 7:57 AM, Roger Kaufman wrote:
> With large models, I've gone to a -l of 9 but in some cases I still
> get coloring errors from the lookup of color on the polygon, usually
> just a few faces. I was thinking of making function to "heal" those
> areas based on adjacent face color.
>
> Instead a more general solution would be to have a utility which would
> take an input color and color by a range of element numbers, or to
> take a color from another face number and apply that. I think this
> general ability to could be useful. I can put the program into the
> addons or it could be placed in general Antiprism if you want.

It will probably be February before I can do anymore coding. But I was
looking at this feature we could add.

Coloring individual faces of a geom and off_color is somewhat setup to
do it already. If it had logic like the selection for delete_elements()
in off_util, elements could be specified to be colored.
restore_orig_colors would set all other elements colors back to what
they were.

The idea of specifying a color based on a current element's color is
better applied by the already proposed 'params_from_geom' which should
probably be written as a c++ program.

Did you any other idea of how coloring individual elements might work?

Roger

[Adrian Rossiter]

Hi Roger

On Wed, 10 Jan 2024, Roger Kaufman wrote:
> On 12/25/2023 7:57 AM, Roger Kaufman wrote:
>> With large models, I've gone to a -l of 9 but in some cases I still get
>> coloring errors from the lookup of color on the polygon, usually just a few
>> faces. I was thinking of making function to "heal" those areas based on
>> adjacent face color.
>>
>> Instead a more general solution would be to have a utility which would take
>> an input color and color by a range of element numbers, or to take a color
>> from another face number and apply that. I think this general ability to
>> could be useful. I can put the program into the addons or it could be
>> placed in general Antiprism if you want.
>
> It will probably be February before I can do anymore coding. But I was
> looking at this feature we could add.
>
> Coloring individual faces of a geom and off_color is somewhat setup to do it
> already. If it had logic like the selection for delete_elements() in
> off_util, elements could be specified to be colored. restore_orig_colors
> would set all other elements colors back to what they were.

...

> Did you any other idea of how coloring individual elements might work?

If it isn't something that is commonly needed, then maybe you could
colour the elements in a copy of the geometry, select the elements
of interest with off_util -K, and finally merge and prefer the colours
from the modified copy, which is essentially what you are suggesting
as code

E.g, Make a red elongated dipyramid, then colour the elogation faces blue.

polygon dip -s e 16 | off_color -f red > model.off
off_color -f blue model.off | off_util -K f0-15 | off_util - model.off -M a,f | antiview -R -90,0,0

I have been reviewing and expanding the colour map documentation, and
will push something soon.

[Roger Kaufman]

Hi Adrian,

On 1/11/2024 1:07 PM, Adrian Rossiter wrote:
> E.g, Make a red elongated dipyramid, then colour the elogation faces
> blue.
>
>    polygon dip -s e 16 | off_color -f red > model.off
>    off_color -f blue model.off | off_util -K f0-15 | off_util -
> model.off -M a,f | antiview -R -90,0,0

This sound like a python utility. I will see what it can do when I get back.

The off_query wrapper might be a python system (I keep going back an
forth on python or c, but the python core of this is already working).
Some items of interest could be in off_report. They can be parsed but I
think I will only add items from off_report as needed or requested.

> I have been reviewing and expanding the colour map documentation, and
> will push something soon.

If there is anywhere I need to change code let me know. Most of the code
is uniform in regard to coloring now so it should be easy.
off_color_radial does some acrobatics with maps though.

Roger

[Roger Kaufman]

Hi Adrian,

In this iteration, I had added an options to tetra59, -g...

-g        allow pairs outside regge group

This affected the -L listing and the -p option. Thinking about this
more, it is not a good idea. The pair of models will have the same
dihedral angle but the edge lengths will be different. First I thought
of making a note in the help about it, but in general it has not useful
and is misleading.

I removed the -g option, but the (also new) -P option allows forcing a
pair which will demonstrate the same thing. I don't think any actual
pairs would be found outside Regge groups but one could try.

With the -P option it is possible to display a tetrahedron with its own
alternate form which is useful (comparing a&b, c&d, e&f) e.g.

tetra59 14 -d a -P 14,b | antiview


Also, the tetra59 help had errors. e.g. tetra59 -L deg should have been
tetra59 -L d. Somehow the help examples script didn't find this, or it
was perhaps skipped because it doesn't produce a model.


I also updated the NEWS to note that n_icons compound counts can now be
correctly calculated for all n/d.

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 29 Jan 2024, Roger Kaufman wrote:
> Also, the tetra59 help had errors. e.g. tetra59 -L deg should have been
> tetra59 -L d. Somehow the help examples script didn't find this, or it was
> perhaps skipped because it doesn't produce a model.

I received an email report that Michael was written Mechael in
the tetra59 help (and I see also in the leading program description
comment).

Adrian.
--
Adrian Rossiter - adr...@antiprism.com
http://www.instagram.com/adrian_rossiter
http://antiprism.com/adrian

[Roger Kaufman]

Hi Adrian,

On 1/30/2024 12:52 PM, Adrian Rossiter wrote:
> I received an email report that Michael was written Mechael in
> the tetra59 help (and I see also in the leading program description
> comment).

I hope the report wasn't from Micheal, lol

I fixed this and pushed. It was also misspelled in the examples file. I
had copied the error everywhere and a result it was spelled wrong in the
last iteration.

> Also, the tetra59 help had errors. e.g. tetra59 -L deg should have
> been tetra59 -L d. Somehow the help examples script didn't find this,
> or it was perhaps skipped because it doesn't produce a model.

It wasn't found because if the last iteration it allowed partial matches
so "deg" would work. When I added the 3rd option I made it so only the
first letter is used

-L <opt>  list Sporadic Tetrahedra as i - integer, d - degrees, p - pairs

Roger

PS I looked at what -g was doing and I'm glad I removed it. I took the
opportunity to obliterate all remnants completely.

[Toby Kelsey]

I notice that with some asymmetric polyhedra, the centre of the display and also rotation centre in antiview is not near
the centre of the bounding box  or "centre of mass" of the polyhedron but rather at one end. Also surprisingly the "-C"
and "-L" options do not seem to change this.

I am attaching an example .off file and screenshot.

Regards,

Toby

[Adrian Rossiter]

Hi Toby

Thanks for the report!

The default model centre is the centre of a bounding sphere. As your
model is dome-like then this point will be near the base rather than
more "interior" to the model.

The -C and -L options are working for me with your model. E.g. Rotate
around the apex but look somewhere else

antiview -C 1,1,1 -L 1,-3,1 climbingframe.off

If you wish to centre viewing on the vertex centroid then

off_trans -C climbingframe.off | antiview -C 0,0,0

The viewing centre used to be the vertex centroid, but this gave
unsatisfactory results for some models, especially where there were
coincident vertices. If a bounding box centre is used, and if the box
is aligned with the coordinate axes, then the model centre can change
when the model is rotated before viewing. The bounding sphere centre
gives consistent results, but does not always correspond to the
general idea of a centre point.

If viewing parameters are critical then it is best to set them
specifically. I have often found when making animations of transformations
that using defaults leads to visible wobbles in the animation.

[Toby Kelsey]

On 05/02/2024 09:00, Adrian Rossiter wrote:
>  off_trans -C climbingframe.off | antiview -C 0,0,0

Thanks Adrian, that works and

  antiview -C -2,-2,-2 climbingframe.off

is also close to what I want.  Not sure why I couldn't get it working before.


I also notice there are visible anti-aliasing artifacts on thin/minimal edges during slow spinning. Are there any
options that can change this?


Toby

[Adrian Rossiter]

Hi Toby

On Mon, 5 Feb 2024, Toby Kelsey wrote:
> I also notice there are visible anti-aliasing artifacts on thin/minimal edges
> during slow spinning. Are there any options that can change this?

There are no options for anti-aliasing within antiview, and the onscreen
image can look a bit rough!

When I want make nice images or animations then I export the model using
off2pov, and set the POV-Ray antialiasing option when rendering. There
is an example script for creating a spinning polyhedron here

https://github.com/antiprism/antiprism/blob/master/share/extras/python/anim_spin.py

All the images and animations on the Antiprism site were produced
using POV-Ray.

[Toby Kelsey]

I am learning how to use the antiview programs and currently am trying to merge some overlapping faces. The program and
options to to do this would seem to be 'planar -d 1' however I can't get this to work with my example (attached).  Do I
need to specify some face splitting or vertex options as well?


Regards,

Toby

[Roger Kaufman]

Hi Toby,

And welcome to the forum.

You are probably doing it right. The compound has no color so there is
no obvious change. But if we color the compound first and then run
planar -d tile the octagons have blended colors (are are new faces).

off_color -f K compound-2-rhombic-triacontahedra.off | planar -d tile |
antiview

One way to see that it works without coloring would be to display the
faces numbers. First display the face numbers without tiling and it can
be seen that the squares have individual face numbers.

off_util compound-2-rhombic-triacontahedra.off | antiview -n f

After blending the new octagons will have one face number and the new
surrounding 4-gon's (called darts) have their own face number.

off_util compound-2-rhombic-triacontahedra.off | planar -d tile |
antiview -n f

And if you color the tiled output afterwards they will get individual
colors.

off_util compound-2-rhombic-triacontahedra.off | planar -d tile |
off_color -f U | antiview

Interesting compound.

Roger

[Roger Kaufman]

Hi Adrian,

I have no immediate plans for any more updates to code, if you are ready
to make a new release.

Looking at what is left in my list, most of it is new and not started,
and I'd develop anything in my space first before proposing it for
antiprism.


One long standing desire was to be able to to unions and intersections
on polyhedra. I've downloaded and built the (now unmaintained) polylib
code but I've never gotten farther than that. Their code seems to have a
unique approach to polyhedra definitions.

Today I saw there is a currently maintained library system here
https://www.cgal.org/  I noticed they have code for 3D convex hulls
among other things that we use.

Roger

[Toby Kelsey]

| off_color -f K compound-2-rhombic-triacontahedra.off | planar -d tile | antiview

Thanks Roger I can see that works, and it also shows that the faces are intersecting. Is there also a tool or command to
split intersecting faces into non-intersecting ones with additional vertices?


Cheers,

Toby

[Roger Kaufman]

Hi Toby,

I think that would mean the -d merge option instead.

Here I added a couple things, the first being to color the edge and
vertices based on the compound. Then with the planar command I color the
new edges and vertices that will have blended colors. The off_util -x E
is in case there are any disconnected edges left over, but in this case
there are not.

off_color -f K compound-2-rhombic-triacontahedra.off -e F -v F | planar
-d merge -E V | off_util -x E | antiview

One thing to note is that neither the tiled or merged for are any longer
valid polyhedra. Either some faces don't connect or their are more than
2 faces at some edge connections.

Roger

[Adrian Rossiter]

Hi Roger

On Wed, 20 Mar 2024, Roger Kaufman wrote:
> I have no immediate plans for any more updates to code, if you are ready to
> make a new release.

I am still very tied up, but I will see if I can put out a release to
share your changes in May or June.

> Today I saw there is a currently maintained library system here
> https://www.cgal.org/  I noticed they have code for 3D convex hulls among
> other things that we use.

I looked at CGAL a while back, and it does contain a lot of interesting
features. However, the library includes GPL as well as LGPL code, and
any binary that links to it and is distributed must also have its code
distributed under a GPL-compatible licence.