Messages
of InteractiveMesh published in Java 3D™ forum at java.net.
Thread: Auto-off-screen rendering limited to GUI-Components?
Off-screen video capturing has functional benefits:
- An off-screen Canvas3D can be created of any size (only limited by your graphics card) independant of the current on-screen Canvas3D's size and location; you don't need to adapt your GUI for video capturing (the ratio of width and height should be the same to assure that you get what you see)
- An off-screen Canvas3D allows to capture a video with transparent background (-Dj3d.transparentOffScreen=true, JMF javax.media.format.RGBFormat); this video can be rendered transparently into Swing Components or Java 3D's Textures and Raster geometries (I'm aware of the huge amount of raw RGB video data)
Secondly it has performance advantages (tested for video sizes up to 1024x512):
- If no user input (key or mouse) or visual control are needed, replace your on-screen Canvas3D by an AutoOffScreenCanvas3D in its View Node for the period of capturing time; compared to Robot.createScreenCapture() fps increases by 10-20% !
- If you build an on-screen lightweight Canvas3D from an AutoOffScreenCanvas3D (like JCanvas3D) and if you use this as the source for capturing as well you gain at least the performance of the Robot!
To get the most out of the JMF (Java Media Framework) I implement a "pre capturing of raw data". The BufferedImage data received from Robot or AutoOffScreenCanvas3D are captured first into the RAM(direct java.nio.IntBuffer) or on disc. Later these are taken as the javax.media.protocol.DataSouce for JMF's encoding etc.. Capturing into a direct IntBuffer costs about 2-5 fps, on disc 7-14 fps.
Performance and on/off-screen discussions are of no importance, if your Java 3D application is able to increase its animation timestamps (Alpha) by 33.3 ms (30 fps) or 40 ms (25 fps) discretly: rendering and capturing of each single frame can last as long as it needs. Not later than next morning your video will be finished.
Thread: Behavior Design - Navigator
Suggestions why you should implement your own navigator (ViewPlatform Behavior) to replace ViewPlatformAWTBehavior/OrbitBehavior:
0. This key functionality is so important that a navigator should not depend on Canvas3D and Java 3D utility classes like Configured/SimpleUniverse and ViewingPlatform. A navigator should support each java.awt.Component for user input (mouse/key) and each scene based on standard VirtualUniverse and ViewPlatform, too.
1. A navigator should be separated into Model and Controller. On one side the Model comprises operation mode and transformation related states, appropriate get-/set-methods and of course methods to change the current transformation according user/application input and to update the target TransformGroup's Transform3D. On the other side the controller is free to extend a Behavior or implement a MouseListener (or both) or to be forced by another "engine". According to received user/application inputs methods of the model are called and navigation is executed.
2. A hierarchy of navigation models and controller would allow to spread and combine the navigation capabilities as needed. Nested TransformGroups above a ViewPlatform could be targeted if all navigators are synchronized and enabled/disabled according to the operation mode.
Experiences: My own navigator controller extends Behavior. In the first step its process stimulation was based on WakeupOnAWTEvents only. But it seems as if in case of a very busy Java 3D engine MOUSE_RELEASED events get lost. As work around a MouseListener is also implemented which posts a WakeupOnPostID to assure termination of navigation.
Thread: Nested Scenes
A Java 3D(TM) scene (source scene) can be rendered within another target scene by using an (shareable) ImageComponent2D object as Background, Texture2D or Raster image. For capturing the source scene an off-screen Canvas3D is necessary that provides continuous rendering and a running BehaviorScheduler. A Behavior object has to take care that each frame of the source scene is copied into the target image.
This type of off-screen Canvas3D wasn't available in the past. In Java 3D 1.5.0 the marker interface 'com.sun.j3d.exp.swing.impl.AutoOffScreenCanvas3D' was introduced. An off-screen Canvas3D, which implements this interface, fulfils all requirements. Attention: This is an experimental interface, which is not intended for use by applications, but is used internally by the lightweight JCanvas3D implementation.
Even so existing code was combined into a single class to create a sample program: SceneInScene. More information can be found within the source code. The constructer and the two inner classes are the most important parts of it.
Feel free to download and launch SceneInScene. System requirements: JRE(TM) Version 5.0, Java 3D 1.5.0.
Download: SceneInScene-1.0.zip
Launch: SceneInScene Source & Target
Launch: SceneInScene Target
Thread: JCanvas3D - Lightweight Rendering
First experiences with lightweight rendering.
0. Be aware that Java3D rendering is still based on heavyweight java.awt.Canvas respectively on its subclass Canvas3D.
1. JCanvas3D is mainly a lightweigth GUI component and adds no more 3D-features or -capabilities to Java3D. It renders the off-screen buffer of a (not showing) Canvas3D as an image by overriding 'paintComponent()' and redirects events to its related off-screen Canvas3D. JCanvas3D looks like a very good starting point for having a stable Swing component available at the end. It also serves as a helpful recipe for different lightweight implementations.
2. On-screen Canvas3Ds can't always be replaced easily by JCanvas3D and its off-screen Canvas3D. For implementations that are limited to Canvas3D and don't except subclasses of java.awt.Component yet a redesign is necessary (see com.sun.j3d.*). Often Canvas3D is needed to get its View. Also JCanvas3D provides access to the related View per 'getOffscreenCanvas3D().getView().
3. The most important change affects Canvas3D! Since 1.5.0 Java3D renders continuously into an off-screen Canvas3D as it does into an on-screen one as far as this Canvas3D has the experimental marker interface 'com.sun.j3d.exp.swing.impl.AutoOffScreenCanvas3D' implemented. This results in continuous rendering into JCanvas3D because its internal off-screen Canvas3D has AutoOffScreenCanvas3D implemented. Redirecting the AWTEvents causes the generation of WakeupOnAWTEvents, too! It seems that the Java3D engine behaves similar for both, on-screen Canvas3D and AutoOffScreenCanvas3D!
4. Still, a non-auto-off-screen Canvas3D renders a single frame only in response to the request 'renderOffScreenBuffer()'. But a non-auto-off-screen Canvas3D alone doesn't force Java3D to start the behavior scheduler. As soon as an additional on-screen Canvas3D is added to any active View of the same VirtualUniverse the scheduler runs.
5. If an on-screen Canvas3D and an AutoOffScreenCanvas3D are added to a single View the on-screen Canvas3D doesn't render anymore. Moving one of them to another (empty) View restarts rendering.
6. Performance: on-screen Canvas3D / AutoOffScreenCanvas3D = 1 / 0.75
Suggestions:
- Java3D shouldn't behave differently in case of on-screen Canvas3Ds or
AutoOffScreenCanvas3D
- Replace interface AutoOffScreenCanvas3D by an additional Canvas3D
constructure parameter like 'boolean autoOffScreen'
- Behavior scheduler should run in case of non-auto-off-screen Canvas3D, too.