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 [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
