Bugs item #3440852, was opened at 2011-11-21 12:36 Message generated for change (Comment added) made by simonplace You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=3440852&group_id=23629
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File Input/Output Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: simon (simonplace) Assigned to: Bob Hanson (hansonr) Summary: x3d output has duplicated geometry Initial Comment: 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. ---------------------------------------------------------------------- Comment By: simon (simonplace) Date: 2011-11-22 14:14 Message: 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. ---------------------------------------------------------------------- Comment By: simon (simonplace) Date: 2011-11-22 14:11 Message: 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. ---------------------------------------------------------------------- Comment By: simon (simonplace) Date: 2011-11-22 14:11 Message: " 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.) ---------------------------------------------------------------------- Comment By: Angel Herraez (aherraez) Date: 2011-11-22 01:07 Message: 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. ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2011-11-21 18:28 Message: 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. ---------------------------------------------------------------------- Comment By: simon (simonplace) Date: 2011-11-21 17:02 Message: 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%. ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2011-11-21 16:47 Message: 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 ---------------------------------------------------------------------- Comment By: simon (simonplace) Date: 2011-11-21 16:47 Message: so thinking bout it, maybe a switch, particularly with the old styte VRML output, for not using DEF/USE, would be really nice. ---------------------------------------------------------------------- Comment By: simon (simonplace) Date: 2011-11-21 16:44 Message: 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. ---------------------------------------------------------------------- Comment By: simon (simonplace) Date: 2011-11-21 16:37 Message: 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. ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2011-11-21 16:28 Message: If you need that particular file, just pull out the duplicates yourself. There can't be that many; it's only 200 lines, right? ---------------------------------------------------------------------- Comment By: simon (simonplace) Date: 2011-11-21 16:23 Message: OK. any way to know where to find a new x3d file? ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2011-11-21 16:17 Message: 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! ---------------------------------------------------------------------- Comment By: simon (simonplace) Date: 2011-11-21 16:08 Message: what? 176 = 188 191 = 164 165 = 152 and those took 1 minute to find. ---------------------------------------------------------------------- Comment By: Angel Herraez (aherraez) Date: 2011-11-21 16:01 Message: Well, that's one. But not "a lot". I see no other. ---------------------------------------------------------------------- Comment By: simon (simonplace) Date: 2011-11-21 15:45 Message: try geometry at line 189 == that at line 201 ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2011-11-21 15:15 Message: I give up. I can't find the duplication.... ---------------------------------------------------------------------- Comment By: Angel Herraez (aherraez) Date: 2011-11-21 13:49 Message: I will have a look at it. Maybe it was produced with al old version of Jmol wich was not yet optimized. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379133&aid=3440852&group_id=23629 ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
