Re: [Gzz] Coordinates, shape

[Tuomas Lukka]

On Tue, Sep 10, 2002 at 11:53:07AM +0200, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >>Ok, so what do we do about the current killer problems:
> >>- text aspect ratio
> >>   
> >>
> >
> >Avoid it for the demos
> >
> 
> Um, in that case I'd rather do the storing w and h crude fix now. As I 
> stated before, what I really want currently is getting the GL client to 
> work, in order to have a working Gzz on my machine. The current text 
> makes it unusable.

Oh, do you mean fixing
1) interpolation
or
2) text width in normal case?

For 1), the fix is difficult and would require the w+h hack.
2) can be fixed just by giving the text vob its own, reasonable coordinate
system.
I was assuming that you were talking about 1).

> >>- clipping
> >
> >Use the stencil buffer, and normal OpenGL clipping, with OpenGL state
> >put in.
> >
> 
> That doesn't answer the question. Where (code-wise) and what do we clip?

Code-wise, we'll have an encapsulated routine that takes the vob(s)
to draw the stencil, the routine to put the vobs inside.

Or am I also understanding the question wrong here? I think we may
be using different concepts too often right now, with you thinking 
about the cell view and me about the buoy view.

> >>On a mildly related note, how are connections supposed to be done in 
> >>GL? We need to make connections work relatively soon.
> >>   
> >>
> >
> >If all the coordsys stuff were working, we'd just put the two 
> >coordsystems
> >of the end points to it. However, since we want rotations and will do 
> >them
> >in nasty ways, we'll probably just have separate coordsys for the ends
> >of the connections.
> >
> 
> But how do we draw the connection? I know how to draw something in the 
> first coordsys, but I have no idea how to draw a line between the first 
> and second coordsys of a vob.

See renderables.py: it's all in there. There are vobs that take two
coordinate systems. Then, inside the vob, you just get the coordinates
appropriately. Naturally, this can't be done using callgl since
the coordinates have to be calculated on the C++ side.

> >One of the problems is mipmapping: the characters
> >get blurred because making a large character and then downsampling
> >gives a blurry small character.
> >
> >The solution is given in TODO.
> >
> 
> Ok.

Actually, a good stopgap measure might be simply to render the characters
at size 2^n instead of something like "40" currently. That could
improve it considerably. Also, have you tried __GL_FSAA_MODE ?
It helps a little.

        Tuomas