downloaded output example file from; http://jmol.sourceforge.net/demo/3dscenes/Ala.x3d
and i notice that it has a lot of duplicated geometry, doesn't effect look but does slow down rendering.
I will have a look at it. Maybe it was produced with al old version of Jmol wich was not yet optimized.
I give up. I can't find the duplication....
geometry at line 189 == that at line 201
Well, that's one. But not "a lot". I see no other.
176 = 188
191 = 164
165 = 152
and those took 1 minute to find.
Oh, I see. These are the small spheres that cap the bonds. That was fixed some time ago; this file is old, that's all.
name='generator' content='Jmol 11.9.23 2010-01-28'
any way to know where to find a new x3d file?
If you need that particular file, just pull out the duplicates yourself. There can't be that many; it's only 200 lines, right?
i did, i was reporting the problem to be helpful, actually all i did was remove all the small spheres in the block altogether, they all seemed redundant, as they are inside the big spheres, i did think they might be there for switching between visualisation forms, but not fully implemented or something, so i didn't report that.
no particular file needed but a range would be nice, i dont really want to start editing them all, it defeats the point, i'll go look for x3d molecules on google again.
and, in a related point, with all the DEF/USE in there it makes it quite difficult to edit the files by hand, and i don't see much, if any, benefit in it, just directly using the built-in spheres and cylinders all the way through, would result in hardly any bigger file, but a MUCH more readable and editable one.
so thinking bout it, maybe a switch, particularly with the old styte VRML output, for not using DEF/USE, would be really nice.
DEF/USE is saving HUGELY on space. The files aren't meant to be edited by hand. Why not just create your own files from alanine. For example:
did a quick edit and that file goes up +25%.
BTW the vrml spec requires support for gzip, a gzipped vrml file is a vrml file, and that gets you -80%.
Not sure what you mean by "that file goes up 25%" -- I think you mean that when you remove the extra atoms, the file size goes down by 25%. In any case, I've checked in code that removes in-atom bond spherical ends. That's not exactly correct in all cases, but it should be OK for any real case.
The first version we had of the exporter declared every single atom and bond as a separate object. Then this DEF/USE method allowed to reduce size considerably, as Bob has pointed out.
As far as I remember, there are some gzipped files in the example set. Jmol does not produce them, but you can gzip the output for any further use.
If there is improvement in the algorithm, I will try to update the sample files with a more modern version. As I said at the beginning, these examples were old --and meant to illustrate Jmol capabilities, which they still do.
I agree that the idea is to improve the algorithm, not to get files. But cases and causes must be identified precisely for that. According to Bob's post, that's on the way.
" I think you mean that when you remove the extra atoms, the file size goes down by 25%"
no, its when you get rid of the DEF/USE, it goes up by 25%, ( so DEF/USE gives you about a 20% reduction)
but, i think up too 50% size reduction, on very large files.
using gzip generally gets you 80%.
and as i said, a gzipped vrml is still vrml, ( but a zipped (pkzip) vrml file is not.)
(so up to ~90% on very big files, by using both together.)
first, thanks for bothering with this now its turned into an off-bug conversation.
obviously the original bug, was fixed.
so all im saying now is that DEF/USE made in much harder for me to directly fix that now non-existent problem.
but i mentioned this because i was originally impressed by this concept, (i think directly stated by the designers); that vrml could have the benefits of verbosity, being human readable and text editor editable, but not suffer from large files by mandating the support for gzip.
you could get an even bigger size reduction using prototypes, which also give you powerful hierarchical features, but as you say, if these files are only used for interchange with other software or as-is then there is no need for these.
and prototypes were taken out of the simplest profile of x3d, so might not be available on very basic x3d browsers, on the other hand i've never seen one that didn't do prototypes.
OK, so that's a closed case, I think. Removing hidden bond endings saved about 10% in my test; using DEF/USE saves 25%; GZIP can save even more, so you should be all set. I thought it was interesting that you said it was harder -- I would have thought the single DEF for the bond endings would make it far easier to find and remove all of them -- just remove that def and all its uses. But in any case, that should no longer be necessary.
Thanks for bringing this to my attention.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.