Re: [vox-tech] VTK 3D image capturing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] VTK 3D image capturing
Well, I'm just taking a stab in the dark so it may be totally irrelevant,
When rendering an image, it can be done in several ways. *In 2D*, you can
draw directly to the hardware, or you can draw it in memory then copy the
drawn image to the hardware. The former is faster but it can end up with
unsmooth animation (if you're animating) or snow flicker. The latter,
called double buffering (because you're buffering the image before it's
rendered on the video card's memory), is slower but you get better timing
control therefore smoother animation. Thus the need for multiple ways of
rendering images to the screen.
In 3D, rendering directly to hardware is fast, and saves quite a bit of
resources by optimization. For example, the hardware can figure out if
it's drawing inside a visible area or outside a visible area, then ignore
the entire invisible area altogether. So if your 3D rendering area is
underneath another window, It's *possible* the 3D video hardware may not
render that area altogether.
But if you double-buffer, the video hardware must draw the 3D image in a
buffered memory area first, then copy that rendered image onto the screen;
the process is same as that of a 2D image rendering. I'm *guessing* the
video hardware, in double buffering, has no chance to figure out which
area of the image is invisible, thus is forced to render the entire window
in memory. This memory area then, at some point, gets plastered on the
screen by the DMA or video card or whatever that handles the image copying
I'm suggesting perhaps there's a way for you to get a hold of this
buffered image area that DMA uses, and copy that image area into a
graphics format you can manipulate instead of pasting it on the screen.
Quick googling shows VTK has some sort of double buffering option, but I'm
not sure if you can get access to the double buffered image.
It's just an idea. It'll probably lead to nowhere. =P But it's worth a
look if you're out of options and have a few minutes to spare.
On Mon, 4 Oct 2004, Jonathan Stickel wrote:
> What's a "double buffer"? Really, until 2 days ago I've never even
> thought about how X is programmed. Is there a good web reference?
> Thanks Mark!
> Mark K. Kim wrote:
> > Can you double buffer the output and save the buffered image?
> > -Mark
> > On Mon, 4 Oct 2004, Jonathan Stickel wrote:
> >>Jeff Newmiller wrote:
> >>>I detest programs designed to behave this way... from "helpful" cpu status
> >>>displays to "Did you really want to quit this program?" dialog boxes to
> >>>"Your Windows resources are running low" to "We are backing up your
> >>>data... please wait" dialog boxes... they all suffer from either hubris or
> >>>programmers who couldn't handle multitasking. Please stop trying to take
> >>>control away from the users ... there has to be a way to avoid this
> >>>unfriendly behavior in your software ... be creative and find it.
> >>I appreciate your comments. Let me explain a little bit more about my
> >>problem. I am helping with a 3D visualization add-on (octaviz, built on
> >>VTK) for a numerical math package (octave). Octave typically runs as a
> >>command-line interpreter in a shell window. Graphing commands (and now
> >>visualization commands) generate new windows that contain
> >>graphs/graphics. 2D plots can be exported in some vectorized format, of
> >>course. The 3D visualizations, however, are complex, opengl rendered
> >>objects with mouse interaction to rotate, zoom, etc. Image "snapshots"
> >>of the windows are often the only way to get a desired export of the
> >>visualization. There are functions in VTK to do just this, but the
> >>rendered window MUST be on top to work; otherwise, it exports whatever
> >>screen image is over the top of the VTK window. And yes, I do consider
> >>this to be a feature problem in VTK, but I do not have the technical
> >>expertise nor time to make changes to VTK.
> >>So... a quick and easy fix for me is to force the window on top before
> >>my export command saves the window as an image. I did spend all weekend
> >>looking through Xlib programming docs to see if I could get around this
> >>some way, for example by keeping the window data in memory when it is
> >>covered up. Another option is off-screen rendering, but that path isn't
> >>short either.
> >>If anyone has further suggestions, I would be happy to hear them. For
> >>now I /try/ to bring the window to the top and have a warning in the
> >>user docs about this.
> >>vox-tech mailing list
> vox-tech mailing list
Mark K. Kim
AIM: markus kimius
PGP key fingerprint: 7324 BACA 53AD E504 A76E 5167 6822 94F0 F298 5DCE
PGP key available on the homepage
vox-tech mailing list