Re: [Gzz] Asko 2002-10-21 (studying)

[Tuomas Lukka]

On Mon, Oct 21, 2002 at 06:04:02PM +0300, Asko Soukka wrote:
> 9h workday
> - ovalbgvob to use mipmap's
> - introducing into culling of coordsys problem
> 
> I'm still stuck in the beginning of culling coordsys, because I just can't 
> understand libcoords as a whole. Maybe some of the principles, but the 
> code in Coords.cxx looks still alien to me.

And completely uncommented, on top of that.

Make sure you keep bugging me to comment the most important bits.

> So, I tried to figure out how to continue. I understood that after 
> building interface I should have two coordinate transformations 
> available. 

Yes. The closest currently would probably be buoy and nadir coordinate systems,
or alternatively concatenation coordinate system.

> AFAIK my problem is to detect (in culledCoordsys' 
> shouldBeDrawn() method) do the unit squares of those two 
> coordinate system intersect. Detecting intersections is not trivial 
> because after transformation the unit squares might be quite distorted.

Yes. The nonlinearity() call should help, though.

It's absolutely vital that the common case, i.e. nonlinearity() == 0
for both systems be BLAZINGLY fast.

> What are those "two coordinate transformations"? Can I assume them as
> Renderable.Object => Window.Object and
> Clip.Object => Window.Object?

No, you can't *assume* that. You can *DEFINE* it to be so, and that would
be the right choice.

> Or can I more generally assume that 2D intersection detection is enough? 
> At least in Window.object it should be?

2D is exactly right. This coordsys type is for a very narrow use: putting in 
clipped stuff and getting it culled early.

> I'm been thinking about finding convex hulls for those distorted unit 
> squares. One convex hull for both at beginning, but if it's too 
> inaccurate, maybe more (by splitting the distorted unit square). 
> After finding convexes there should be fast intersection detection 
> algorithms for 2D convex polygons. I don't know them yet or haven't ever 
> implemented one, but I believe they exists O:-)

Here, remember that we only need absolute certainty in the NEGATIVE case.
We don't want to go through a long, complicated, painstaking process to find
out that they don't intersect, having spent more time than it would have
taken just to render them.

It *is* allowable to say that they intersect, even if they don't really.
The converse is not true.

        Tuomas