Re: [Gzz] Coordinates, shape

[Benja Fallenstein]

Tuomas Lukka wrote:

> 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?

2).

> 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).

Ah, ok. Fine.

> > 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.

Yes, could be. What I mean is, if we don't change any semantics, the 
cells will work if we clip by the coordsys hierarchy: i.e., if vob V is 
in coordsys C1, C1 is in C2 and C2 in C3, then V is clipped to the 
smallest area that is inside C1 AND inside C2 AND inside C3 (forgot the 
mathematical term right now).

So,
a) is that system ok for what you need in the demos? Or do you need the 
more flexible approach already, where you can define clipping 
independently from translation/transformation?
b) How do we implement it? I.e., what code does set the clip area? (In 
AWT, the vob asks the VobRenderInfo for the clipping rectangle, then 
issues the clipping command itself, but somehow I got the feeling you 
won't like that for GL.)

> > 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. 

(Do you realize renderables.py is REALLY hard to understand in its 
undocumented state?)

> 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.

Achso. So what do I use?

Is there some vob constructor in renderables.py I should use? Where do I 
find out how to call it?

It would be nice if renderables.py would insert Javadoc for every 
renderable into GZZGL...

> > > 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.
>  

I don't know how to turn it on...

Remember that I'm very much of a beginner with all things OpenGL.

- Benja