9 |
<p>Hierarchical <tt>VobScene</tt>s need some fixing.<br> |
<p>Hierarchical <tt>VobScene</tt>s need some fixing.<br> |
10 |
</p> |
</p> |
11 |
|
|
12 |
<p>Open issues:<br> |
<h2>Open issues:<br> |
|
</p> |
|
13 |
|
|
14 |
<ul> |
</h2> |
|
<li>Is the integer identifier of the coordinate system into which to |
|
|
place a new coordinate system appropriate?</li> |
|
|
<li>Should plain coordinate systems be usable as those ints? |
|
|
<small>(Benja:) "Plain coordinate systems"?</small></li> |
|
|
|
|
|
<ul> |
|
|
<li>What are the semantics there? Current, just translate, is not good. |
|
|
However, using the vob-internal CS is not really nice either, as Vob CSs |
|
|
usually are in pixels, and this would be in 10s or 100s of pixels per unit.</li> |
|
15 |
|
|
|
</ul> |
|
|
<li>The most general use case is the PP-like viewport. How is that implemented? |
|
|
You need</li> |
|
16 |
|
|
17 |
<ul> |
<ul> |
18 |
<li>clipping</li> |
<ul> |
|
<li>separate coordinate system for the motion of the clipping rectangle |
|
|
and the contents</li> |
|
19 |
|
|
20 |
</ul> |
</ul> |
21 |
|
|
22 |
</ul> |
</ul> |
23 |
Possible solutions:<br> |
<h2>Suggested solution:</h2> |
24 |
|
Vobs should not have to worry about clipping, |
|
<ul> |
|
|
<li>Separate clipping from coordinate systems. Currently, a coordinate |
|
|
system defines a clip rectangle. How about specifying the coordinate system |
|
|
to clip to when creating a (any) coordinate system, as well as the coordinate |
|
|
system into whose coordinates the given coordinate system should go.<br> |
|
|
<small>(Benja:) This doesn't serve well in the usual viewport case, where |
|
|
you have: |
|
|
<ul> |
|
|
<li>A thing you want to view (e.g. a PP paper, the contents |
|
|
of a cell)</li> |
|
|
<li>A place inside that thing where your focus is (you want to |
|
|
view the stuff around the focus)</li> |
|
|
<li>An area on the screen where you want to show the viewport |
|
|
(so that the focus is shown in the middle of the viewport, |
|
|
and as much of the viewed thing is shown around the focus |
|
|
as fits in the viewport). |
|
|
</li></ul> |
|
|
Calculating the position of the viewed thing relative to the viewport |
|
|
is easier than calculating the absolute position of the viewed thing |
|
|
on the screen: to calculate the position relative to the viewport, |
|
|
you don't need to know the viewport's position, just the focus; |
|
|
to calculate the absolute position on the screen, you need both, |
|
|
essentally translating the focus coordinates by the viewport's. |
|
|
<br><br> |
|
|
Therefore, I think that there is no need to special-case this in |
|
|
the API, as it's easier to do with two nested cs.<br> |
|
|
(Tuomas:) Sorry, I don't follow this argument at all. Could we start using |
|
|
(x,y,w,h) etc. notation, since the verbal description is a bit hard to follow? |
|
|
Even more so, pictures would be good...</small></li><li>A suggested principle: Vobs should not have to worry about clipping, |
|
25 |
neither in AWT nor in GL. The current system where a Vob has to set its cliprect |
neither in AWT nor in GL. The current system where a Vob has to set its cliprect |
26 |
works for really simple cases but gets inefficient and inconvenient.</li> |
works for really simple cases but gets inefficient and inconvenient.<br> |
|
<li><tt>createCoordsys(int transformedBy, int clippedBy, Object key, ...)</tt></li> |
|
|
<li>0 would be default for both, i.e. no clipping, no transformation.</li> |
|
|
<li>Unfortunately, to get the translate-and-clip effect, you'd need two |
|
|
different coordinate systems:</li> |
|
|
<ul> |
|
|
<li>clipping: the current one (x,y,w,h)</li> |
|
|
<li>transforming: (x-1, y-1, 2, 2) would give the correct one. Of course, |
|
|
we'd have shortcuts for these.</li> |
|
|
<li>OTOH, you could just create the clipping one and give the coordinates |
|
|
explicitly anyway, if that's the meaning; that would work.</li> |
|
|
<li>What are the semantics there? Current, just translate, is not good. |
|
|
However, using the vob-internal CS is not really nice either, as Vob CSs usually |
|
|
are in pixels, and this would be in 10s or 100s of pixels per unit.<br> |
|
|
(Benja:) I think use the parent cs to translate and optionally give a scale |
|
|
when creating the sub-cs, and use the parent for clipping. I think this |
|
|
serves well in the usual case. |
|
|
</li> |
|
|
|
|
|
</ul> |
|
|
<li>Clipping would work recursively:</li> |
|
|
<li>The most general use case is the PP-like viewport. How is that implemented? |
|
|
You need |
|
|
|
|
|
</li><li>cs1 = createCoordsys(0, 0, ...)</li> |
|
|
<li>cs2 = createCoordsys(0, cs2, ...)</li> |
|
|
<li>would clip by both coordinate systems when cs2 used.<br> |
|
|
</li> |
|
|
<li>clipping</li> |
|
|
<li>separate coordinate system for the motion of the clipping rectangle |
|
|
and the contents</li> |
|
|
|
|
|
</ul> |
|
|
|
|
|
<p>(Benja:) I thought rotation/scaling? The above is extremely easy to do by |
|
|
putting two cs into each other, the parent being used for clipping, |
|
|
and the child being used for the contents.</p> |
|
|
<p>(Tjl):How would you specify that? You'd have to think about the inner coordinate system relative to the outer, right?</p> |
|
|
<p>(Benja:) Aaah, now we get to the real discussion! Yes, that's exactly what |
|
|
I mean. Now if you can give me a single good case where this is |
|
|
inconvenient and your system is more convenient, you've gone a long |
|
|
way in convincing me of it. <tt>;-)<br> |
|
|
</tt></p> |
|
|
<p>(Tjl:) Easy. Imagine a skewed, perspective coordinate system (i.e. |
|
|
using the homogeneous coordinate transformations of OpenGL). Now imagine |
|
|
e.g. putting an image behind a viewport transformed like that it so that |
|
|
you *don't* want to transform that image. Finding the inverse transformation |
|
|
there is not trivial and requires inverting a 4x4 matrix. It <b>can</b> be done but it's nasty. I can well imagine wanting to do this. Even with just rotations there's too much to worry about.<br> |
|
|
</p> |
|
|
<p> |
|
|
(Benja:) Ok. And you could still do the more usual case where you <em>want</em> |
|
|
to think of the inner coordinate system relative to the outer: you can |
|
|
still put your transformation coordsys inside your clipping coordsys... |
|
|
</p> |
|
|
<p> |
|
|
(Benja:) Hmmm, issue: Before hierarchical coordsys, we used coordsys essentially |
|
|
as bounding boxes for vobs (ok, different in pp, through the (AFAIK) |
|
|
complicated PP viewport mechanism). But a coordsys is actually a cross |
|
|
between a box and a coordinate transformation to you, if I understand |
|
|
correctly: you want to use the vectors inside the coordsys as the unit |
|
|
vectors for transformation coordsys in your hierarchical scheme |
|
|
(meaning that when using OrthoCoorder, you would often create coordsys |
|
|
with width = height = 1, because you do not want scaling). |
|
|
This isn't very elegant, especially because vobs aren't truly |
|
|
(graphically) scaled by changing their coordsys' width and height... Hm<br> |
|
|
<br> |
|
|
(Tjl:) Of course, the API needs changing in that case. Something like<br> |
|
|
</p><tt>/* Get a coordinate system which is translated dx, dy from the given coordinate</tt><br> |
|
|
<tt> * system.</tt><br> |
|
|
<tt> */</tt><tt><br> |
|
|
int translate(int transBy, int clipBy, Object key, float dx, float dy);</tt><br> |
|
27 |
<br> |
<br> |
28 |
And so on. Affine coordinate systems would also have <tt>rotate</tt>, and |
The suggested API change is in the file coorders.java.<br> |
|
with that we would actually get rid of the current problem with affine coordsys |
|
|
interpolation as well, where interpolation across a rotation shrinks (since |
|
|
the coefficients go linearly), getting us closer to the semantics. <br> |
|
29 |
<br> |
<br> |
|
This takes us closer to a scene graph... maybe that's a good thing. It may |
|
|
be easier to explain to people that Vob coordsystems are nodes in a scenegraph |
|
|
that get identified with nodes in another scene graph.<br> |
|
|
<p>(Benja:) Starts to sound really good, but I don't completely understand yet. |
|
|
Care to propose a full interface (i.e., a list of *all* supported methods)? |
|
|
I think that would help me getting the "big picture" here. (Just giving the |
|
|
method signatures would probably suffice.) |
|
|
|
|
|
|
|
|
<p> |
|
|
|
|
|
|
|
|
<br> |
|
|
Transforming and clipping:<br> |
|
|
<img src="d1.png" alt="Showing an example" width="569" height="788"> |
|
|
<br> |
|
|
|
|
|
</p> |
|
30 |
|
|
31 |
|
The most general use case is the PP-like viewport. To achieve that, you need |
32 |
|
|
33 |
|
|
34 |
|
<ul> |
35 |
|
<li>cs1 = createCoordsys(0, 0, ...), the coordinate system of the frame.</li><li>cs2 = createCoordsys(0, cs1, ...), the coordinate system inside.</li><li>would clip by the frame coordinate systems when cs2 used.<br> |
36 |
|
</li> |
37 |
|
</ul> |
38 |
|
Another use case is the cell content. There, <br> |
39 |
|
<ul> |
40 |
|
<li>cs1 = createCoordsys(0, 0, ...) the frame coordinate system</li> |
41 |
|
<li>cs2 = translatedCoordsys(0, cs1, ...) the internal coordinate system<br> |
42 |
|
</li> |
43 |
|
</ul> |
44 |
|
<ul> |
45 |
|
<li>Note about cells: As discussed in Documentation/TechReports/Graphics, |
46 |
|
there is a really nasty special case for cell-like things where you interpolate |
47 |
|
them, changing the aspect ratio. Because of this, the rendering code needs |
48 |
|
to either 1) look at the external coordinate system, or 2) get more interpolated |
49 |
|
information. This is something we might want to consider.</li> |
50 |
|
</ul> |
51 |
|
|
52 |
|
|
53 |
|
<ul> |
54 |
|
</ul><p> |
55 |
|
</p> |
56 |
|
|
|
<br> |
|
57 |
|
|
58 |
<h2>Coordinate systems</h2> |
<h2>Coordinate systems</h2> |
59 |
<p>One thing that is currently not used enough with vobs is the possibility |
<p>One thing that is currently not used enough with vobs is the possibility |
71 |
<br> |
<br> |
72 |
<br> |
<br> |
73 |
<br> |
<br> |
74 |
</body></html> |
<br> |
75 |
|
</body></html> |