Hey everybody. David Yazel posted some code to to overlays a little bit back and I have been playing with that code. Things are coming together pretty well and I like how things are looking. I got caught up in talking about it today with a friend of mine and it is a descent overview of some of the implementation and also some of the changes. It is definitely more info than most of you will care to read about but I figured I'd share it. Things are still in something of a mess. I haven't redone any of the comments and I would like to be able to reproduce the demo that David put out so I am not going to post any code just yet but I figured I'd put this out as a teaser. =) Will ---------- Forwarded message ---------- Date: Wed, 27 Jun 2001 12:02:55 -0500 (CDT) From: Will Holcomb <[EMAIL PROTECTED]> To: Matt Estes Subject: assignment [ Blah, blah, blah bitching about the VB I am working in... ] I am really pushing to get this migrated to java. Say what you like about it but given the evil of VB I'm sure you'll agree most anything is lesser. Oh, I did something neat yesterday in java. I have been working on overlays by placing a textured quad right in from of the viewplane, right? Well, I wrote this little class that writes two textures to the card and then when your mouse goes over the space that the overlay is occupying in the view it swaps the texture being used. You can do mouseovers in 3d, it is pretty cool. =) Because the textures are on the card and you are just swapping the one used they are quick too. Java3D has what are called Behaviors in the scene graph. A behavior has a wakeup. You can wakeup on an event or when some other behavior posts a notification or when the view platform intersects the bounds for the behavior or after a certain amount of time has passed or whatever. There are lots of different possible criteria. The nice thing about a behavior is that the code executing behaviors runs in the render thread before the render. That way anything done when a behavior is triggered ends up in the next rendered frame. If you have something long that you don't want to wait for you can always kick off a thread to take care of it. Anyhow, I am kinda proud of how the swapping stuff works. The overlay is registered as a MouseMotionListener for the canvas so it gets calls to mouseMoved(MouseEvent e) while the mouse is moving. It knows what space on the canvas it occupies so it can do an intersection test. If the mouse is over and it wasn't before (or vice versa) then it toggles the boolean tracking if the mouse is over and dirties itself. (That sounds nice, doesn't it?) The textures are not switched straight off because the renderer could catch them in an inconsistent state. Instead the overlay has a behavior in the scene graph. It calls updateRequested() in the behavior and then behavior then posts an id to the render manager. The behavior has a wakeupOnPost where the behavior it is listening to is itself and the id is the one it posts when the overlay requests an update. So the render manager checks to see if any behaviors are set to wakeup on a post of that id from that behavior, finds the behavior itself is, allows the behavior to run and then rerenders. The behavior then is woken up by the render manager. It then calls back to the update() on the overlay that requested the update and the overlay can then swap the textures being certain that the renderer won't catch it with its pants down. =) Neat, huh? It gets better. =) Overlays don't have to request an update from a behavior, they just request an update from something implementing UpdateManager (which includes the update behavior.) There is a class though that just takes an array of overlays and lets you scroll then around the circle. (This is useful for a chatbox.) You don't want to redraw the chatbox each time because that would take putting new textures on the card which is expensive. You can break the whole thing into one line apiece and then just move them around and that is pretty cheap. When something scrolls off the top just put it on the bottom. Well, the scroller also implements UpdateManager and it sets itself as the manager for the elements it contains. This way when it is setting positions each item that is moved will think it is dirty and need to move. If each one had its own behavior some of them might manage to move in one frame and then the rest would play catchup. Since the scroller is the update manager though as you move each one the scroller can catch the update request and make sure they all go through at once. The scroller does its updates in the same way as the overlays. It dirties a property, say line order. Then it requests an update and doesn't actually move the lines until update() is called. I keep track of a bunch of different properties so that things that aren't dirtied don't get changed. All of this code came from another guy who is working on a java3D mmpg called cosm. http://www.cosm-game.com/ You should look at some of the screen shots, it looks pretty neat. (Not trying to convert you or anything, just admiring out loud.) =) I wanted to understand how it worked though and so I started stepping through it reformatting it to my general 8-12 letter variable names. =) My fortune on /. yesterday was: "There are two types of Linux developers; those who can spell and those who can't, and they are in constant battle." After I did the variables I started screwing with the algorithms and made a couple of the n-dimensional (there are now n buffers rather than 2) and you now scroll by n lines rather than 1. Figuring those sorts of problems out entertains me. Not especially useful but entertaining. =) Also the update structure I talked about is my own. The original had a wakeupOnFrameUpdate so it was just running all the time (every frame triggers the behavior again.) Changing that messed up one of the examples; it was a fps overlay and it worked because the overlay itself kept the renderer running. Switching to an on demand update meant that it only updated when the overlay updated which was once a second. One frame / a little bit more than one second is an integer framerate of 0. =) I think I like the scroller the best though. There was a version of it before made specifically to scroll lines of text for a chatbox. The class had to be overridden specifically and painted in a special way to get it to work. This one scrolls any sort of overlay and overlays of arbitrary sizes. Repaints are handled only by the overlay (updating is managed by the scroller but the overlay doesn't know that.) Also before the scroller was responsible for handing repainting the overlays when they scrolled around, it just fires an event now and you can do whatever is appropriate for the scrolled item (blank text, do nothing for buttons, whatever.) Can you tell I've been getting into this stuff? =) I coded for like 15 hours yesterday and hardly noticed. I forget to eat when I get going, but you know what that's like. =) I was working the stuff up into a form I liked to do some effects on the demo for the recording that I am working on. I'm glad I've been playing with it, I learned alot doing it. Now I have to start in on the recording stuff which is using the java media framework api which still confuses the devil out of me. =) Whenever I get it going though I'll send you a link to a movie. Ttyl Will =========================================================================== 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".
