Re: [Gzz] OrthoCoordsys???

[Tuomas Lukka]

On Thu, Aug 22, 2002 at 02:17:49PM +0200, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >No, that's not the problem. The problem is the *HIERARCHICAL*
> >coordinate systems, which changed a lot of APIs (and also made 
> >a lot of jython GL-using code not work any more).
> >
> 
> Ah, I see. This doesn't have anything to do with OrthoCoordsys-- I 
> implemented the hierarchical coord systems before I implemented the 
> latter. OrthoCoordsys is just to make it faster (so that we don't need 
> to be so worried about creating many coord systems).

Ah, ok. I understand the confusion.

The problem was of course also that OrthoCoordsys had no documantation
whatsoever, as well as "cx", "cx2" like names.

And that the meanings of some quite central APIs had changed without
adjusting jython code...

> There are four issues involved here.
> 
> 1. Coordinates
> 
> OrthoCoorder stores the coordinates (and depth) absolute, not relative 
> to the parent coordsys, even though it gets the coordinates relative to 
> the parent. It simply adds the parent's x, y, and depth coordinates to 
> its own.

Yes. In OpenGL, we have a completely different set of tradeoffs 
that would have been nice to think about in the design: in OpenGL,
it's cheap to do real hierarchical cs, if you do all child cs
inside a parent cs at one time.

BTW: the coordinate stuff is also not quite all thought out yet, as
you don't scale the coordinates by the parent's coordinates; 
the way a coordinate system is "put into another" is quite arbitrary:
it translates but does not scale. In OpenGL, we'd of course want it
to scale as well as rotate, skew.

> 2. Interpolation
> 
> The current semantics are: Interpolate only inside the parent coordset, 
> i.e., interpolate A to B only if they have the same key *and* their 
> parents are interpolated to each other.

Yes, this is the one that causes the major breakage.

> This means that you need to do lookups by key *and parent*, and that 
> means java.util.Maps won't suffice. I've implemented my own in 
> OrthoCoordsysMap, which is tightly coupled to OrthoCoordsys.

Maybe loosening that coupling would be the right way to go?

> 3. Clipping
> 
> In OrthoCoorder, the clip rect is found by going through all parents of 
> a coordsys and taking the maximum left and upper and the minimum right 
> and lower coordinates of all ExtRects. (OrthoCoorder doesn't do this 
> right during interpolation, yet.)

Clipping is even harder to get right in OpenGL...

> 4. Depth sorting
> 
> In depth sorting, we draw first a coord system, then (above that) all 
> coord systems in it, the (above that) the next coord system on the same 
> level. The algorithm to do that takes some figuring out; see 
> OrthoDepthSorter.cmp().

And in OpenGL, depth sorting is not used at all - everything is drawn
in the order it was put into the vobscene, enabling stupid OpenGL tricks.

> Hm. Actually... I guess you could use OrthoCoordsys, in fact; you'd 
> simply need to store the coordinates you need in it (neither 
> OrthoCoordsysMap nor OrthoDepthSorter depend on the coords, I think).

That would make things quite a bit slower: we need the coords in one
contiguous array with 7 entries for each coordinate system.

> You could make OrthoCoordsys an abstract superclass (AbstractCoordsys), 
> and remove the w and h arrays from it. Then you could make two 
> subclasses, OrthoCoordsys (adding the w and h arrays), and 
> AffineCoordsys (adding xx, xy, yx and yy arrays). Would that work for you?

Why different arrays rather than one long one?

        Tuomas