On Tue, May 15, 2007 at 11:24:07PM -0700, Ken Taylor wrote:
> The point is I've noticed that in 0.23 the blacksun pyramid seems a lot ...
> smaller than in 0.24. Or maybe the penguins are bigger. Also, if I have 0.23
> and 0.24 clients connected to the same server, the 0.23 guys look like
> they're floating above the ground to the 0.24 guys while the 0.24 guys look
> like they're half way in the ground to the 0.23 guys.
>
> Obviously some scaling and origin placement has been tweaked between
> versions. I just wanted to make sure this was intentional :) -- and also
> suggest that re-scaling 3d data should be added as a cleanup task before
> releasing 0.24. (Speaking of which, is a goal/to-do/priority list for 0.24
> coalescing anywhere?)
Yes, I changed the penguin sizes in 0.24. I did the math and realized
they were about 40cm tall, and were intended to be a bit bigger than
that.
The bigger problem was I was doing something dumb in 0.23, which was the
code that loads the md2 models for avatars recenters it to make the
origin the center of the avatar bounding box rather than at the avatar's
feet. That's why the 0.24 guys appear to be halfway in the floor when
viewed using 0.23. Also, the avatars feet not touching the floor has to
do with the collision bounding volume not matching up with the avatar
(which is something else I was fiddling with).
Since most of the work has gone into the network layer, a lot of stuff
in the 3D layer was a quick proof of concept rather than being really
well thought out. Even if s4 -> s5 transition wasn't necessary, an A3DL
redesign was already on the plan.
> Also it made me think about standardization. Obviously, VOS/Interreality3D
> will eventually have to have a golden standard for networking and data
> encoding. But also obviously, there will be lots of tweaking until a good
> standard is found (given VOS's code-evaluate-recode development approach).
Speaking of the code-evaluate-recode cycle, I want to mention here that
that come July, I intend to go part time on my current job and spend the
rest of my time on VOS, which should work around to around 20
hours/week. Although it's not full time, I expect this to make a huge
difference in the pace of development, especially since the majority of
design work has already been done, so most of the work is will be just
sitting down and coding.
> Until that standard is finalized, everyone will have to make sure they're
> using the same version of clients, servers, and data sets, to ensure
> consistency. But at some point, perhaps VOS/Interreality 1.0, a standard
> needs to be set in stone, with a guarantee that objects will be interpreted
> in consistent ways, that newer versions will be backwards-compatible, and
> older versions will fail gracefully if presented with newer data. A standard
> that's unambiguous enough that a person who's never seen the VOS codebase
> could write their own client and server from the standard itself, and also
> guarantee that compatibility.
Well, that's a pretty tall order, and codifying standards is premature
until we've settled on something that works. However, what is important
at this point is to plan for backwards compatability, which is something
I mentioned in an earlier email. In s5, I want to lay out a set of
rules by which certain object fields and message signatures can be
automatically casted, sliced or extended to allow structured data not
conforming exactly to expected format to be converted.
I think VOS should be able to offer very good compatability and
consistency by providing the developer with guidance on what kinds of
interface changes affect backwards compatability, and giving some
flexibility so that not every teeny tiny little change requires an
incompatible upgrade (which is the situation with most protocols in
general, but virtual world systems in particular, such as Second Life
having to frequently distribute client patches and reboot their grid).
So rest assured, it's something we're thinking about, and have been
thinking about for a long time -- making it general purpose and doing it
right is one of the reasons VOS development has taken so long.
--
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d