[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz] The getSqSize problem
From: |
Tuomas Lukka |
Subject: |
[Gzz] 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
- [Gzz] The getSqSize problem,
Tuomas Lukka <=