The new WebGL output is very tempting as a modern replacement for the VRML I have been using, however the sheer size of the the generated code is disconcerting. Most of my models contain lots of unitspheres, which Asymptote turns into individual sets of eight Bezier patches each which makes for a rather lengthy output. This is already apparent in the 180kB WebGL resulting from cyclohexane.asy, with three of four times the number of spheres (and similar number of polyhedra and/or cylinders connecting them) the size easily approaches 600kB or more than ten times that of the correponding VRML.
(This may not sound much given typical ethernet bandwidths, but imagine several per page on an educational website that should stay usable in a congested wireless network or on a limited mobile data plan.)
Is there something I am missing here, or would it be possible to move the expansion of the (scaled) unitsphere
to the common asygl.js ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The newly released 2.63 version of Asymptote now generates sphere, disk, cylinder, and tube primitives that are rendered within the AsyGL library. This has reduced the cyclohexane.html
output file size from 184K to 5.7K. Thank you for the excellent suggestion. These primitives provide a foundation for the upcoming v3d vector graphics file format we are proposing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Why some proprietery v3d file format? Did you evaluate extending X3D with just your node, bezier patch with vertex colors? X3D has NURBS (but without vertex colors) and some WebGL viewers like x3dom or X_ITE have support for it, although rendering seems to be done once.
All other primitives you need are in X3D, I believe.
2) Where can I find AsyGL library source to try to understand how it works and evaluate the idea of makeing x3dom extension based on it?
3) Uphill battle of adding vertex color support to X3D NURBS node may be much more limited then pushing through an entirely new format. And X3D has already an ecosystem of tools.
Sicerely, Michail
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Michail, which propietary format do you mean, the quasi-internal .asy one ? I find it very easy to generate from my code, much like the original VRML. In my opinion X3D has been all but killed off by all the xml-ifications when all that is desired is a 3D visualisation. And WebGL has the added advantage of not requiring everyone to install some specialized viewer (that may even be hard to get for some platforms).
Source code is on github
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Martin,
"which propietary format do you mean, the quasi-internal .asy one" - no, I mean not Asymptote input format, but Asymptote output format.
"WebGL has the added advantage of not requiring everyone to install some specialized viewer (that may even be hard to get for some platforms)." - but on the other hands:
1) Now John has to make the viewer (in JS/WebGL code). As he had made his own OpenGL viewer originally. And he has to deal with platform chages himself, as he had to rewrite his OpenGL viewer in modern OpenGL.
2) Asymptote output can not be edited, translated to other format and joined with other 3D models in any practical way.
3) Long term use of 3D models that require for viewing a propietary tool (asygl.js library) mainained off-hours by one man team looks like no-go.
Declarative output in some recognized format solves that problems.
So John talks about "the upcoming v3d vector graphics file format we are proposing".
But pushing throuh formal standartisation and having other parties join in developing an ecosystem for entirely new format looks much harder than extending an existing format.
"Source code is on github" - but all asygl.js code there is merged in one long line. :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, maybe you are trying to solve an entirely different problem. And WebGL is just one of several output formats supported by Asymptote, I assume adding (contributing) another backend would be possible. (But I only realised just now that you already contributed to the PRC code, which is probably even more "exotic" than WebGL)
If you see the js code from github all in one line that is likely to be a problem with the translation of line ending characters on/to your platform, are you on MSWindows by any chance ? How does https://github.com/vectorgraphics/asymptote/blob/master/webgl/gl.js display for you in a browser ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much for implementing this, it has indeed reduced the size of typical files to the same order of magnitude as their VRML counterparts. (Most of the difference now is from polyhedra, where IndexedFaceSet is a bit more compact than the set of Bezier patches, but at least sizes are small enough now for congested or mobile connections. Suddenly so much more important than anticipated...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The new WebGL output is very tempting as a modern replacement for the VRML I have been using, however the sheer size of the the generated code is disconcerting. Most of my models contain lots of unitspheres, which Asymptote turns into individual sets of eight Bezier patches each which makes for a rather lengthy output. This is already apparent in the 180kB WebGL resulting from cyclohexane.asy, with three of four times the number of spheres (and similar number of polyhedra and/or cylinders connecting them) the size easily approaches 600kB or more than ten times that of the correponding VRML.
(This may not sound much given typical ethernet bandwidths, but imagine several per page on an educational website that should stay usable in a congested wireless network or on a limited mobile data plan.)
Is there something I am missing here, or would it be possible to move the expansion of the (scaled) unitsphere
to the common asygl.js ?
Yes, this is certainly possible; I will add compact sphere and tube primitives to our asygl TODO list.
The newly released 2.63 version of Asymptote now generates sphere, disk, cylinder, and tube primitives that are rendered within the AsyGL library. This has reduced the cyclohexane.html
output file size from 184K to 5.7K. Thank you for the excellent suggestion. These primitives provide a foundation for the upcoming v3d vector graphics file format we are proposing.
Dear John,
1) Why some proprietery v3d file format? Did you evaluate extending X3D with just your node, bezier patch with vertex colors? X3D has NURBS (but without vertex colors) and some WebGL viewers like x3dom or X_ITE have support for it, although rendering seems to be done once.
All other primitives you need are in X3D, I believe.
2) Where can I find AsyGL library source to try to understand how it works and evaluate the idea of makeing x3dom extension based on it?
3) Uphill battle of adding vertex color support to X3D NURBS node may be much more limited then pushing through an entirely new format. And X3D has already an ecosystem of tools.
Sicerely, Michail
Michail, which propietary format do you mean, the quasi-internal .asy one ? I find it very easy to generate from my code, much like the original VRML. In my opinion X3D has been all but killed off by all the xml-ifications when all that is desired is a 3D visualisation. And WebGL has the added advantage of not requiring everyone to install some specialized viewer (that may even be hard to get for some platforms).
Source code is on github
Martin,
"which propietary format do you mean, the quasi-internal .asy one" - no, I mean not Asymptote input format, but Asymptote output format.
"WebGL has the added advantage of not requiring everyone to install some specialized viewer (that may even be hard to get for some platforms)." - but on the other hands:
1) Now John has to make the viewer (in JS/WebGL code). As he had made his own OpenGL viewer originally. And he has to deal with platform chages himself, as he had to rewrite his OpenGL viewer in modern OpenGL.
2) Asymptote output can not be edited, translated to other format and joined with other 3D models in any practical way.
3) Long term use of 3D models that require for viewing a propietary tool (asygl.js library) mainained off-hours by one man team looks like no-go.
Declarative output in some recognized format solves that problems.
So John talks about "the upcoming v3d vector graphics file format we are proposing".
But pushing throuh formal standartisation and having other parties join in developing an ecosystem for entirely new format looks much harder than extending an existing format.
"Source code is on github" - but all asygl.js code there is merged in one long line. :(
Well, maybe you are trying to solve an entirely different problem. And WebGL is just one of several output formats supported by Asymptote, I assume adding (contributing) another backend would be possible. (But I only realised just now that you already contributed to the PRC code, which is probably even more "exotic" than WebGL)
If you see the js code from github all in one line that is likely to be a problem with the translation of line ending characters on/to your platform, are you on MSWindows by any chance ? How does https://github.com/vectorgraphics/asymptote/blob/master/webgl/gl.js display for you in a browser ?
Thank you very much for implementing this, it has indeed reduced the size of typical files to the same order of magnitude as their VRML counterparts. (Most of the difference now is from polyhedra, where IndexedFaceSet is a bit more compact than the set of Bezier patches, but at least sizes are small enough now for congested or mobile connections. Suddenly so much more important than anticipated...)