Paul Pantera wrote: > > Note: Justin and I are discussing RasterTextLabel, which > uses Java 3D rasters for text labels (duh).
Popular suckers aren't they. Seems everyone likes Raster labels. > >> First, alwaysOnTop isn't working. It seems to have no affect. Maybe > >> there's a bug in Raster where it's ignoring > setDepthBufferEnable(false)? This seems odd that you are not seeing things correctly. Last night I ran the demo on Alan's machine which is a GF2 and J3D OpenGL and it worked perfectly, just like my AIT/D3D equipped laptop (which has show several other serious texturing-related driver bugs) > A raster is a Shape3D and should be transformed by any TransformGroups > above it in the scenegraph. Rasters are actually Geometry under the shape3D, but yes they should be transformed like every other item in the scene graph. > The (X,Y,Z) position of the raster should work like a translation > from the transformed position of the raster. For example, if > a TransformGroup above the raster is rotating the raster by 90 > degrees around the Y axis, turning it sideways, then if the > raster's position is (1,0,0) then it should move the object > back, away from the viewer. (Right?) Rasters are always pixel perfect in size. I raster pixel is one screen pixel. That means that rasters don't appear to move forward and backward because their size never changes. However, if they are in the scene graph and you ae doing depth-buffer comparisons, then they may be occluded by other geometry. In addition, they will always be subject to clipping planes because they live in 3D space. > I'm getting the geometry out of the RasterTextLabel, which is a Raster, > and using setDstOffset to center the image on the Raster. This is > working fine, except that I'm supplying a positive X and Y offset and > it's moving the raster up and to the left, so I think there may be > a sign problem there. No, that sounds right. Remember that bitmap space is standard image space. The coordinate system is in the top-left corner of the image with +X across and +Y down. Apply positive offsets to the destination means, effectively, shifting the origin of the raster towards the center of the raster. The visual effect should be to move up and to the left if the parent transformations stay still as you are seeing. > The main problem I'm having is with depth buffering. > Even if I turn off depth buffering entirely on the raster, it still > gets depth-buffer compared. I think what you might be seeing is render-traversal dependent. How have you specified your scene graph? I bet that you have the rasters in a branch that gets rendered before the other items. Turning off depth buffer testing does not mean that it should always be on the top of your rendered window. All it means is that when the pixels exit the pipeline and get deposited to the framebuffer that they never checked the depth of the objects previously written to that space and just blit straight to it. If further rendering of other objects also happen to cover that same pixel, and have depth less than the pixel depth of the raster, that will be used in preference. What you really need to do is make sure that the rasters are in an OrderedGroup to ensure that they get rendered last. -- Justin Couch http://www.vlc.com.au/~justin/ Java Architect & Bit Twiddler http://www.yumetech.com/ Author, Java 3D FAQ Maintainer http://www.j3d.org/ ------------------------------------------------------------------- "Humanism is dead. Animals think, feel; so do machines now. Neither man nor woman is the measure of all things. Every organism processes data according to its domain, its environment; you, with all your brains, would be useless in a mouse's universe..." - Greg Bear, Slant ------------------------------------------------------------------- =========================================================================== 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".
