Is the 'g' operator working right?

[huttarl]

If I try 'gC', and compare the result with https://en.wikipedia.org/wiki/Conway_polyhedron_notation#/media/File:Pentagonalicositetrahedronccw.jpg, they don't really look the same.
In polyhedronisme the pentagons aren't totally planar.
The same is true of 'pC' and https://en.wikipedia.org/wiki/Conway_polyhedron_notation#/media/File:Propellor_cube.png

I read what you wrote in #2 about producing non-flat faces, and maybe this is the same problem.
I also tried 'eptI' to reproduce http://www.georgehart.com/sculpture/roads-untaken.html, but the result was far from convex, and hard to recognize as being the same figure.
However, putting in the convex spherical adjustment a couple of times, e.g. recipe 'AeA3ptI', gives a beautiful result.

So I guess I'm wondering, when you say "In the code I separated the topological operators from the geometrical operators, such that you can get meshes that have non-flat faces," do you mean that 'g' and 'p' are topological operators ... and that it's not always possible for them to produce flat faces? Are the wikipedia images I linked to above "cheating" somehow in that they have flat faces? Or is it easy to do in a single instance but hard to do in general?

[levskaya]

Sorry for the confusion, the "g" and "p" and other topological operators just change the mesh in a very simple way to produce the new mesh, without relaxing the resulting mesh to make it a convex polyhedron. I did this mainly to allow for wackier non-traditional meshes that require some custom tweaking, which wouldn't be possible to achieve if I automatically enforced convexity with every operation. To get the classical polyhedra, you just need to apply the "convexification" operator C (C[N] runs the C operator N times). For instance:

• instead of 'gC', try ' C300gC ', this builds the 'gC' mesh and then does 300 convex relaxation cycles to have it converge to the canonical gC polyhedron. (it's very fast to run the C operator, so this is fine)
• instead of ' eptl ' if I do ' C300eC200pC200tI ' then I get a figure similar to George Hart's.

The 'A' operator does convexification as well but with a much more direct route that doesn't need as many iterations, however for some meshes it is highly unstable, so the slower, safer 'C' operator was provided as well to help guarantee convergence for some weirder meshes. ('K' was an operator borrowed from older code that really should never be used as it's not stable.)

My apologies if these geometric operators weren't obvious - I was trying to allow for as much freedom as possible in controlling the final mesh result, as opposed to making just the traditional polyhedra easy to arrive at. Just let me know if you have any other questions.

[huttarl]

Thanks for the explanations ... this helps. C300gC and C300pC work great! I had tried the CN operator, but hadn't tried beyond about N=3. I guess that's why it didn't seem to have much effect! I wasn't sure whether "slower" meant that more iterations of C were required to get the job done, or that each iteration took more CPU time. Now I understand.

Regarding eptI, when I try C300eC200pC200tI, it's certainly recognizable (and correct, I don't doubt), but AeA3ptI looks better and more like George Hart's, with the faces being much more even in size. It's good to know about C, though, in case A blows up.

While I'm here let me say how much I appreciate this tool. I had been searching for some cross-platform (preferably web-based), interactive, free tool for experimenting with successive application of operators on polyhedra, especially one that would allow export of the geometry in an open format. I couldn't find one, and started building one. Then I stumbled across polyHédronisme. It's a huge timesaver and a Godsend. And it just goes to show that when something doesn't show up in the first pages of Google results, that doesn't mean it isn't there! :-)

If you're open to a pull request, I'd be happy to draft some elaborations to the explanatory text on the web page, that would help people like me be able to use the tool successfully, with less confusion.

[levskaya]

Well, I'm very happy that you're getting so much use out of it. I would happily accept any pull request that sought to clarify any of my ambiguous language! The webpage text itself is just dead-standard static HTML.

I agree that when "A" works it tends to produce more pleasing symmetry than "C" - that's because the former uses spherical reciprocation to adjust the coordinates as opposed to iterative planarization.

Note that if you export geometry the absolute scale is set somewhat arbitrarily for small figurines for 3d printing, probably too small, you'll want to scale the models to suite whatever needs you have. I should probably add a scale input for the export options. Overall, there's a number of improvements that could be made to the code. If I ever get enough free time I should really make a newer version of the web tool with a WebGL frontend. I'm currently trying to finish a C++ implementation of some of the code for live animations and might one day backport some the opengl code to webgl.

[huttarl]

I've forked the code and started some modification of index.html, but it looks like there are several differences between what's deployed at http://levskaya.github.io/polyhedronisme/ and what's in the master repo's HEAD. E.g. the former has the "more complicated, parameterized forms for k and n", and the latter doesn't. The latter has "a space-delimited series" of recipes, and the former doesn't. So I'm not sure whether I'm modifying the most recent version or something out of date. I'll still submit a pull request, but I hope I'm not tangling things up by modifying an older version.

[huttarl]

Submitted pull request #4

[levskaya]

Hey - sorry about that. The way you host static pages on github is to have a 'gh-pages' branch in your repo that is automatically served. I must have edited the documentation in that branch without merging it back into master. I accepted your pull request and merged in the old edits on the gh-pages branch to bring it all together. (The two html files are now identical with the sole exception of the served version pointing to a minified version of the js files.)

[huttarl]

Great - thanks. I'll go ahead and close this issue.
One thing I still notice is that the page says "a space-delimited series of polyhedral recipes," but when I try a series like "T C", the only result I see is that of the first recipe in the series. Not sure if this was a feature that was in planning stages and not yet implemented, or something got lost in merging, or what.