Re: [Jmol-developers] what creates the image?

[sascha becker]

Thank you so much for the answers and advice. I had to put the port aside for a few days, but I got back to it tonight and had some exciting results.  Starting with getting shapes rendering with just the g3d package was an excellent suggestion. Check this out: http://www.cs.brown.edu/~sab/pub/first-jmol-net.png That's 100% C#, using org.jmol.g3d and javax.vecmath The whole process wasn't all that hard, once I found the place to start. My NET3d sublcass of Platform3d builds an image from Platform3d.pbuffer, and puts it in Platform3d.imagePixelBuffer. I'm copying the pixels over one at a time, which is of course the slowest possible way, but I'm pretty sure I can reduce that to a single call to a .NET function that will build the image directly from memory. Then I just have a Windows Forms Control with an overriden paint method; that paint method just says... g3d.beginRendering() short colix = g3d.getColix(Color.PowderBlue); Sphere3d sphere = new Sphere(g3d); sphere.render(colix, 100, 40, 40, 77) .... g3d.endRendering // this is where I push the g3d image onto the screen e.Graphics.DrawImage(g3d.ScreenImage, 0, 0, panel.Width, panel.Height); My next steps are... * build the image from memory, not copying pixel by pixel * convert org.jmol.viewer and start drawing some chemistry! * evaluate//improve performance if necessary * Echange data with the non-Jmol parts of the system I checked with my advisor (Andy van Dam) about the GPL issue -- we're going to explore it with our local GPL expert (you were right, the CS dept is already quite familiar with the GPL). Andy is willing to go with the idea that my C# port of Jmol will be released as open source; we'll do some more research on our end to figure out what this means about using the C# port in a larger application whose source we might not want to release. best, sascha Miguel wrote: Sascha wrote: I'm working on the C# port, and I'm through org.jmol.g3d This is a standalone package. You should be able to write some standalone test programs that use org.jmol.g3d to verify that it is working properly. and javax.vecmath, which seemed like a foundation level to start with. This should be very straightforward. No ui. If there is a 'conversion tool' then it should just work. It *almost* did -- just a bit of trouble with java.io.Serializable, whose .NET analog is a bit different, and a few places where I have to be careful about casting floats and doubles to ints. Also trouble with the conversion tool's insistence on making *methods* named Rotation when there are is also a field named Rotation. Now I want to make Jmol paint into an image which I can copy to the screen. Per my message above ... I recommend a small test program that uses and verifies org.jmol.g3d I'm having trouble understanding where each of these classes fit into the structure of a viewer, and which of them I should use as the contact point for integrating with my C# app. Can anyone give me a brief description of each of these classes? org.jmol.api.JmolViewer, This is only an API specification. Its purpose is to: 1. put the external API in one place 2. make it easier to write the doc 3. make it easier to identify all the methods that should *not* be public org.jmol.viewer.Viewer The core of the implementation. org.jmol.viewer.FrameRenderer The thing that does the drawing. It walks over the data structures and calls individual Renderers. The word 'frame' is completely incorrect and should be changed. Since the title was 'what creates the image', then I suppose that the answer would be the FrameRenderer. Aha! Excellent. The library relies on a lot of collaboration between clasess; that will probably make it easier to swap in different implementations, but it makes it hard to grok the all-over structure. Any help would be appreciated. All of that stuff got pushed together into one package quite recently. I had to put it into one package because internal methods were 'public' ... and people started to use them. ...and then how do the adapters fit in? Is this just about sharing *data*, not images? org.jmol.api.JmolAdapter The adapter is the file IO mechanism. We are adapting an external data representation to the internal Jmol representation. The primary implementation of this is org.jmol.adapter.smarter The name is 'smarter' because it is more intelligent than the first 'simple' adapter. Other adapters (such as the cdk adapter) allow Jmol to import data from other data models Cool -- I'll take a look at this when I start doing data exchange with the other components of our application. Miguel ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Jmol-developers mailing list Jmol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-developers