#516 x3d output has duplicated geometry

closed-fixed
5
2011-11-22
2011-11-21
simon
No

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.

Discussion

  • Angel Herraez

    Angel Herraez - 2011-11-21

    I will have a look at it. Maybe it was produced with al old version of Jmol wich was not yet optimized.

     
  • Bob Hanson

    Bob Hanson - 2011-11-21

    I give up. I can't find the duplication....

     
  • simon

    simon - 2011-11-21

    try

    geometry at line 189 == that at line 201

     
  • Angel Herraez

    Angel Herraez - 2011-11-22

    Well, that's one. But not "a lot". I see no other.

     
  • simon

    simon - 2011-11-22

    what?

    176 = 188
    191 = 164
    165 = 152

    and those took 1 minute to find.

     
  • Bob Hanson

    Bob Hanson - 2011-11-22
    • status: open --> closed
     
  • Bob Hanson

    Bob Hanson - 2011-11-22

    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'

    Ancient history!

     
  • simon

    simon - 2011-11-22

    OK.

    any way to know where to find a new x3d file?

     
  • Bob Hanson

    Bob Hanson - 2011-11-22

    If you need that particular file, just pull out the duplicates yourself. There can't be that many; it's only 200 lines, right?

     
  • Bob Hanson

    Bob Hanson - 2011-11-22
    • status: closed --> closed-out-of-date
     
  • simon

    simon - 2011-11-22

    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.

     
  • simon

    simon - 2011-11-22

    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.

     
  • simon

    simon - 2011-11-22

    so thinking bout it, maybe a switch, particularly with the old styte VRML output, for not using DEF/USE, would be really nice.

     
  • Bob Hanson

    Bob Hanson - 2011-11-22

    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:

    load ==ALA
    write ala.x3d

     
  • simon

    simon - 2011-11-22

    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%.

     
  • Bob Hanson

    Bob Hanson - 2011-11-22
    • status: closed-out-of-date --> closed-fixed
     
  • Bob Hanson

    Bob Hanson - 2011-11-22

    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.

     
  • Angel Herraez

    Angel Herraez - 2011-11-22

    Simon,
    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.

     
  • simon

    simon - 2011-11-22

    " 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.)

     
  • simon

    simon - 2011-11-22

    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.

     
  • simon

    simon - 2011-11-22

    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.

     
  • Bob Hanson

    Bob Hanson - 2011-11-23

    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.

    Bob Hanson

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks