Re: [Jmol-developers] newbie question

[Dmitry M. <dma...@ma...>]

thank you very much for your answers
On Oct 21, 2004, at 1:07 AM, Miguel wrote:

> Dmitry wrote:
>
>> 1. I'd like to add some menuItems to the JmolPopup  menu
>>
>> but I didn't find any public methods to do so (only package methods)
>>
>> definitely I can modify jmol code or use reflection mechanism but I'd
>> prefer not to do so
>
> The JmolPopup is not part of the JmolViewer ... it is considered 
> external
> user interface that the application must provide.
>

well my goal is to build my application on top of Jmol suit
Jmol class is a example how to embed viewer into the custom application
JApplet is another one
for some reasons (so far I don't think is is relevant for that 
discussion) I'd like to build my own
wrapper (Application) around the Jmol
so I prefer to change API as less as possible if at all
I think that JMolPopup class is a part of Jmol suit so I'd prefer not 
to change it
to resolve my problem would be enough to make addMenu... methods public
BTW, in that case application/applet developer could add additional 
application/applet
specific menu items that are specific to that application
other way to handle it would be to provide some method like
addCustomMenu to the JMolPopup class, so I'll be able to add any 
arbitrary submenu to the main Jmol menu


> Take a look at the JmolApplet.java code to see a relatively simple 
> example.
>
>> 2. is there some reasonable explanation why
>> class JmolViewer is final?
>>
>> in general I found that many classes and methods in Jmol suit
>> have unnecessary restricted access
>
> Hmmm ... fair question.
>
> JmolViewer is final and many classes/methods have restricted access
> because, frankly, I don't think anyone should be building things based
> upon them. I still consider that code very volatile and subject to 
> major
> restructuring.
>
> At one level, all (most of?) the functionality should be available 
> through
> the scripting language.
>
> I consider the JmolViewer a component. If people need additional
> functionality, then we should modify the API to provide access to what
> they need.
>
> If you have special needs/requirements/wishes then I'll be glad to 
> discuss
> it.


well I respectfully disagree,
for example we use some special url handlers (not just http:, file:)
so I'd like to override some methods from JMolViewer
in that particular case I solved the problem by using inline function:
I load file from our URI into the memory and after that call function 
with String argument
that's OK ( I have instance of JMolViewer as a member of my wrapper 
class) but in that case
better solution would be just override appropriate JMolViewer method


>
>> 3. if I understand right in order to add new reader I have to modify
>> ModelResolver class
>>
>> is there any way to add new reader without modifying ModelResolver
>> class?
>
> No, not within the current SmarterModelAdapter framework.
>
> You must modify the ModelResolver to extend it.


>> so Modelresolver can pick up new format from
>> a) introspection
>> b) external preferences file
>> c) java preferences
>> d) java system preferences
>> e) explicit registration
>> ...
>
> The functionality of the ModelResolver could rather easily be extended
> using one of the mechanism that you suggest ... but currently there is 
> no
> mechanism.
>
> The SmarterModelAdapter is intended to support public file formats in a
> very flexible way, so that the Jmol application, the JmolApplet, and
> applications embedding the JmolViewer can easily read lots of file
> formats.
>
> HOWEVER, there is a completely other option that you may want to 
> consider.
>
> The entire SmarterModelAdapter is simply an implementation of the
> ModelAdapter API. If you don't want to work within the 
> SmarterModelAdapter
> framework then you can simply subclass the ModelAdapter and write all 
> your
> own stuff.
>
> If you only want to support a proprietary file format, or if you don't
> even have a file but want to load from your own data structures, then 
> you
> should consider implementing your own ModelAdapter.
>


yes, that could be a good way to do so, I'll consider that, definitely



>> 4. is there way to support transparency in the Jmol?
>
> Not yet, but I am working on it.
>
>> I found that BufferedImage from Swing3D class
>> was created with TYPE_INT_RGB modifier why not TYPE_INT_ARGB?
>
> For performance reasons.
>
>> I tried to change it to TYPE_INT_ARGB and didn't notice
>> any performance penalty (I have Powerbook G4/1.25GHz/1GB/MAC
>> OS X 10.3.5/Java 1.4.2 Update 2)
>
> On a modern machine like yours with a powerful graphics subsystem you 
> will
> not notice a performance difference.
>
> On older machines I was able to measure a performance difference.
>
> However, there is a much more fundamental problem. The org.jmol.g3d
> graphics engine is what needs to deal with transparency, not the Java
> class library.
>
> In order to get 3d functionality we must render the entire scene
> off-screen. This image gets sent to the screen in a single drawImage 
> call.
> So Java 2D transparency won't help at all. (unless you want to display 
> the
> molecule over an image background).
>
> I am working on 5 levels of transparency along with antialiasing.
>

after reviewing Jmol's rendering code
I think I understand that Jmol shouldn't use ant 2D facility should 
simulate transparency in other way


>> 5. what is the status of generating molecular surfaces?
>
> It is on the list of things to do.
>
> I need to officially release version 10 first.
>
> Some of the work for vanderWaals and solvent-accessible surfaces is 
> done
> as part of the Dots code.
>
>> if for example I will calculate triangles by myself may I use some 
>> mesh
>> rendering in Jmol?
>
> There currently is no support for mesh rendering.
>
> Be advised that the Jmol g3d engine is, well, different ... in that it
> does not use triangles to render the shapes.
>
> I *probably* will use triangles to render surfaces, but it will require
> quite a bit of work on the graphics engine.
>
> For example, the engine today can render individual triangles, but not
> meshes. And there is no support for any type of phong/gourand shading.
>

:-(

so if I render my triangles as individual triangles (as you said I have 
ability to render individual triangles)
I won't get nice picture I understand without shading
from other hand I can calculate color of every triangle by myself (and 
simulate light source)

few words to explain my situation:

we created some molecular viewer based on gl4java, but
it was not optimized for big molecules and didn't have full cartoon 
support
so we decided to use Jmol, especially after releasing of ver.10

surface was important feature that we had in our opengl viewer
also we had some engine to calculating electrostatic potential for 
proteins based on some virtual charges
so we was able to color our surfaces in appropriate way

transparency was quite important too"  we were able to show part of the 
molecule but
in the same time we were able to show whole picture by drawing 
"invisible" part of the molecule as a "ghost"

Jmol has very powerful scripting inherited from RasMol and it's very 
big pro argument to use Jmol



thanks again for your very good answers


we would like to contribute to Jmol project if possible



>
> Tough questions from a *newbie* :-)
>
>
> Miguel
>
> * The curse is broken! Go Red Sox!
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Jmol-developers mailing list
> Jmo...@li...
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>
Dmitry Markman