On 2/13/07, Reed Hedges [EMAIL PROTECTED] wrote:
chris wrote:
...there's a global coordinate system, and a local rendering coordinate
system...
So the main thing that you need to do, I guess, is represent your global
coordinate system not with IEEE floating point numbers (doubles have the
On 2/11/07, Ken Taylor [EMAIL PROTECTED] wrote:
if your physics - say bouncing boxes like my example - is performed in
it's own local coordinate space then it could be made consistent every
time - but I can't see how you would combine the rendering of this in
realtime with the rendering
Hello, just some thoughts from a lurker. :-)
What if high level objects and the camera have an extra coarse origin that
is snapped to a grid whose grid distance is a large power of 2, so the
values are exactly representable in floating point variables in the same
scale. Then fine origins are
On 2/10/07, Peter Amstutz [EMAIL PROTECTED] wrote:
On Wed, Feb 07, 2007 at 08:57:18AM +0900, chris wrote:
That is not to say this model cannot work as a hybrid system with
portals at doorways, for space jumps etc. In fact, for very large
scale solar/galaxy systems you would have to either
On 2/10/07, Karsten Otto [EMAIL PROTECTED] wrote:
I am not quite sure what kind of precision is necessary here... I'd
expect that it should be enough to center the current sector for
displaying purposes, and re-center to the new sector once you cross a
portal boundary. Considering relatively
On 2/10/07, Peter Amstutz [EMAIL PROTECTED] wrote:
On Fri, Feb 09, 2007 at 04:56:39PM +0100, Karsten Otto wrote:
I am not quite sure what kind of precision is necessary here... I'd
expect that it should be enough to center the current sector for
displaying purposes, and re-center to the new
if your physics - say bouncing boxes like my example - is performed in
it's own local coordinate space then it could be made consistent every
time - but I can't see how you would combine the rendering of this in
realtime with the rendering of the scene
I don't see why transforming from
On Wed, Feb 07, 2007 at 08:57:18AM +0900, chris wrote:
That is not to say this model cannot work as a hybrid system with
portals at doorways, for space jumps etc. In fact, for very large
scale solar/galaxy systems you would have to either use very high
precision in the object system or maybe
I am not quite sure what kind of precision is necessary here... I'd
expect that it should be enough to center the current sector for
displaying purposes, and re-center to the new sector once you cross a
portal boundary. Considering relatively small sectors, I'd imagine an
error factor of a
On Fri, Feb 09, 2007 at 04:56:39PM +0100, Karsten Otto wrote:
I am not quite sure what kind of precision is necessary here... I'd
expect that it should be enough to center the current sector for
displaying purposes, and re-center to the new sector once you cross a
portal boundary.
On Fri, Feb 02, 2007 at 12:15:47PM +0900, chris wrote:
Yes - that's why we use a single continuous world space. Many systems
like VGIS divide the earth into fixed sized sectors. This sort of
segmentation creates many overheads.
The Dungeon Siege game segmented its world into SiegeNodes, each
When I speak of a single continuous world space I am referring only to
the subset of the application that is being used in the display
system: the part of the app that includes the grahics pipeline. This
is where we are forced to used single precision because of hardware
limits and performance and
First off, I'd say the limit is really the coordinate system you use.
Assuming you have a 4-byte integer value measuring meters, then you
already can go roughly 2.000.000.000 meters in any direction, which
well exceeds terrestial distances, but isn't quite enough to take you
from the Sun
Karsten and Chris are both right and have insightful comments.
There's no real computational or memory restriction on the size of a
volume of space *as a volume of space* Chris is talking about the
representation of coordinates.
[[I.e. the only reason that a 1x1x1 kilometer space is
On 2/2/07, Reed Hedges [EMAIL PROTECTED] wrote:
Karsten and Chris are both right and have insightful comments.
thx Reed :)
There's no real computational or memory restriction on the size of a
volume of space *as a volume of space* Chris is talking about the
representation of coordinates.
You mean those penguins are actually three millimeters tall? Omg, MicroPenguins!
[Notice that we never specify what the units in VOS are. We can call
them notrons in honor of an original collaborator in the project :)
As a de-facto convention they would probably be meters in most worlds,
and
On 2/2/07, Reed Hedges [EMAIL PROTECTED] wrote:
chis wrote:
The best combo of techniques from research IMHO is what I call
origin-centric techniques that build on the concept of a continuous
floating origin (in the client side display system), includes special
management of clip planes
What are your thoughts about fixed-point numbers? If have, say, a 16.16
fixed-point number and the units are meters, you get a maximum range of
65 kilometers with a resolution of about 15 micrometers (Reed mentioned
notrons but in practice meters are the most useful for any kind of
This might seem a haphazard or poorly thought out question, but it has
been long begged by science fiction, and I'm very intrigued to hear
answers from people who might know how it would be possible...
Forget everything you know about the COD format.
Say, I have a small online world, which looks
19 matches
Mail list logo
