Hi, I'm wondering if anyone could give me some insights as to what's happening 'under the hood' in J3D when switching textures in a live scenegraph. A couple of weeks ago I read an old message in the mail list archives from someone asking whether it was possible to show AWT components within Java3D by simply using normal paint methods. I was intrigued by this and decided to try it out with an HTML renderer I wrote some time back. Basically I'm just rerouting the paint calls of this renderer to an Appearance class which has two referenced textures. Only one of these is in the scene at any time, allowing the other texture's Image2DComponent to be updated with the HTML renderer's output. When the paint call is complete the textures are switched. As you can probably imagine with all this imaging, the memory cost is pretty expensive. Web pages are usually formatted to a minimum width of 640 pixels, so even a 512x512 texture doesn't allow me to format the HTML as the author intended. Nevertheless, it works. I've put a separate HTML Appearance on four faces of a cube (six is pushing it...) and the pages will update within the scene in real time, asynchronously loading from various URLs across the Web. Animated GIFs work, and I'm able to tab between and activate hyperlinks. However, I've got two basic problems: first the program always seizes up after a while. This can be after 10 secs, or after 20 mins. The renderer is being used in commercial help systems/apps and I'm happy that it's robust, but when interacting with J3D it looks like there's some sort of thread lock-up (I'm only surmising this due to the intermittent nature of the crashes). Maybe this is something I just need to work on. More importantly though - and this is what I'd like some guidance on - the texture switching is quite slow: about 0.7 secs on a fairly fast, 3D accelerated PII. This means the animated GIFs are slow to update, and scrolling/tabbing via the keyboard is also slow. Will this always be the case do you think? Is this a limitation of the underlying hardware? [I ought to point out that my interest in Java3D has nothing to do with HTML - I just used the renderer because it was an obvious component to test this with, since it has to handle text, drawing and image rendering. Viewing Web pages in 3D is, er, surreal...] If texture switching could be handled rapidly (or even better if you were simply allowed to blit an image straight into an ImageComponent2D object while it's live in the scenegraph) then the whole of the Java Graphics2D API would be directly usable on the fly in J3D - image filtering, animations, graphics primitives, together with all the millions of lines of paint code in existing Applets/Applications. I guess someone's going to tell me I'm asking the impossible here, but it would be a pity if that's the case. With only a few lines of code any AWT/Swing paint call can be routed into a J3D Appearance. (BTW, as a final point, the original poster asked if it was possible to show a Java3D scene running in a Java3D scene. I don't see why not, but some of the AWT paint calls would need to be slightly modified so that the Canvas3D's paint routines will still be fully processed even when the component isn't visible on the screen. This wouldn't be necessary however if you simply duplicated every graphics call so that the first call is painted to a visible Canvas3D component, and the second to a texture. This would allow you to show (say) a computer monitor in the virtual world which is rendering a view identical to that of the Canvas3D). Thanks for any replies, and excuse me if I'm missing the obvious here, or if this has been answered a hundred times before. Andrew Moulden CN Media Ltd. =========================================================================== 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".
