## Visualize using javaview app (for converting to STL format)

Questions and problems about using polymake go here.

Moderator: Moderators

ren
Posts: 25
Joined: 03 May 2011, 15:21

### Visualize using javaview app (for converting to STL format)

I really like that visualizations can be viewed in any browser using javaview. But is it also possible to create a file that can be opened by the javaview app? I would like to save the objects in STL format for 3d-printing.

Here is an example that I would be interested in printing, a faithful tropicalization of a plane quartic curve that cannot be faithfully tropicalized if embedded into the plane (because the edge lengths violates some inequalities in https://arxiv.org/abs/1409.4395):

Code: Select all

application "tropical"; $f = toTropicalPolynomial("max(y,z,w+0*x)");$Vf = new Hypersurface<Max>(POLYNOMIAL=>$f);$g = toTropicalPolynomial("max((-18)+4w+0z,(-6)+x+3w,2x+2w,(-24)+4x,(-11)+y+3w,x+y+2w,2x+y+w,(-8)+2y+2w,(-3)+x+2y+w,2x+2y,(-12)+3y+w,(-8)+x+3y,(-18)+4y)"); $Vg = new Hypersurface<Max>(POLYNOMIAL=>$g); $g1 = toTropicalPolynomial("max((-8)+4w+0y,x+3w,(-24)+4x,(-8)+z+3w,x+z+2w,(-2)+2x+z+w,(-8)+2z+2w,(-3)+x+2z+w,2x+2z,(-12)+3z+w,(-8)+x+3z,(-18)+4z)");$Vg1 = new Hypersurface<Max>(POLYNOMIAL=>$g1);$Vgg1 = set_theoretic_intersection($Vg,$Vg1); $Wgg1 = new Cycle<Max>(VERTICES=>thomog($Vgg1->VERTICES), MAXIMAL_POLYTOPES=>$Vgg1->MAXIMAL_POLYTOPES);$Vfgg1 = set_theoretic_intersection($Vf,$Wgg1); $Wfgg1 = new Cycle<Max>(VERTICES=>thomog($Vfgg1->VERTICES), MAXIMAL_POLYTOPES=>$Vfgg1->MAXIMAL_POLYTOPES); visualize_in_surface($Vf,\$Wfgg1);
P.S.: Here is the folder that is created by the visualization: https://www.dropbox.com/s/7dpll00ly0rbx ... r.bz2?dl=0

gawrilow
Main Author
Posts: 310
Joined: 25 Dec 2010, 17:40

### Re: Visualize using javaview app (for converting to STL format)

When you rewrite the last command in your sequence as

Code: Select all

javaview(visualize_in_surface(...), File=>"myfile"); 
you'll obtain a file myfile.jvx which you can later load into a standalone javaview process.
Is this sufficient for your needs or do you want to enrich the model with more data or decorations? If the latter, please tell the details.

In general, any visualization command in polymake can be wrapped in a similar way if one wants to save the graphics for custom post-processing, so the code example above is not constrained to this particular function visualize_in_surface or to javaview.

gawrilow
Main Author
Posts: 310
Joined: 25 Dec 2010, 17:40

### Re: Visualize using javaview app (for converting to STL format)

By the way, the archive you've uploaded to DropBox has not been created by javaview but a different visualization backend, namely threejs. Javaview has not been used at all in your session.

If you don't want to save the model file persistently and you have javaview installed on the same computer where you run polymake, you can omit the File option in the command and import into STL directly from the javaview process launched by polymake:

Code: Select all

javaview(visualize_in_surface(...)); 

joswig
Main Author
Posts: 209
Joined: 24 Dec 2010, 11:10

### Re: Visualize using javaview app (for converting to STL format)

Did you see that polymake has a backend to stl? It is implemented as a user method. You can use it like.

Code: Select all

dodecahedron()->write_stl("/tmp/dodecahedron.stl"); 

gawrilow
Main Author
Posts: 310
Joined: 25 Dec 2010, 17:40

### Re: Visualize using javaview app (for converting to STL format)

It is implemented as a user method
Why it's implemented in a non-standard way then? The function in user's request, visualize_in_surface, produces a composite picture consisting of several graphical elements, there is no chance to append any user method call to it. It should be possible to wrap it in a free function like write_stl(..., File=>"...").

joswig
Main Author
Posts: 209
Joined: 24 Dec 2010, 11:10

### Re: Visualize using javaview app (for converting to STL format)

Why it's implemented in a non-standard way then?
This was a rapid prototype, and it stayed like this since no-one cared.
Of course, it makes sense to adapt it to our general visualization backend structure.