[vox-tech] VTK 3D image capturing

Mon Oct 4 16:16:16 PDT 2004

On Mon, 4 Oct 2004 14:38:44 -0700 (PDT)
"Mark K. Kim" <lugod at cbreak.org> wrote:

> Well, I'm just taking a stab in the dark so it may be totally
> irrelevant, but...
> 
> 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 process.

The graphics card can automatically figure out which parts are clipped
outside of the window, so there is no difference between
single-buffering and double-buffering in this regard. The only place
where there might be a difference is regarding overlapping windows.

The video hardware doesn't even need to spend time switching buffers -
because the back buffer is a part of the 3D video hardware, it just
needs to change which bank of memory it is sending over the video port,
something that can happen instantaneously in circuitry when the buffers
are swapped.

> 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.

If VTK is using OpenGL, then it is certainly possible. Look at the
glCopyPixels() function.

> 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.
> 
> -Mark =)
> 
> 
> 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!
> > Jonathan
> >
> >
> > 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.>>
> > >>
> > >><snip>
> > >>
> > >>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.
> > >>
> > >>Thanks,
> > >>Jonathan
> > >>_______________________________________________
> > >>vox-tech mailing list
> > >>vox-tech at lists.lugod.org
> > >>http://lists.lugod.org/mailman/listinfo/vox-tech
> > >>
> > >
> > >
> > _______________________________________________
> > vox-tech mailing list
> > vox-tech at lists.lugod.org
> > http://lists.lugod.org/mailman/listinfo/vox-tech
> >
> 
> -- 
> Mark K. Kim
> AIM: markus kimius
> Homepage: http://www.cbreak.org/
> Xanga: http://www.xanga.com/vindaci
> Friendster: http://www.friendster.com/user.php?uid=13046
> PGP key fingerprint: 7324 BACA 53AD E504 A76E  5167 6822 94F0 F298
> 5DCE PGP key available on the homepage
> _______________________________________________
> vox-tech mailing list
> vox-tech at lists.lugod.org

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.
"All the spots [of tzarat] that a man sees on others, are his own."
 -- from the Mishna, as interpreted according to the Ba'al Shem Tov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://ns1.livepenguin.com/pipermail/vox-tech/attachments/20041004/b4b85829/attachment-0001.bin