Re: [vos-d] Scaling and Origins -- 0.23 vs 0.24
On Wed, May 16, 2007 at 12:10:21PM -0400, Reed Hedges wrote: > On Wed, May 16, 2007 at 10:18:34AM -0400, Peter Amstutz wrote: > > 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. > > So now it uses the bottom extent of the md2 model as the origin for the > vobject's polygons? Shouldn't it use the same origin as in the md2 > model, and if the origin is wrong there you just have to fix the model? > (Or I guess we could have a flag in a3dl:model that decides this, since > it's possible that people won't want to have to go back and change the > source models, especially if you have a nontrivial workflow involving > several artists and programmers). Unfortunately, "just fix the model" is often much harder than it sounds in the real world. For example, a lot of 3D models in the wild are exported from 3D modelers rather than being in the native modeler format, so you lose useful editing data, or maybe you have the original model file but don't have the right version of the modeling program that was used to make the original model. 3D file format compatability is such a big problem that this can even happen in organizations that might want to reuse content made for an earlier project. In this case fiddling with the model in code was due in part because I already needed to rotate the md2 model by 90 degrees so that it faced forward (this to get around a bug in the underlying md2 loader in Crystal Space). For the s5 redesign, I would prefer to avoid the current a3dl:object3D.model approach entirely, which was just an expedient hack to be able to leverage the Crystal Space modeling loading at the cost of the model data being opaque to A3DL. Instead we should write filters that convert to/from a unified A3DL format. Normalization should happen in the import step, rather than in the client. -- [ 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
Re: [vos-d] Scaling and Origins -- 0.23 vs 0.24
On Wed, May 16, 2007 at 10:18:34AM -0400, Peter Amstutz wrote: > 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. So now it uses the bottom extent of the md2 model as the origin for the vobject's polygons? Shouldn't it use the same origin as in the md2 model, and if the origin is wrong there you just have to fix the model? (Or I guess we could have a flag in a3dl:model that decides this, since it's possible that people won't want to have to go back and change the source models, especially if you have a nontrivial workflow involving several artists and programmers). Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Scaling and Origins -- 0.23 vs 0.24
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
[vos-d] Scaling and Origins -- 0.23 vs 0.24
Was fooling around with 0.23 again to test whether some strange behavior I was seeing was my fault or not (it wasn't -- basically, if objects move around while my client is in the "download" phase, but stop moving before it's complete, the client might get an out-of-date position update on them and not get any update for their most recent position until they move again. Same goes for orientation, etc) -- but that's not the point of this email. 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?) 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). 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. But VOS 1.0 is probably quite a ways off :) -Ken ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
