[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IDLgrClipboard and IDLgrPrinter: wrong vector output order ?
- Subject: Re: IDLgrClipboard and IDLgrPrinter: wrong vector output order ?
- From: "Mark Hadfield" <m.hadfield(at)niwa.cri.nz>
- Date: Wed, 24 May 2000 10:31:20 +1200
- Cache-Post-Path: clam-ext!unknown@gust.niwa.cri.nz
- Newsgroups: comp.lang.idl-pvwave
- Organization: NIWA
- References: <392AA2DF.521D1AEE@Noveltis.fr>
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:19778
"Nicolas Decoster" <Nicolas.Decoster@Noveltis.fr> wrote in message
392AA2DF.521D1AEE@Noveltis.fr">news:392AA2DF.521D1AEE@Noveltis.fr...
> Hi.
>
> First of all:
> IDL> print, !version
> { sparc sunos unix 5.3 Nov 11 1999}
>
> I am trying to build home tools to draw some kind of personal graphics.
> Once I have my pretty drawing on a IDLgrView displaying on a
> IDLgrWindow, I want to print it or include it in document. I decided to
> use IDLgrClipboard with the vector keywords of the Draw method for
> various reasons.
>
> The problem is that the IDLgrWindow::Draw method and the IDLgrClipboard
> one don't seem to use the same atomic object order to render the view.
>
> Here is a little code to illustrate my words:
>
> --- begin of the little code ---
> ...
> --- end of the little code ---
>
> You see what I mean?
Well, no. On my system (x86 Win32 Windows 5.3.1 Feb 23 2000) the IDL window
& the Postscript file both look the same (red in front of green). At least
they do when the IDLgrWindow uses the hardware renderer (RENDERER=0), but if
I tell it to use the software renderer (RENDERER=1), the overlap is reversed
(green in front of red). I presume the latter is what you saw.
In my experience the only way to get reliable Z-ordering with Object
Graphics is to actually position atoms in the Z dimension, not to rely on
drawing order. The minimum offset required to ensure reliable overlap
control is approximately 1/65536 times the distance between the front and
rear clipping planes, e.g. see the following fragment from the IDLgrLegend
code:
oView->IDLgrView::GetProperty, ZCLIP = zClip
depthOffset = (double(zClip[0]) - double(zClip[1]))/65536.d
(I guess this means that OpenGL uses 16-bit integers internally?)
Actually I suggest increasing the depth offset for overlap control to twice
the above value, because this seems to be required with some combinations of
atoms on some output devices.
---
Mark Hadfield
m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield/
National Institute for Water and Atmospheric Research
PO Box 14-901, Wellington, New Zealand