l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
February 3: Social gathering
Next Installfest:
Latest News:
Jan. 2: Happy new year! LUGOD turns 16!
Page last updated:
2004 Oct 04 18:09

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
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

On Mon, 4 Oct 2004 14:38:44 -0700 (PDT)
"Mark K. Kim" <lugod@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@lists.lugod.org
> > >>http://lists.lugod.org/mailman/listinfo/vox-tech
> > >>
> > >
> > >
> > _______________________________________________
> > vox-tech mailing list
> > vox-tech@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@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

Attachment: pgp00003.pgp
Description: PGP signature

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.