[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] Asko 2002-10-21 (studying)
From: |
Tuomas Lukka |
Subject: |
Re: [Gzz] Asko 2002-10-21 (studying) |
Date: |
Mon, 21 Oct 2002 18:25:54 +0300 |
User-agent: |
Mutt/1.4i |
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