[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IDLgrClipboard and IDLgrPrinter: wrong vector output order ?



"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