| Re: Another Long Day Compliments of Object Graphics [message #21210] |
Wed, 16 August 2000 19:17 |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
"David Fanning" <davidf@dfanning.com> wrote in message
news:MPG.1404ed3fe278116b989bd8@news.frii.com...
> ...I moved the tick marks
> up 0.001 unit in Z and all was well. Are you saying
> I could *not* do this if I didn't have the image in
> a polygon?
Ah yes...or no...I can't handle these double negatives and it's only 2 pm!
If two overlapping atoms (plots, text, polygons, etc--but not images) are at
the same level in Z, then the question of which one obscures the other does
not have a consistent answer. The IDL documentation says that it depends on
the order in which they were put into the graphics tree (which determines
the order in which they are drawn) but that's not really true. It depends on
the destination device. If the destination device is the display screen,
then it depends on whether the hardware or software renderer is selected (on
my system anyway). It may depend on the video card. Whatever it depends on
it can't be relied on.
The solution to robust overlap control is to position things in Z. The
minimum displacement required for this purpose is equal to the distance
between the front & rear clipping planes, divided by 65536. Deduction:
16-bit integers are involved somewhere! I got this number from the
IDLgrLegend code. (Actually I find it is best to double it just to be on the
safe side. I get the impression that some renderers draw text just
*slightly* above or below its nominal position relative to lines & polygons
etc.)
Texture-mapped polygons obey these rules but stand-alone images don't. With
your old image-based colour bar, you would see the tick marks where they
overlap the image as long as they were added to the colour bar object after
the image.
I've added an example program called mgh_example_image to my WWW site to
illustrate how drawing order & Z position affect visibility of text objects
relative to an image.
---
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
|
|
|
|
| Re: Another Long Day Compliments of Object Graphics [message #21211 is a reply to message #21210] |
Wed, 16 August 2000 17:12  |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
"David Fanning" <davidf@dfanning.com> wrote in message
news:MPG.1404d069bf79fd15989bd7@news.frii.com...
> Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
>
>> Plain IDLgrImages are "funny" in other ways. In particular, where images
are
>> involved, visibility is controlled by drawing order, not vertical
position.
>> So moving your colour bar into some other sort of container is a good
idea.
>
> Maybe I'm just plum wore out, but I don't understand this,
> Mark. Could you elaborate?
When I wrote "So moving your colour bar into some other sort of container is
a good idea" I should have written "So representing the colour ramp in your
your colour bar with some sort of atom other than a stand-alone IDLgrImage
is a good idea". I was just agreeing with you--unusual, I admit.
The bit about IDLgrImages being "funny" referred to the fact that they are
two-dimensional objects in an otherwise 3-dimensional object graphics world.
This means (as you pointed out) you can't rotate them satisfactorily. It
also means that you can't control visibility by putting images above or
below other atoms in the Z direction. If you put an image then another atom
into a model, the other atom is visible over the image irrespective of its
vertical position. If you reverse the order in which they are put into the
model, the other atom is not visible over the image, again irrespective of
its vertical position. At least that's what my experience shows.
Of course the general guideline that you should control visibility/overlap
of graphics atoms (other than images) by vertical position and not drawing
order is one of those secrets the IDL documentation doesn't want to tell us.
---
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
|
|
|
|
| Re: Another Long Day Compliments of Object Graphics [message #21213 is a reply to message #21211] |
Wed, 16 August 2000 16:05 |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
"David Fanning" <davidf@dfanning.com> wrote in message
news:MPG.1404bdb94cb56014989bd6@news.frii.com...
> Basically, I wanted to put the color bar image into
> a polygon, since you can rotate polygons in 3D space,
> but you can't rotate images. (There is no practical
> purpose in rotating a color bar in 3D space that I know
> of, but I always find I learn as much about IDL
> by doing these silly little things as I learn by
> doing something I'm likely to get paid for.)
Plain IDLgrImages are "funny" in other ways. In particular, where images are
involved, visibility is controlled by drawing order, not vertical position.
So moving your colour bar into some other sort of container is a good idea.
> So, it's a simple matter of making the image a texture
> map of the polygon.
When I first tried texture maps I got funny results (odd pixel shapes &
sizes, I think) and reported it as a bug. The answer from RSI tech support
was, "Make sure texture map image sizes are powers of 2." -- Just a warning.
Another atom you could base your colour bar on is an IDLgrPolygon coloured
via VERT_COLORS. That should keep you busy for Another Long Day.
---
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
|
|
|
|
| Re: Another Long Day Compliments of Object Graphics [message #21217 is a reply to message #21211] |
Wed, 16 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
> If you put an image then another atom
> into a model, the other atom is visible over the image irrespective of its
> vertical position. If you reverse the order in which they are put into the
> model, the other atom is not visible over the image, again irrespective of
> its vertical position. At least that's what my experience shows.
>
> Of course the general guideline that you should control visibility/overlap
> of graphics atoms (other than images) by vertical position and not drawing
> order is one of those secrets the IDL documentation doesn't want to tell us.
Odd that you should mention this, because once I *did*
get the darn thing rotating I noticed that the tick marks,
which were at the same Z level as the polygon/image were
fading in and out with rotation. I moved the tick marks
up 0.001 unit in Z and all was well. Are you saying
I could *not* do this if I didn't have the image in
a polygon?
Humm. I'll have to check. But not today. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Another Long Day Compliments of Object Graphics [message #21219 is a reply to message #21213] |
Wed, 16 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
> Plain IDLgrImages are "funny" in other ways. In particular, where images are
> involved, visibility is controlled by drawing order, not vertical position.
> So moving your colour bar into some other sort of container is a good idea.
Maybe I'm just plum wore out, but I don't understand this,
Mark. Could you elaborate?
> Another atom you could base your colour bar on is an IDLgrPolygon coloured
> via VERT_COLORS. That should keep you busy for Another Long Day.
Ha! I was desperate enough about an hour ago I thought of
trying it. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
