WriteImage is there. It can be invoked explicitly and it is imbedded
within the Image macro.
The Image macro invokes Render/Display for software or hardware rendering.
This can be done explicitly with the Options("rendering mode", "hardware")
with Render or Display directly. So for no interaction (i.e., batch),
driven by the Sequencer, you just need Render->WriteImage in your network.
With appropriate plumbing, you can build an interactive application that
could also operate in batch to produce requested images on disk without
having to render them to the screen, to avoid double rendering.
In commercial DX and at least earlier versions of OpenDX, you could only
save the bitmaps rendered in software for writing to disk or to do other
processing. The questions really are 1) can OpenGL-rendered images can be
buffered in a similar fashion to software and 2) can you do OpenGL
rendering without displaying it to the screen? The answer was no in older
flavors of DX. The only mechanism I knew of is what Greg had suggested of
explicitly saving the image buffer with ReadImageWindow.
ballard andrews <[EMAIL PROTECTED]>@opendx.watson.ibm.com on
03/13/2002 03:22:35 PM
Please respond to [email protected]
Sent by: [EMAIL PROTECTED]
To: [email protected]
cc:
Subject: Re: [opendx-users] Re: Saving HW-rendered images
Randall,
Assuming the WriteImage module is still in OpenDX,
you need to use the Render module rather than
the Image module (of course you can run the
output from Image->Render->WriteImage
but this means rendering the data twice;
So use Render->Display instead if
you want to see the date you're writing.
>
> I used to do this in the commercial version with the WriteImage
> module. Is this gone from OpenDX?
>
> >
> > |Do you mean while you are interacting with the object in the image
window?
> >
> > No, I don't need interaction. The animation is driven by a Sequencer.
> >
> > I'm using Image because (IIRC) Render currently doesn't support
hardware
> > rendering.
> >
> > |And I think the bits you get are exactly those read back from the
OpenGL
> > |window, so they were gamma corrected during the rendering process and
the
> > |read-back doesn't un-correct them. So if you then Display them,
they'll
> > |get gamma corrected yet again.
> >
> > Ok. I can de-gamma-correct them.
> >
> > |One unpalatable way you might save each frame is by building a custom
user
> > |interactor which read back the OpenGL window and wrote each rendered
image
> > |to a file. The readback and file write would be easy; they'd just
be
> > |explicit invokations of the ReadImageWindow and WriteImage modules.
It'd
> > |take a bit of hacking to make itwork well, though; I bet you'd need
to
> > |implement an additional call to the user interactor to pass it
control
> > |again after each image is rendered.
> >
> > I'll work with that. I hadn't used ReadImageWindow before (didn't know
it
> > was there). And I'll flip through the UserRef again to see what other
> > modules I could be using.
> >
> > Thanks for the suggestions.
> >
> > Randy
> >
> > --
> > Randall Hopper (mailto:[EMAIL PROTECTED])
> > Lockheed Martin Operation Support
> > EPA Scientific Visualization Center
> > US EPA N127-01; RTP, NC 27711
>
> --
> Dr. A. Ballard Andrews
> Senior Research Scientist
> Schlumberger Doll Research
> 36 Old Quarry Road Ridgefield, CT 06877
> tel: 203-431-5522 fax: 5521
--
Dr. A. Ballard Andrews
Senior Research Scientist
Schlumberger Doll Research
36 Old Quarry Road Ridgefield, CT 06877
tel: 203-431-5522 fax: 5521
