blob: 42d74ab70f4f4757f9707e6cd491bfdb695052f6 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title>Java 3D 1.5: Render To Texture</title>
</head>
<body>
<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.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 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>View<br> method: setViewSpecificGroupOnly(boolean)<br></pre>
</ul>
</ul>
<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>
</body>
</html>
|
