On 2/2/07, Sebastian Hoffmann <[EMAIL PROTECTED]> wrote:
On Fri, Feb 02, 2007 at 04:06:08PM +0900, chris wrote:
> for time, with the python-ode example, i did not see much diversion
> until about 8000.
Thank you, at which stepsize?
atached are two of the programs - the second having time=8000.
On Fri, Feb 02, 2007 at 04:06:08PM +0900, chris wrote:
> for time, with the python-ode example, i did not see much diversion
> until about 8000.
Thank you, at which stepsize?
> to me, the scary thing is that people tend to assume
When people start to assume, bad things always start to happen. :)
On 2/2/07, Sebastian Hoffmann <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 01, 2007 at 10:15:19PM -0800, Ken Taylor wrote:
> > > yeah - but my tests of the position sensitivity are quite scary for
> > > anything u want
> > > to be accurate or repeatable and for mission critical stuff.
> >
> > But would
On Thu, Feb 01, 2007 at 10:15:19PM -0800, Ken Taylor wrote:
> > yeah - but my tests of the position sensitivity are quite scary for
> > anything u want
> > to be accurate or repeatable and for mission critical stuff.
>
> But would this kind of experiment be reproducable in the real world, even
> w
On 2/2/07, Ken Taylor <[EMAIL PROTECTED]> wrote:
chris wrote:
> Thought problem 2: physics 2
>
> Suppose I am going to do a rigid body simulation. I put one box (box1)
> on a plane, at the origin and hold another box (box2) suspended a
> meter above the plane nearby. I release box2 at time t=20 a
I've used Celestia before, and from what I can tell... Much like
"Microsoft Flight Simulator", there are models for different ports (in
this case, spaceports rather than airports). When you are near the
ports, the level of detail for those ports are increased. When you are
further from them, howeve
On 2/2/07, Ken Taylor <[EMAIL PROTECTED]> wrote:
>
> chris wrote:
> > On 2/2/07, Peter Amstutz <[EMAIL PROTECTED]> wrote:
> > > Well, I assume this is a trick question. Obviously it *should* do the
> > > same thing, but because of tiny changes in floating point precision,
> > > that isn't guarante
On 2/2/07, Ken Taylor <[EMAIL PROTECTED]> wrote:
> Reed Hedges wrote:
> > One thing that I'd like to have at some point is a way to "enter"
> > another object/space; e.g. when flying around the solar system it's
> > really a "scale model" of sorts, until you decide to descend to the
> > surface of
I wrote:
> chris wrote:
> > Question: will the two images of the two experiments show box2 in the
> > same rest position relative to box1?
> >
>
> Well first I was going to say "of course not."
I mean I was going to say "of course."
I'm tired.
-Ken
_
chris wrote:
> Thought problem 2: physics 2
>
> Suppose I am going to do a rigid body simulation. I put one box (box1)
> on a plane, at the origin and hold another box (box2) suspended a
> meter above the plane nearby. I release box2 at time t=20 and it
> bounces, perhaps collides with box1 then ev
chris wrote:
> On 2/2/07, Peter Amstutz <[EMAIL PROTECTED]> wrote:
> > Well, I assume this is a trick question. Obviously it *should* do the
> > same thing, but because of tiny changes in floating point precision,
> > that isn't guaranteed, and the further you go the less likely it is to
> > prod
Reed Hedges wrote:
> One thing that I'd like to have at some point is a way to "enter"
> another object/space; e.g. when flying around the solar system it's
> really a "scale model" of sorts, until you decide to descend to the
> surface of a planet. I guess the planet is basically a hyperlink to
Thought problem 2: physics 2
Suppose I am going to do a rigid body simulation. I put one box (box1)
on a plane, at the origin and hold another box (box2) suspended a
meter above the plane nearby. I release box2 at time t=20 and it
bounces, perhaps collides with box1 then eventually comes to rest.
On Thu, Feb 01, 2007 at 01:50:07PM +0100, Karsten Otto wrote:
> I finally got around to write some comments on the requirements
> document. I reversed the numbering, since the last bit is the most
> controversial.
>
> 1.4.3. Authoring
>
> "There shall be a bidirectional mapping between X3D an
These are all really great ideas -- there's too much here to reply in
detail (I'd be up all night) but rest assured that I'll be incorporating
a lot of this into the requirements document. I'll post the new version
with everyone's suggestions in a few days.
On Wed, Jan 31, 2007 at 11:18:03PM -
On 2/2/07, Peter Amstutz <[EMAIL PROTECTED]> wrote:
> That's very interesting. Which simulation engine is this?
ode - used in python-ode code. I can provide code and install
instructions if u like.
>
> Also, to reiterate my previous email, would fixed-point math improve the
> situation any?
>
se
On 2/2/07, Peter Amstutz <[EMAIL PROTECTED]> wrote:
> 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 practic
That's very interesting. Which simulation engine is this?
Also, to reiterate my previous email, would fixed-point math improve the
situation any?
I suppose one thing to keep in mind is rigid body simulation for the
purposes of games just needs to be "good enough" and look reasonable.
Practic
On 2/2/07, Peter Amstutz <[EMAIL PROTECTED]> wrote:
Well, I assume this is a trick question. Obviously it *should* do the
same thing, but because of tiny changes in floating point precision,
that isn't guaranteed, and the further you go the less likely it is to
produce the same results. Do I ge
On Wed, Jan 31, 2007 at 11:29:37AM +0100, Karsten Otto wrote:
> The problem here is the clash of two different mindsets, computer
> graphics people versus knowledge engineering people. The first prefer
> scene graphs, which are well understood as Braden pointed out, and
> are good for renderi
Well, I assume this is a trick question. Obviously it *should* do the
same thing, but because of tiny changes in floating point precision,
that isn't guaranteed, and the further you go the less likely it is to
produce the same results. Do I get a cookie?
On Fri, Feb 02, 2007 at 09:26:43AM +09
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
human-scale
This is in response to Reed's question in earlier thread.
Thought problem 1: physics
Suppose I am going to do a rigid body simulation. I put one box (box1)
on a plane, at the origin and hold another box (box2) suspended a
meter above the plane nearby. I release box2 at time t=20 and it
bounces, p
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
On 2/2/07, S Mattison <[EMAIL PROTECTED]> wrote:
> You mean those penguins are actually three millimeters tall? Omg,
> MicroPenguins!
but they're fierce little buggers! You should see how they treat the notrons :).
I always talk in meters for ease of conceptualisation but really I
just mean numb
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,
>
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 and LOD and a slightly different simulation
> pipeli
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 coordi
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 different
Peter Amstutz wrote:
> 1.5. 3D Graphics Requirements
>
> 1.5.1. Meshes and Effects
>
How about vertical "terrain" described by a bitmap. (I.e. heightmap/DEM).
Reed
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/m
On 2/1/07, S Mattison <[EMAIL PROTECTED]> wrote:
> 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 C
I finally got around to write some comments on the requirements
document. I reversed the numbering, since the last bit is the most
controversial.
1.4.3. Authoring
"There shall be a bidirectional mapping between X3D and Interreality
3D capabilities and semantics."
I assume this include Coll
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 to
33 matches
Mail list logo
