VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Sun Nov 27 2016 - 23:58:33 CST

Ben,
  If you're running VMD on Linux, you can set the display size beyond the
screen dimensions, for any of the supported renderers (built-in or external)
even when using the graphical interface -- but there's a trick to getting
around some of the recent GNOME window managers that like to prevent it:
If you move the bottom right corner of the VMD OpenGL window
below and to the right of the bottom right corner of the screen, the window
manager will (usually) not prevent you from setting an arbitrarily large
window size in VMD using the "display resize" command just as one would
do when running VMD with "-dispdev text". Admittedly, this is less
than ideal, and what we really want is to be able to force any/all
VMD renderings to take on an arbitrary user-defined image size regardless
of the limitations of your display.

Since there isn't a completely outboard OptiX-based renderer implementation
for VMD at the moment (it's on my TODO list for Tachyon, but there hasn't
been enough time yet for me to finish missing shaders etc) I have gone ahead
and added a workaround that will be in the final VMD 1.9.3 release.
The workaround is to use an environment variable, VMDOPTIXIMAGESIZE, to
specify the image dimensions, completely overriding what VMD would
otherwise tell the renderer to do. To use this (again, this is only
in the final VMD 1.9.3 release, not any of the prior versions) you can
set the environment variable, as in this example:
  set env(VMDOPTIXIMAGESIZE) "4096 4096"

This will give you essentially the same general override capability that
you've had before with the external Tachyon renderings, but for the internal
OptiX-based renderer.

One of the goals I have for the next VMD release after 1.9.3 is to
rewrite the VMD "Render" dialog to expose a bunch of features that
are in the low level code but aren't accessible from the GUIs as yet,
and must currently be managed using script commands and/or special
environment variables. This includes everything from stochastic sample
counts for ray tracers, to special projections used for rendering VR movies
and the like, as well as the more mundane things like image resolutions
that are far larger than what the display or window manager would normally
allow.

Cheers,
  John Stone
  vmd_at_ks.uiuc.edu

On Tue, Nov 15, 2016 at 06:44:53PM +0000, Ben Lowe wrote:
> Dear Josh,
>
> Thank you for this information, particularly its useful to know there
> is no obvious binary for the OptiX implementation.
>
> It is a shame that rendering to custom resolutons requires sacrificing the GUI.
>
> My issue with doing this non-interactively is that saving the state
> with VMD does not produce exactly the same image as my interative
> session, as you put it, it "tries its hardest" though!
>
> Kind Regards,
> Ben
>
> On 12 November 2016 at 22:46, Vermaas, Joshua <Joshua.Vermaas_at_nrel.gov> wrote:
> > Hi Ben,
> >
> > My understanding is that there isn't a standalone GPU-enabled Tachyon
> > binary. The tachyon binary you are calling actually comes from John's
> > independent passion project (http://jedi.ks.uiuc.edu/~johns/raytracer/),
> > which was CPU-only. John might have an OptiX variant that can be called
> > independently, but otherwise you are stuck with whats inside VMD.
> > Happily though, the most common request (arbitrary resolution) can be
> > done through a non-interactive VMD session pretty easily.
> >
> > Basically you set up the view as you like at a smaller resolution but
> > with the same aspect ratio, and save the VMD visualization state (lets
> > say state.vmd). This is just a plain Tcl script that tries its hardest
> > to recreate the scene you've setup (although for whatever reason leaves
> > the axes as the default). Then you add some things to the end of the script.
> >
> > axes location off; #Turn off the axes. I wanna see molecules, not 3 arrows
> > render TachyonLOptiXInternal test.ppm; #Does the actual rendering
> > exit; #Tell VMD to quit after rendering. Super useful for batch jobs
> > that otherwise waste node-hours
> >
> > Then you call this non-interactively from the terminal. The VMD
> > command-line options are handy for this
> > (http://www.ks.uiuc.edu/Research/vmd/current/ug/node240.html).
> >
> > vmd -dispdev text -e state.vmd -size 4800 4800
> >
> > In non-interactive mode, whatever you pass as the argument for size is
> > the rendered size (in pixels), and is how you can get sizes *greatly* in
> > excess of you monitor resolution.
> >
> > -Josh
> >
> > On 11/11/2016 11:23 AM, Ben Lowe wrote:
> >> I would like to render using the GPU-enabled TachyonLOptiXInternal,
> >> and custom options (such as a high resolution).
> >>
> >> I have managed to do this succesfull for the CPU Tachyon using the
> >> following command:
> >>
> >> render Tachyon scene.dat
> >> "/local/scratch/bml1g12/Software/vmd-1.9.2/install/vmd/tachyon_LINUXAMD64
> >> -aasamples 12 -trans_max_surfaces 1 %s -format TGA -res 846 626 -o
> >> %s.tga"
> >>
> >> But this relies upon passing the PATH of the executable for the the
> >> CPU Tachyon (/local/scratch/bml1g12/Software/vmd-1.9.2/install/vmd/tachyon_LINUXAMD6)
> >> and as I do not know the PATH of the GPU enabled Tachyon, I cannot use
> >> this for TachyonLOptiXInternal. How can I find the path for the GPU
> >> enabled tachyon (TachyonLOptiXInternal)?
> >>
> >> Or alternatively, how can I run TachyonLOptiXInternal with options?
> >>
> >> My question seems similar to the unanswered question last year from
> >> Parker de Waal :
> >> https://www-s.ks.uiuc.edu/Research/vmd/mailing_list/vmd-l/26042.html
> >>
> >> Kind Regards,
> >> Ben
> >>
> >>
> >>
> > 

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/