On Mon, Apr 2, 2012 at 3:20 PM, Kevin Theisen <ke...@ichemlabs.com> wrote:

> Marching cubes in JavaScript. Now there's a challenge! Kevin, I think if
> you want something like that, use JmolData.jar. That's headless and can run
> any script not involving image creation or font use. So creation of
> isosurfaces is fine. Jmol's marching cubes algorithm is highly efficient,
> now processing just about everything "progressively" meaning as a data
> stream, never actually creating a huge cube of data. It's possible
> exporting it as some other format would work.
>
>
> Exporting it to a format is not necessary. We just need to send Jmol
> atoms, and then extract the vertices, normals and mesh connectivity of the
> surface. That information will be ajaxed down as JSON, and immediately
> rendered. Is this possible?
>
>
I was thinking  that some simple format like

write xxx.vrml

This is a very simple format that I would think would be easily parsed by
your JavaScript. It includes vertices, normals, and faces.

Transform{children Transform{translation .449 -.189 .065
children [
Shape {
 appearance  DEF _0 Appearance{material Material{diffuseColor 1 .648 0
transparency 0}} geometry IndexedFaceSet {
coord Coordinate {
   point [
4.262 1.094 .447
4.262 1.068 .484
4.275 1.068 .447
4.262 1.2 .191
4.338 1.068 .191
...
-5.071 -1.439 .702
-5.087 -1.439 .447
-5.033 -1.439 .191
   ]
  }
  coordIndex [
2 0 1 -1
3 0 4 -1
4 0 2 -1
...
3988 4019 3990 -1
3990 4019 3982 -1
  ]
  solid FALSE
  normalPerVertex TRUE
   normal Normal {
  vector [
.836 .456 .305
.836 .539 .101
.889 .43 .154
...
3150 3127 3125 -1
3125 3127 3127 -1
3127 3127 3119 -1
  ]
 }
}





>
> Kevin, could you tell us about some of your ideas for scriptability of
> ChemDoodle? I'm sure that's come a long way since I talked with you last.
>
>
> I'm sure we will butt heads again on this, but this is a fundamental
> difference between Jmol and ChemDoodle. Jmol's scripting system is
> necessary because authors cannot manipulate Java at runtime, and therefore
> would have no way to programmatically interact with Jmol. The ChemDoodle
> Web Components library is pure Javascript, and can be manipulated in any
> way, at any time, including runtime. So a script for the ChemDoodle Web
> Components is not necessary, but that does not mean an author can't achieve
> the same behavior in both environments.
>
>
Ah, well, actually web developers have full access to the Viewer class, so
they can do anything with it they want, if they chose to. However, they
would never choose to.

> Does this make sense?

No, sorry, it still doesn't! :) I think I just need a "for instance":

I have a page with a ChemDoodle version of caffeine.

What do I do in ChemDoodle that would be equivalent to this in Jmol:

  select {carbon}; color red

or

  rotate x 30

or, I have a protein, let's say 1crn. What would I do in ChemDoodle to do
this?

select *; wireframe only
select {helix}; cartoons only

? Those are pretty simple operations, of course. But I think they are
representative of what I'm talking about. Are there any web pages out there
using ChemDoodle that have simple scripting like this?


Bob


> -Kevin
>
>
> On Apr 2, 2012, at 2:31 PM, Robert Hanson wrote:
>
>
>
> On Mon, Apr 2, 2012 at 12:35 PM, Kevin Theisen <ke...@ichemlabs.com>wrote:
>
>> I think these are all good points. In order to create a Jmol app for
>> iPads, one would need to completely port the project to Objective-C, no
>> easy task. To publish in Apple's App Store also costs money (99$/year), is
>> very, very complicated and requires constant attention. And regardless of
>> whether such an app would exist, Jmol authors would still need to
>> "recreate" their content to work in these apps; the applets on their
>> websites would still not work. So we are focusing on HTML5/WebGL as the
>> solution.
>>
>> Most of the performance issues with the ChemDoodle Web Components and
>> large proteins have been addressed, and the toolkit should never crash when
>> parsing any sized PDB file at this point. However, when using the backend
>> services, a PDB file may take a while to parse, and our Apache server
>> automatically terminates connections after 60 seconds, resulting in an
>> error. This is due to the fact that our Java backend is based on the
>> ChemDoodle desktop API, and therefore has overhead for working with the GUI
>> and for creating 2D graphics. We are currently in the process of separating
>> this logic out, so that really intensive functions become much more
>> efficient.
>>
>> I should note that our graphics are not limited to just proteins, the
>> ChemDoodle Web Components library handles small molecules, macromolecules,
>> crystals, spectra, and 2D as well as 3D (MOL/PDB/CIF/JCAMP/XYZ). We are
>> also working on surfaces (an experimental API is already included). Maybe
>> this is a good time to really push for an integration of Jmol functionality
>> on our backend though. We are still working on an efficient marching cubes
>> algorithm in Javascript, and until that is complete, we could use Jmol
>> instead. We would just need to know how to call it and export the necessary
>> information. I think with your help, Bob, we could have this in a few days.
>>
>
> Marching cubes in JavaScript. Now there's a challenge! Kevin, I think if
> you want something like that, use JmolData.jar. That's headless and can run
> any script not involving image creation or font use. So creation of
> isosurfaces is fine. Jmol's marching cubes algorithm is highly efficient,
> now processing just about everything "progressively" meaning as a data
> stream, never actually creating a huge cube of data. It's possible
> exporting it as some other format would work.
>
> Kevin, could you tell us about some of your ideas for scriptability of
> ChemDoodle? I'm sure that's come a long way since I talked with you last.
>
> --
> Robert M. Hanson
> Professor of Chemistry
> St. Olaf College
> 1520 St. Olaf Ave.
> Northfield, MN 55057
> http://www.stolaf.edu/people/hansonr
> phone: 507-786-3107
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
>
> http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Reply via email to