sascha wrote: > I've made a lot of progress in the last few hours; this description > definitely helps.
good [snip] >>Write a small test program that instantiates a SmarterAdapter. Then read >>in a file using it. >> >>You do not need to store the contents anyplace, but you need to iterate >>through all the atoms and all the bonds. >> >> > > Yes! I ported this and I can now read in a Mol file. There's a bit of a > hiccup in that the .NET equivealent of BufferedReader doesn't have a > "reset" method, but that's easily worked around. very good. >>>Control flow: >>>I'm rather confused by the rendering pipeline -- Graphics3D, Viewer, >>>FrameRenderer, Frame, Platform3D -- so many related classes, >>> >>> >> >>Graphics3D and Platform3D provide rendering primitives. You have >>demonstrated that part working, so don't worry about them anny more. >> >> > > I just needed to step through the code to figure out the control flow. > It also turned out that the Java->C# converter messes up the conversion > of virtual methods, so that the base class virtual method gets called > unless the subclass method is marked "override." Crazy, I thought > virtual methods *meant* that the subclasses version would be called. I agree ... that seems quite strange. >>The FrameRenderer's job is to render the Frame. It does this by >> delegating >>to BallsRenderer, SticksRenderer, RibbonsRenderer, etc. >> >> > I'm almost there! I'm pretending that everything uses a BallsRenderer > for now. OK. You can easily disable all of the other shapes by commenting them out in JmolConstants.java & Eval.java Be careful when working with those classes. They are dynamically loaded so there is almost no compile-time checking going on. Any errors will show up at run-time. [snip] > Okay -- now that I'm getting a grip on the SmarterJmolAdapter, I think > I'll be able to move things around so I can create the model > programmatically. good. that is the right way to do it. > Ah, but they do, but not how you think -- if I can't get this Jmol port > to work, I have to go back to my lame built-from-scratch Direct3D > molecule viewer. But you would not have to roll back that far. org.jmol.g3d offers a higher level of functionality than Direct3D ... at least when rendering molecules. Therefore, worst case you could still implement your own data model on top of g3d. You would get higher performance and a higher level of abstraction ... spheres & cylinders. [snip] > Jmol is super-fantastic. It's worth the porting effort. good. I'm glad that you are enthused. > The various > rendering styles are the main reason I wanted to use Jmol -- and the > ability to read so many file types. The organic chemistry professor I > work with said something like "it would be SPECTACULAR if we could use > Jmol." > > The port is going to work, tonight I think! I've got the > SmarterJmolAdapter reading in mol files, and I've got g3d, and I > understand how the ModelManager and Frame work -- I'm moments away. > Thanks for all the help. Excellent. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
