Ok, I've been sick for the past few days which is why I've been a bit slow to reply to the list.
I think Reed nailed most of the reasons for why a literal translation of X3D isn't necessarily a good idea, but let me add my two cents. The main issue is that X3D by designed around rendering the scene graph, so the data structures tend to reflect that rather than provide a more semantic view of the scene that may be easier for people (and programs) to understand. By constrast, the current A3DL design is almost completely semantic, and the problem we have right now is that it lacks a notion of a viewport (the actual rendering window that is presented to the user). This is important because graphical elements like a heads-up display are best defined in terms of camera space, not world space, and often different viewports will have different state associated with them (such as the current selection.) I also want to take the opportunity to consult other file formats such as Collada, Cal3D (for skeletal modeling) and so forth to try and come up with a graphics model that is a good compromise between them and reflects the needs of current interactive media. On Tue, May 22, 2007 at 09:03:29AM -0700, Ken Taylor wrote: > Ok, well I can totally support deviating from TheWayX3DDoesThings if it's > less efficient than something VOS can support or if it doesn't support > required VOS/Interreality features very well. But I'd recommend keeping it > rendering-engine agnostic as much as possible, and to try to keep the focus > on content and interoperability. Don't let an arbitrary decision get weighed > too heavily by "this would be easier in crystal space," for example, but > rather "this is existing practice" or "this is the most flexible and > interoperable." > > I guess my suggestion really comes down to, when in doubt, follow X3D, > because they're putting a lot of work into making this stuff flexible and > interoperable :) > > For example, for mesh vertex/polygon data, a3dl would ideally natively > support the exact formats that X3D uses, defined directly from their spec. > If additional formats that support more features are necessary, then that's > fine, but I think the support should be in there. And "this is native data > that CS uses internally" really shouldn't be one of the options unless it's > conveniently used *outside* of CS. > > And when you get into stuff like advanced shaders and things like that, > seeing how X3D is attacking the problem would probably be a very good > starting point. (And again, using "the shader structure of CS" would > probably be a less-than-ideal starting point if it's not a common way to go > about it). > > As for ease of use, you want to support editing in-world, but I wouldn't > have a problem letting the client do most of the work translating the easy > editing interface to actual a3dl representation. You don't want to restrain > what advanced things people using external editing tools or importing data > from other formats can do just to allow a simple programmer interface for > dynamically generated data. Some people will want to be able to make lush, > interesting worlds with lots of advanced content, and others will want to > make things quickly and in real-time with primitives, and VOS should be able > to make both groups happy. (Ideally, those who want to make lush, complex > worlds with advanced content in real-time should be happy too!) However, I > do agree that allowing anything to dynamically change should be a major goal > of VOS, and if something in X3D artificially stands in the way of that, > that's a good reason to look for a different design. > > I may just be re-iterating a lot of stuff you already are thinking, but I > just wanted to get these thoughts down. > > -Ken -- [ 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
