| Double-precision plotting doesn't work in object graphics [message #29075] |
Thu, 31 January 2002 20:22  |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
In IDL version 5.4 RSI introduced double precision support in its graphics
routines and objects to allow (amongst other things) plotting of times
expressed in Julian Days. I have just noticed that it doesn't work as
advertised in Object Graphics.
The routine below demonstrates this. It generates & plots two day's worth of
data at 15-minute intervals. Option 0 gives you a Direct Graphics plot: it
shows a nice clean ramp. Option 1 gives an Object graphics plot: it shows
steps at ~0.3 days spacing.
Here is a calculation of the granularity expected in single- and
double-precision representations of Julian dates:
IDL> m = machar() & feps = m.eps
IDL> m = machar(/DOUBLE) & deps = m.eps
IDL> print, 2452301*feps, 2452301*deps
0.292337 5.4452021e-010
The step spacing in the Object Graphics plot is suspiciously similar to the
single-precision granularity. Obviously some single-precision numbers are
creeping into the Object Graphics calculations.
Version tested: { x86 Win32 Windows Microsoft Windows 5.5 Aug 28 2001 32 64}
Oh well, it looks like I'll have to translate the data and fudge the labels
a little longer.
---
Mark Hadfield
m.hadfield@niwa.co.nz http://katipo.niwa.co.nz/~hadfield
National Institute for Water and Atmospheric Research
***** mgh_test_double_plot.pro *****
pro mgh_test_double_plot, option
compile_opt IDL2
if n_elements(option) eq 0 then option = 0
;; Create two days data at 15-minute intervals
;; Origin is 27 Jan 2002
time = 2452301.5D0 + dindgen(193)/96
data = dindgen(193)/96
case option of
0: begin
;; Direct Graphics
plot, time, data, XTICKUNITS='days', XTICKFORMAT='(C(CDI2,X,CMoA))'
end
1: begin
;; Object Graphics
model = obj_new('IDLgrModel')
;; NORM_COORD function is in
;; <IDL_DIR>/examples/visual/utility/norm_coord.pro
xcoord = norm_coord([min(time),max(time)])
ycoord = norm_coord([min(data),max(data)])
xaxis = obj_new('IDLgrAxis', 0, RANGE=[min(time),max(time)], $
TICKUNITS='days', TICKFORMAT='(C(CDI2,X,CMoA))', $
TICKLEN=0.05, $
LOCATION=[-0.2,-0.2], XCOORD_CONV=xcoord)
model->Add, xaxis
yaxis = obj_new('IDLgrAxis', 1, RANGE=[min(data),max(data)], $
TICKLEN=0.05, $
LOCATION=[-0.2,-0.2], YCOORD_CONV=ycoord)
model->Add, yaxis
dplot = obj_new('IDLgrPlot', time, data, $
XCOORD_CONV=xcoord, YCOORD_CONV=ycoord)
model->Add, dplot
xobjview, model
end
endcase
end
|
|
|
|
|
|
| Re: Double-precision plotting doesn't work in object graphics [message #29165 is a reply to message #29075] |
Fri, 01 February 2002 07:12  |
btupper
Messages: 55
Registered: January 2002
|
Member |
|
|
On Fri, 1 Feb 2002 17:22:31 +1300, "Mark Hadfield"
<m.hadfield@niwa.co.nz> wrote:
>
> xobjview, model
Hi Mark,
Try
xObjView, model, /double_view
To get xObjView to handle double precision (why doesn't it do it
anyway?)
Ben
P.S. This may be the third time I have been able to provide an answer
to a newsgroup question. Ever! Do you think I should call it an
earlier weekend and wrap up my week on a high note?
|
|
|
|
| Re: Double-precision plotting doesn't work in object graphics [message #29166 is a reply to message #29075] |
Fri, 01 February 2002 07:12 |
karl_schultz
Messages: 13
Registered: August 2001
|
Junior Member |
|
|
"Mark Hadfield" <m.hadfield@niwa.co.nz> wrote in message news:<a3d57g$pt1$1@newsreader.mailgate.org>...
> In IDL version 5.4 RSI introduced double precision support in its graphics
> routines and objects to allow (amongst other things) plotting of times
> expressed in Julian Days. I have just noticed that it doesn't work as
> advertised in Object Graphics.
>
> The routine below demonstrates this. It generates & plots two day's worth of
> data at 15-minute intervals. Option 0 gives you a Direct Graphics plot: it
> shows a nice clean ramp. Option 1 gives an Object graphics plot: it shows
> steps at ~0.3 days spacing.
>
> Here is a calculation of the granularity expected in single- and
> double-precision representations of Julian dates:
>
> IDL> m = machar() & feps = m.eps
> IDL> m = machar(/DOUBLE) & deps = m.eps
> IDL> print, 2452301*feps, 2452301*deps
> 0.292337 5.4452021e-010
>
> The step spacing in the Object Graphics plot is suspiciously similar to the
> single-precision granularity. Obviously some single-precision numbers are
> creeping into the Object Graphics calculations.
>
> Version tested: { x86 Win32 Windows Microsoft Windows 5.5 Aug 28 2001 32 64}
>
> Oh well, it looks like I'll have to translate the data and fudge the labels
> a little longer.
>
> ---
> Mark Hadfield
> m.hadfield@niwa.co.nz http://katipo.niwa.co.nz/~hadfield
> National Institute for Water and Atmospheric Research
< snip program >
The short answer is to add /DOUBLE to your call to XOBJVIEW. Then the
plot looks like the direct graphics plot.
Here's why:
Object Graphics uses OpenGL. OpenGL only guarantees floating point
precision that is about what you get with IEEE single precision
numbers (no accident, I suppose). The OpenGL folks figured that most
apps would already be OK with this or could easily make themselves OK
with this. Also, a lot of graphics hardware is built with this sort
of limitation on the same assumption.
Normally, IDL passes data to OpenGL in "user" data space. That is, if
you are drawing things in the 1d+10 range, we pass these numbers to
OpenGL and let it transform this data to the screen space, which is in
the 0-2000 sort of range.
But OGL ends up storing your user data in single-precision floating
point, and so you will lose precision as OGL stores it away in a
single precision float. That is why you got the stair-step pattern.
To get around this, IDL can be configured to perform all the
transforms from user to screen space in double precision ABOVE the OGL
layer. OGL ends up getting coordinates in screen space and happily
processes them without applying a general model transform. The way to
activate this mode is to turn on the DOUBLE property on IDLgrView.
The DOUBLE keyword on XOBJVIEW does exactly this.
Why isn't this the default behavior? For software rendering, it
probably does not matter much, because we're just moving the vertex
transform step out of OGL and into IDL. Many OpenGL libs are
optimized to skip the transform step if the current transform matrix
is the identity.
The problem is that people with devices that have hardware-accelerated
transform and lighting would be very upset because IDL would always be
doing the transform in software and not be using the nice hardware on
the card. The T&L hardware essentially can do the transform for free,
since it is running on the graphics CPU and is probably overlapping
with the vertex submission code that IDL is running at the same time.
For awhile, only workstation graphics hardware could do this. Now the
commonly available GEForce2/3 class cards have this capability as
well.
Karl
RSI
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
