Re: [Gzz] Asko 2002-12-04/05 (OvalBgVob)

[Tuomas Lukka]

On Mon, Dec 09, 2002 at 05:32:14PM +0200, Asko Soukka wrote:
> Fri, 6 Dec 2002, Tuomas Lukka wrote:
> > >    + I'd like to implement GL side for all of them as renderables
> > >      (and make them dice). Though, I'm not yet sure, how should those
> > Hmm. What exactly are the things you want to draw?
> 
> I'm not sure yet :) I just would like to make also normal vobs dice and
> then test if distorted coordinate systems could be somehow used in
> "general" views (at least in my BubbleView).

I really like the sound of that!

> I wonder, how text renderables could be made dice?

Not too difficult. Just a little extra code in some places.

> And does this make rendering too s l o w ?-)

Not really. We're not using even half of the tricks we could be using:
to get more vertex bandwidth, we can start using GL_EXT_compiled_vertex_array
and GL_NV_vertex_array_range, and optimize coordinate systems generally.
There's a *LOT* of slack we can take away when the need comes.

> > What type of methods would ViewTool contain, exactly? Could you give
> > some examples?
> 
> It would abstract things like VanishingClient, but not totally hiding the
> coordinate systems. I'll put these soon (tomorrow) into the generalizing
> vanishing view peg. E.g.:
> 
>   Vanishing client has:
>    void place(Cell c, java.lang.Object o, float fract, int x0, int y0, int
>             x1, int y1, int depth, float rot)
> 
>   ViewTool would have something like (probably some of the parameters are
>   irrelevant):
>    int place(cs into, Cell c, java.lang.Object o, float fract, int x0,
>              int y0, int x1, int y1, int depth, float rot)
> 
> So, ViewTool won't do the vs.put(), but returns a new coordsys for
> correct placing. I don't know yet how ViewTool's connect should work,
> though, connection needs two coordinate systems.

What would this call actually do? How would it use c and o?

> > >  - We discussed also about the problem, how connection could be drawn
> > >    differently in LollipopCV and BoxCV. Came up that the same problem
> > >    exists also with TDecoder. We ended up with solution, where View
> > >    queries the connection/Tdecoder vob for spesific angle from CV.
> > Angle from CV? I'm not understanding completely...
> > Also, how would you make fillets work here?
> 
> Currently connections are created in View like: new SimpleConnection(1,
> 0.5f, 0, 0.5f); Those parameters are depending the direction of the
> connections. As connection is drawn by put(conn, cs1, cs2), this
> one goes from the right side of first coordsys's box to the left side of
> the second coordsys's box.
> 
> The first proposed solution was to only ask those connection
> mount parameters from the CellView (BoxCellView wants the connection to be
> mounted in the middle of its side, LollipopCellView wants the connection
> to be mounted on its circle's edge). Benja thought that this won't
> work with fillets because fillets should be also drawn differently with
> different CVs (again, the LollipopCellView is an exception, where only its
> circle should fillet).
> 
> So, now its proposed that CellView creates connection vob for wanted
> direction from the given cell and returns it to View.

There are two different ends to a connection and we want different cells
to be able to have different views...

Also, vobs don't need to be created, just returned, usually.

        Tuomas