Loading ...
Sorry, an error occurred while loading the content.

Re: moving forward

Expand Messages
  • Alan M
    ... are blended together. You can also see where two or three pentagrams are blended. ... It seems to look somewhat yellowish. ... and down on the B. It seems
    Message 1 of 15 , Mar 1, 2011
    View Source
    • 0 Attachment

      --- In antiprism@yahoogroups.com, "Roger Kaufman" <vortexswirling@...> wrote:

      > Hi Alan,

      > > > http://www.interocitors.com/tmp/uc21_n5_2k4_tiled.wrl

      > > Tiled seemed to be four pentagrams (red, yellow, green, blue) that are blended together. You can also see where two or three pentagrams are blended.

      > The color of the central polygon is RGB 135 135 81

      It seems to look somewhat yellowish.

      > Since yellow is represented by 255 255 0 it pushes up on the R and G and down on the B. It seems to look somewhat greenish.

      
       255    000    000
      255    255    000
      000    255    000
      000    000    255
      And the answer is:
      128    128    064
      

      > > > http://www.interocitors.com/tmp/uc21_n5_2k4_merged.wrl
      > > Red + Yellow + Green + Blue all seem to be Merged into some gray.

      It's actually the same gray (that got tinted with the extra yellow).

      > It's actually the same color. It seems when surrounded by other colors, the tiled version looks a bit different.

      > > See the http://en.wikipedia.org/wiki/Natural_Color_System

      > I noticed they have a color identifier machine. I wondered if there was some apps for the Droid which will do the same thing. There are a few. Using the built in camera, a couple of them will speak the name of the color which it finds in a target area.

      > The natural color system looks interesting. I will have to look into it more.

      > Roger

    • Alan M
      There s more at http://tech.groups.yahoo.com/group/Polytopia/messages/641?threaded=1&m=e&tidx=1
      Message 2 of 15 , Mar 1, 2011
      View Source
      • 0 Attachment
        There's more at http://tech.groups.yahoo.com/group/Polytopia/messages/641?threaded=1&m=e&tidx=1

        --- In antiprism@yahoogroups.com, "Roger Kaufman" <vortexswirling@...> wrote:
        >
        > Hi Alan,
        >
        > > See the http://en.wikipedia.org/wiki/Natural_Color_System
        >
        > I noticed they have a color identifier machine. I wondered if there was some apps for the Droid which will do the same thing. There are a few. Using the built in camera, a couple of them will speak the name of the color which it finds in a target area.
        >
        > The natural color system looks interesting. I will have to look into it more.
        >
        > Roger
        >
      • Roger Kaufman
        Hi Alan, ... It took me a while to figure out what was going on here! Clearly the averages were different than expected. (In the meantime I found bugs in other
        Message 3 of 15 , Mar 2, 2011
        View Source
        • 0 Attachment
          Hi Alan,

          > > Since yellow is represented by 255 255 0 it pushes up on the R

          > And the answer is: 128 128 064

          It took me a while to figure out what was going on here! Clearly the averages were different than expected. (In the meantime I found bugs in other places so no time was wasted)

          The difference was that I have the program set to blend using HSL. If I use RGB I get 128 128 64 for the blended color.

          http://www.interocitors.com/tmp/uc21_n5_2k4_tiled_using_rgb.wrl

          In the above model I used the 0 255 0 green to test the blend

          My choice of default green is not 0 255 0. Instead I use darkgreen which is 0 100 0. I do this because I have always been used to green the color of grass and leaves and so on.

          The other factor is that I wanted my choice of green to have an X11 name. Ideally I would have liked it to be 0 127 0. However darkgreen was there at 0 100 0. The only other color close to that which has 0 in the red and blue positions was green4 at 0 139 0.

          I have thought about putting it in as map_0/127/0. The the help text would have an example of setting rgb color. (this would only affect n_icons and conway)

          For comparison here is the previous model with the darkgreen used. (It was blended with HSL so the average is not compariable)

          http://www.interocitors.com/tmp/uc21_n5_2k4_tiled.wrl

          Roger

          P.S. X11 does furnish the value of darkorange1 as 255 127 0 which I commonly use for orange.
        • Roger Kaufman
          Hi Adrian, ... This speed up was fairly effective but there should be a better improvement. It has to traverse geom.edges() quite often. In the higher order of
          Message 4 of 15 , Mar 2, 2011
          View Source
          • 0 Attachment
            Hi Adrian,

            > The face creation part uses map lookups which are known to be a bit slow. It was checking to see if a turn ABC had been traversed once (CBA would be a separate traversal). Instead it could store edge traversals AB,BC,CB,BA. Then it is possible to bail out if for example AB has been traversed then BC need not be tested. This resulted in a bit of savings.

            This speed up was fairly effective but there should be a better improvement.

            It has to traverse geom.edges() quite often. In the higher order of polygons that overlap the more it is traversed. For UC21_n5/2k15 it iterates over a million times.

            I was thinking rather than use a map to keep track of usage I might instead erase the used edges from a vector list. The problem is it would have to look up which edge was used and erase it, so the number of traversals it the same. Even a linked list would still have to know what edges to skip.

            It would improve somewhat to keep track of the first unused edge and start the traversal from there.

            > Finding if a point is in a polygon is the most costly at this point. I am wondering if a sum-of-angles solution might work faster. Paul Bourke has these listed as solution 2 and 4 on his page.
            >
            > http://paulbourke.net/geometry/insidepoly/

            I never looked closely at these algorithms. What was developed for planar seems to be in a class by itself. It only works with triangles and so a polygon that is triangulated into many parts creates more complexity.

            According to methods 1 and 2 on the Bourke page they work on nonconvex whole polygons. This would be much less costly I think. I will develop both algorithms and compare them to the one that exists and get some real numbers.

            Roger
          • Roger Kaufman
            Hi Adrian, ... This is a worthy update. When generating uc21_n5/2k15 the 5/2k15 polygon iterated through polygon.edges() 2,928,940 time. After starting the
            Message 5 of 15 , Mar 2, 2011
            View Source
            • 0 Attachment
              Hi Adrian,

              > It has to traverse geom.edges() quite often. In the higher order of polygons that overlap the more it is traversed. For UC21_n5/2k15 it iterates over a million times.
              >

              > It would improve somewhat to keep track of the first unused edge and start the traversal from there.

              This is a worthy update. When generating uc21_n5/2k15 the 5/2k15 polygon iterated through polygon.edges() 2,928,940 time.

              After starting the first unused edge the iteration count is now 5529.

              Now to concentrated on the point in polygon problem and planar should become fairly efficient.

              Roger
            • Alan M
              ... averages were different than expected. (In the meantime I found bugs in other places so no time was wasted) ... I use RGB I get 128 128 64 for the blended
              Message 6 of 15 , Mar 2, 2011
              View Source
              • 0 Attachment

                --- In antiprism@yahoogroups.com, "Roger Kaufman" <vortexswirling@...> wrote:

                > Hi Alan,

                > > > Since yellow is represented by 255 255 0 it pushes up on the R

                > > And the answer is: 128 128 064

                > It took me a while to figure out what was going on here! Clearly the averages were different than expected. (In the meantime I found bugs in other places so no time was wasted)

                > The difference was that I have the program set to blend using HSL. If I use RGB I get 128 128 64 for the blended color.

                > http://www.interocitors.com/tmp/uc21_n5_2k4_tiled_using_rgb.wrl

                #FF0000 + #FFFF00 + #00FF00 + #0000FF = #808040

                > In the above model I used the 0 255 0 green to test the blend

                > My choice of default green is not 0 255 0. Instead I use dark green which is 0 100 0. I do this because I have always been used to green the color of grass and leaves and so on.

                Most leaves are a darker shade of green.

                > The other factor is that I wanted my choice of green to have an X11 name. Ideally I would have liked it to be 0 127 0. However dark green was there at 0 100 0. The only other color close to that which has 0 in the red and blue positions was green 4 at 0 139 0.

                > I have thought about putting it in as map_0/127/0. The the help text would have an example of setting rgb color. (this would only affect n_icons and Conway)

                > For comparison here is the previous model with the dark green used. (It was blended with HSL so the average is not comparable)

                > http://www.interocitors.com/tmp/uc21_n5_2k4_tiled.wrl

                #FF0000 + #FFFF00 + #006400 + #0000FF = #868650

                > Roger

                > P.S. X11 does furnish the value of dark orange 1 as 255 127 0 which I commonly use for orange.

              • Alan Michelson
                ________________________________ From: Alan M To: antiprism@yahoogroups.com Sent: Wed, March 2, 2011 7:32:27 PM Subject: [antiprism]
                Message 7 of 15 , Mar 14, 2011
                View Source
                • 0 Attachment

                  From: Alan M <amichelson2002@...>
                  To: antiprism@yahoogroups.com
                  Sent: Wed, March 2, 2011 7:32:27 PM
                  Subject: [antiprism] Re: moving forward

                   

                  --- In antiprism@yahoogroups.com, "Roger Kaufman" <vortexswirling@...> wrote:

                  > Hi Alan,

                  > > > Since yellow is represented by 255 255 0 it pushes up on the R

                  > > And the answer is: 128 128 064

                  > It took me a while to figure out what was going on here! Clearly the averages were different than expected.

                  They sure were!

                  (In the meantime I found bugs in other places so no time was wasted)

                  > The difference was that I have the program set to blend using HSL. If I use RGB I get 128 128 64 for the blended color.

                  > http://www.interocitors.com/tmp/uc21_n5_2k4_tiled_using_rgb.wrl

                  #FF0000 + #FFFF00 + #00FF00 + #0000FF = #808040

                  You used a lighter green, but got a darker gray!

                  > In the above model I used the 0 255 0 green to test the blend

                  > My choice of default green is not 0 255 0. Instead I use dark green which is 0 100 0. I do this because I have always been used to green the color of grass and leaves and so on.

                  Most leaves are a darker shade of green.

                  > The other factor is that I wanted my choice of green to have an X11 name. Ideally I would have liked it to be 0 127 0. However dark green was there at 0 100 0. The only other color close to that which has 0 in the red and blue positions was green 4 at 0 139 0.

                  > I have thought about putting it in as map_0/127/0. The the help text would have an example of setting rgb color. (this would only affect n_icons and Conway)

                  > For comparison here is the previous model with the dark green used. (It was blended with HSL so the average is not comparable)

                  > http://www.interocitors.com/tmp/uc21_n5_2k4_tiled.wrl

                  #FF0000 + #FFFF00 + #006400 + #0000FF = #868650

                  You used a darker green, but got a lighter gray!

                  > Roger

                  > P.S. X11 does furnish the value of dark orange 1 as 255 127 0 which I commonly use for orange.


                • Adrian Rossiter
                  Hi Roger ... This could be used for the surhedron. Find the polygons made by truncation at the same plane, merge and create the outer polygons. Now use the
                  Message 8 of 15 , Mar 17, 2011
                  View Source
                  • 0 Attachment
                    Hi Roger

                    On Fri, 25 Feb 2011, Roger Kaufman wrote:
                    > I thought of the 'merge' option after considering that from the tiling
                    > algorithm, one face is always the whole planar complex. That face, the
                    > so called retrograde face, is thrown away. I was wondering what would
                    > happen if instead, that was the only face retained and color blended
                    > accordingly.

                    This could be used for the surhedron. Find the polygons made by
                    truncation at the same plane, merge and create the outer polygons.
                    Now use the GLUtesselator to extract the face polygons with the
                    truncation polygons removed. However, it may be that it is generally
                    more efficient to use the triangle sets rather than the outer
                    polygons.

                    On a related note, I have had a look at removing the OpenGL
                    dependancy for the Antiprism library. SGI changed the licence
                    on their GLUtesselator code about three years ago, and so I
                    have added that in for the triangulation. Everything else
                    was only needed by antiview, so I have have split that code
                    out and put it in with the antiview source. I'll post about
                    this on antiprism_dev.

                    Adrian.
                    --
                    Adrian Rossiter
                    adrian@...
                    http://antiprism.com/adrian
                  • Roger Kaufman
                    Hi Adrian, ... Using the retrograde face works great for merging adjacent planar faces. Remember I once had an idea for de-triangulating a model? This seems
                    Message 9 of 15 , Mar 17, 2011
                    View Source
                    • 0 Attachment
                      Hi Adrian,

                      > > I thought of the 'merge' option after considering that from the tiling
                      > > algorithm, one face is always the whole planar complex. That face, the
                      > > so called retrograde face, is thrown away. I was wondering what would
                      > > happen if instead, that was the only face retained and color blended
                      > > accordingly.
                      >
                      > This could be used for the surhedron. Find the polygons made by
                      > truncation at the same plane, merge and create the outer polygons.
                      > Now use the GLUtesselator to extract the face polygons with the
                      > truncation polygons removed. However, it may be that it is generally
                      > more efficient to use the triangle sets rather than the outer
                      > polygons.

                      Using the retrograde face works great for merging adjacent planar faces. Remember I once had an idea for "de-triangulating" a model? This seems to be able to do the trick.

                      There is an issue with holes, which disappear doing this. They could actually be added back by identifying pro-grade polygons that were put in place where there is zero density. Zero density will occur when no underlying color is found for those facelets. I haven't looked at it yet, but it should be possible to add the holes back in.


                      The only other outstanding issue is the license text for the pnpoly code. I think our license is in keeping with his license text. It even looks like it can be put into commercial code.

                      http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html#License%20to%20Use

                      Roger
                    • Adrian Rossiter
                      Hi Roger ... That is fine. I thought it was BSD at first, but the end part looked like MIT. It could be the University of Illinois/NCSA Open Source License,
                      Message 10 of 15 , Mar 18, 2011
                      View Source
                      • 0 Attachment
                        Hi Roger

                        On Fri, 18 Mar 2011, Roger Kaufman wrote:
                        > The only other outstanding issue is the license text for the pnpoly
                        > code. I think our license is in keeping with his license text. It even
                        > looks like it can be put into commercial code.
                        >
                        > http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html#License%20to%20Use

                        That is fine. I thought it was BSD at first, but the end part looked
                        like MIT. It could be the University of Illinois/NCSA Open Source
                        License, with clause 2 edited so the full license doesn't need to
                        be included with a distributed binary (a web search on the clause 2
                        text finds very few hits)

                        http://en.wikipedia.org/wiki/University_of_Illinois/NCSA_Open_Source_License#Terms

                        Adrian.
                        --
                        Adrian Rossiter
                        adrian@...
                        http://antiprism.com/adrian
                      Your message has been successfully submitted and would be delivered to recipients shortly.