fenfire-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fenfire-dev] The getSqSize problem


From: Tuomas Lukka
Subject: [Fenfire-dev] The getSqSize problem
Date: Sat, 16 Aug 2003 12:49:56 +0300
User-agent: Mutt/1.5.4i

Just figured out why buoys are not rendered properly if their
anchors are outside the main view when the vobscene is created.

The problem is that getSqSize() is used for the buoy coordinate system
in e.g. NodeType2D, and when the coordinate system is culled (i.e. not
rendered because it is outside the main viewport) when that
method is called, -- splam: the buoy's width and height are zero.

We need to figure out what to do about this.

The problem is that we didn't want to pass around coordinate systems
and width and height so we made the SqSize mechanism to store a default
"box size" for the coordinate system.

So, there are several ways to proceed:

1) kludge it so that the getSqSize() method returns a size even when
   the coordsys would have been culled.

   This would be a relatively easy solution, requiring changes only
   in the Libvob GL implementation. **However**, this is an EXTREMELY
   unclean change: what if the coordinate system determines the sqsize
   at run time? 

2) explicitly say that the box size obtained from getSqSize() should **NOT**
   be used in view generation, and either pass w and h around or require
   the views to be smart inside the vobscene.

   This requires changes to the buoys.

   I prefer this: it's along the lines of other things. We don't get
   coordinates from the vobscene to put things on, rather we hang
   other coordinate systems on the existing ones to enable fast,
   consistent animation.

What do you think?

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]