diff options
Diffstat (limited to 'www/j3d1_4/render-texture.html')
| -rw-r--r-- | www/j3d1_4/render-texture.html | 57 |
1 files changed, 51 insertions, 6 deletions
diff --git a/www/j3d1_4/render-texture.html b/www/j3d1_4/render-texture.html index 05cf1e9..42d74ab 100644 --- a/www/j3d1_4/render-texture.html +++ b/www/j3d1_4/render-texture.html @@ -3,31 +3,76 @@ <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"> - <title>Java 3D 1.4: Render To Texture</title> + <title>Java 3D 1.5: Render To Texture</title> </head> <body> -<h2>Java 3D<sup><font size="-2">TM</font></sup> 1.4: +<h2>Java 3D<sup><font size="-2">TM</font></sup> 1.5: Render To Texture</h2> <h3><span style="color: rgb(0, 153, 0);"><i>ROUGH DRAFT: This API is a Work in Progress</i></span></h3> <hr> <p>This page describes the possible render-to-texture feature in -Java 3D 1.4... +Java 3D 1.5. The main idea is to create new +"render-to-texture" subclasses of Canvas3D and View that would render +into a texture that could then be used in a scene graph to render into +an ordinary on-screen (or off-screen) Canvas3D. We will either need to +create special "rendered" subclasses of Texture (e.g., +RenderedTexture2D), or add a mode flag to the existing texture classes. +The former is cleaner from an API point of view, but the latter is more +flexible (e.g., it would allow some mipmap levels of a Texture or faces +of a TextureCubeMap to be generated by rendering and others to be +specified via an image).<br> </p> +<p>NOTES:<br> +</p> +<ul> + <li>A TextureView is rendered when any View that references a scene +graph containing its RenderedTexture object is rendered. The ordinary +View is said to be <em>dependent</em> on the TextureView.</li> + <li>Each TextureView is rendered before its <em>dependent</em> +View(s).<br> + </li> + <li>RenderedTexture objects cannot be in a scene graph that is +rendered by a TextureView. Violating this will lead to undefined +results. We may want to consider relaxing this restriction to allow for +cascading render-to-texture operations. If we do relax this, we may +need to provide a way for the application to specify an ordering of +TextureViews (determining the dependency graph would be difficult).<br> + </li> + <li>To make it easier for an app to comply with the above, we will +add a new feature to View: a boolean +attribute indicating whether to render <strong><em>only</em></strong> +to nodes under a ViewSpecificGroup. This flag is false by default for +an ordinary View and true by default for a TextureView.</li> +</ul> <p>The proposed API is:</p> <ul> <li>New classes</li> <ul> - <pre>public class XXXXX extends YYYYY<br> method: setXxxxx()<br></pre> + <pre>public class TextureView extends View<br> method: setXxxxx() // Any methods here?<br><br>public class TextureCanvas3D extends Canvas3D<br> method: setRenderedTexture(RenderedTexture) // or should this be immutable?<br> method: setLevel(int level)<br> method: setFace(int face)<br> // override lots of Canvas-related methods and throw UnimplementedException<br><br>public class RenderedTexture extends Texture<br> method: setXxxxx() // Any methods here?<br><br>public class RenderedTexture2D extends RenderedTexture<br> method: setXxxxx() // Any methods here?<br><br>public class RenderedTexture3D extends RenderedTexture<br> method: setXxxxx() // Any methods here?<br><br>public class RenderedTextureCubeMap extends RenderedTexture<br> method: setXxxxx() // Any methods here?<br></pre> </ul> <li>New methods in existing classes:<br> </li> <ul> - <pre>XXXXX<br> method: setXxxxx()<br></pre> + <pre>View<br> method: setViewSpecificGroupOnly(boolean)<br></pre> </ul> </ul> -<p>More info here... +<p>Issues: </p> +<ol> + <li>Can the resulting image be read back to the application?<br> + <span style="font-style: italic;">[we don't plan to allow this]</span><br> + </li> + <li>What is the best way to ensure that there is a valid source of +all mipmap levels (and all faces of a cube-map)?</li> + <li>Should RenderedTexture be a mode or a subclass?<span + style="font-style: italic;"><br> +[currently proposed to be a subclass]</span></li> + <li>Since this feature encourages using implicit mipmap generation, +we need to file an RFE to implement implicit mipmap generation using +OpenGL HW mipmap generation.<br> + </li> +</ol> <p><font color="gray">Page last updated — $Date$ </font></p> |