Thanks for your responses. There has been some discussion on 'which way
is the best way to implement overlays'. I think there is no
'perfect' way to do it, and it definately depends on what you are trying
to accomplish.
This is why I have just provided the mechanism to do as you please,
whether it is in one texture or many smaller textures.
One way to do this is to put one texture (i.e. Buffered
Image, or Raster) overlaying the entire canvas, then draw to the Graphics
object, similar to AWT. Then it can be updated every frame. The problem with
this is that it requires a large (possibly very large, if the size of the
Canvas3D is just above a power of 2, i.e. 513x513, since it would require
1024x1024 sized texture to get updated every frame. Definately workarounds
on this one, but can get ugly). Another problem is if you are doing this
in stereo with different Z values, then you cannot do it with one texture.
This is the basic problem with trying to do overlays in 3D, is that you
always want to minimize the amount of textures that are used. If you are
changing only a small portion of the screen, then you might want to use a
separate, smaller texture for that change. For example, a button could be
just two textures that get interchanged in the Appearance node, which will
require minimal amount of texture memory.
Also, if you just want to move a GUI object, you will have the ability to
do so by simply manipulating the SceneGraph the texture is in (under the
OverlayGroup). You have to be careful with picking these textures! Just
need to check to make sure the pick is inside the part of the texture that
is drawn, and not your transparent part that is larger because of the
requirement of texture dimensions being a power of two (it is a simple
check).
B
On Tue, 12 Jun 2001, Kasparian, Raffi J. wrote:
> Blaine, thanks for the code. With all the talk about overlays right now, I
> don't understand why no one else has commented on it. Any way, I look
> forward to playing with it in a couple of days.
>
> Raffi
>
> -----Original Message-----
> From: Blaine Alex Bell [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 11, 2001 4:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA3D] Overlay Library: Implemented
>
>
> Woops, forgot to put this test file with my last message. This program is
> a simple example of how you can use the OverlayGroup. (simple
> modification of HelloUniverse).
>
> B
>
> On Mon, 11 Jun 2001, Blaine Alex Bell wrote:
>
> > Here is the Overlay Library that I have implemented. I have tried
> > minimizing this implementation so it can be as flexible as possible.
> > Two classes exist, both in the package edu.columbia.cs.cgui.j3d:
> > FixedCanvas3D and OverlayGroup.
> > FixedCanvas3D is interchangeable with Canvas3D, and NEEDS to be used if
> > you want to use OverlayGroup. OverlayGroup allows you to place overlayed
> > objects by having a Node that is in pixel coordinates (origin is in the
> > bottom left hand corner of the Canvas), and gives you the
> > flexibility to create a scenegraph below this group node to place the
> > overlay objects.
> >
> > Some functionality that you might find useful:
> >
> > * Supports all View Model Parameters that are not part of head tracking.
> > As noted in the documentation, you cannot currently do Overlays in a head
> > tracked environment (Java3D limitation, hoping to be fixed in the near
> > future).
> >
> > * Supports changing Z values for Overlays. This gets very interesting,
> > especially in stereo since 2D overlays cannot do this. You do not need to
> > use this functionality, you can also place it directly in front of the
> > front clipping plane.
> >
> > * Works around the 'lag' problems introduced in the WakeUpOnElapsedFrame
> > behavior because Canvas3D caches values from previous frame. Also, I
> > provide new functions in FixedCanvas3D that should be in Canvas3D, such as
> > transformations relative to the ViewPlatform.
> >
> > Please send be comments/suggestions. I know that this is a hot topic on
> > this newsgroup, and I hope this helps everyone.
> > Please let me know what you think!
> > Soon coming: A View Model Demo Program to explain this crazy View Model!
> >
> > Blaine
> >
> > On Mon, 11 Jun 2001, Artur Biesiadowski wrote:
> >
> > > "Yazel, David J." wrote:
> > >
> > > > 17. No plans to implement resize because of the issus involved in
> rebuilding
> > > > the sub-textures. Would be easier to just make a new one. We might
> support
> > > > use of model-clips to clip in from a maximum size.
> > >
> > > I was trying to do overlay system some time ago and failed. Anyway, I've
> > > come up with following interface - it might be an overkill if you don't
> > > plan resize, but maybe you will like to reuse some idea.
> > >
> > > Overlay have specified xoffset, yoffset, width and height at creation
> > > time. These are double values, with following meanings:
> > >
> > > xoffset -
> > > if positive > 1, means distance of left edge of overlay from
> left side
> > > of window in pixels
> > > if negative < -1, means distance of right edge of overlay from
> right
> > > side of window in pixels
> > > if positive < 1, means how much free space should be used for
> the left
> > > side (fraction)
> > > if negative > -1, means how much free space should be used for
> the
> > > right side (same as 1+negative)
> > > yoffset - the same, just top and bottom
> > >
> > > width -
> > > if positive > 1 means width of overlay in pixels
> > > if negative < -1 means how much free width should be left on
> screen
> > > after substracting overlay width (in pixels)
> > > if positive < 1 means width of overlay as fraction of entire
> window
> > > width
> > > if negative > -1 means fraction of width which should be
> unoccupied by
> > > overlay (same as 1+negative)
> > > height - same as width, just for height
> > >
> > > This would allow for very dynamic system, but unfortunately size of
> > > texture would have to change with window resizes. It might be too much
> > > for your needs, then please implement at least negative offsets - to
> > > allow placing overlay relative to right and bottom edges (not only top
> > > and left). Fractional offsets would be also nice (allows for example
> > > centering with 0.5, 0.5 offsets).
> > >
> > > Artur
> > >
> > >
> ===========================================================================
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > > of the message "signoff JAVA3D-INTEREST". For general help, send email
> to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> > >
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff JAVA3D-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
