I just thought I'd add my two-cents worth to the VRML issue:

We currently only support VRML export of volume isosurfaces and multiscale surfaces. So the answer is no, not yet.

Bizarrely, (and irrelevantly) from my experience chimera actually provides one of the faster VRML rendering solutions for Linux. Whilst it does not have all of the interaction models available to VRML2/97 or X3D, it might be a good basis for them. But this is a digression, only relevant because of the serious lack of a high-performance 3d world browser on that platform.

Exporting to a 3D graphics file format is definately something we would like to do. However, it is unclear what format would be best to generate. VRML 2.0 will never support transparency like chimera does. VRML's successor, X3D, looks promising, but there aren't many users yet. Other possiblities include the Renderman format, popular with animation studios; the .3DS format, popular on PCs; and many others.

Format issues are difficult - 3DS is popular because it's one of the older modelling systems. As such, there are a whole heap of conversion programs between it and other formats (afair). Another point against 3DS is that of the limitations with a geometry/scene description form like it (iirc) is that it does *not* support the so-called 'rich media' interaction forms that VRML2/97 was devised for (although proteins probably don't call for immersive world properties like mpeg-movie nodes and proximal sound effects).

So, a question for everyone reading this, if you had to pick one format, would it be VRML97? And if so, why? And if not, why not? We are leaning torwards outputing X3D, but would appreciate comments from people who would actually be using the output.

My answer in short is to go for X3D output - but make sure that at least one 3D-browser on each platform actually supports all the bells and whistles that chimera's X3D flavour contains, and that at least one script exists to translate the XML into a generic VRML97 form. Producing X3D should be easier than generating VRML97, not least because of the use of standard XML tools. Secondly, dumbing-down the X3D form to read like VRML shouldn't be too hard (except perhaps when it comes to annoying things like complex NURB surfaces, but I've never got those to work right in every browser anyhow :-( ). The downside of using X3D is that it still exists as a 'reference implementation' for the generic successor to VRML97 (which is basically not developed anymore). There was precious little observable progress in the last two years, however, although the x3d website is now looking rather smarter than it did a year ago. I've had good experiences with using the java3D implementation of x3d, but freeWRL and a few others which claimed support tended not to work anywhere near as well. This has hopefully changed in the last 6 months, but the various coding projects may suffer from the same lack of progress that the 3D modelling scene suffers from (perhaps because all the workers became serious 3D-animator/developers for film-studios ;-). Finally, some more concrete points : . Static 3D scene files require lots of effort to get right This is why 3ds still makes money - the user interface for 'denovo' modelling is very important. Arguably the most straightforward approach to static scene generation is WYSIWYG, which is easily achievable given the underlying object engine used in chimera. * This is exactly what the first post asked for. . The power of 3D environments is that they are spatial This is a double edged sword - 'flythroughs' were great for coorporate demos (apparently) but quite useless when you actually want to look at specific parts of a model. Generally, users need some guidance information in the scenes - particularly for collaborative apps. The standard ways of doing this is by having multiple viewpoints built in to the scenegraph, and providing annotation, that can also be hidden. Essentially, its possible to write books about the kind of features necessary for effective stand-alone 3D visualizations - and people have. Static scene generation should be a first goal - and chimera's scene model doesn't need much modification. But, if the X3d (or even vrml 1's) form is to be used seriously, the chimera viewing model needs to be made 'stateful'. That is, there can be many independent instances of a particular view (position,scale,focal-length, rendering styles, etc) onto the same set of coordinates, and these can be switched between, stored and browsed at will. I hope all the extraneous discussion makes sense - obviously it will make me really happy if chimera's 3d exporting is improved in any way, x3d support seems the most obvious because there are no other open formats which come close and still have an active development community. cheers :-) j. _______________________________________________________________________ Dr JB Procter:Biomolecular Modelling at ZBH - Center for Bioinformatics Hamburg http://www.zbh.uni-hamburg.de/staff.php