About x3d Was: [WF-Protocols] A few remarks from the Blender frontier

[Matze Braun]

On Wed, 2 Jul 2003, Aglanor wrote:

> Hi again,
> 
> On Wed, 2003-07-02 at 18:47, Matze Braun wrote:
> > > - My suggestion for you would be to adopt XML for the format, and try  
> > > to be as close as possible to X3d... although I haven't evaluated X3d  
> > > myself, the web3d consortium seems to have learned from the VRML  
> > > failure.
> > I just did a quick look at x3d. I must admit I didn't hear of it before.
> > All in all I don't think it matches our needs really well...
> 
> 	I hadn't heard about it until today too, I'm still reading on it, but
> seems a possibility to consider. Besides, if blender XML is going to be
> compatible with X3D, seems we'd have something to gain with this
> approach.
blender xml is not! based on X3D, it's still the same structure as in 
normal blender files, just encoded as xml.

> 
> > I'd really like to support some standards here, but with x3d I already 
> > found several problems when only doing a quick look at it:
> > 
> > -The format supports alot of stuff we'll never use. While this is not a 
> >  problem by default (we can define a subset for us). Users will still 
> >  wonder why their x3d files won't be accepted by our converters.
> >  I'm quiet sure we'll never support stuff like defining 2d paths and 
> >  extruding them to 3d objects...
> 
> 	Well, as I only know X3D from today I might be horribly wrong, but I
> think this is what "Profiles" are for. From X3D FAQ
> (http://www.web3d.org/fs_faq.htm):
> 
> ************************
> What are X3D Versions and Profiles?
> 
> For X3D to truly be an industry-wide standard, the designers realized
> that different companies don't need or want to support every feature
> that X3D has to offer. For example, if a company wants to make a small,
> efficient 3D animation engine, it might not be interested in supporting
> features for geology rendering. Because of this, groups of features are
> encapsulated in what are called "profiles". A profile may be specific
> for one particular area of functionality (i.e. a "Geo" profile for
> handling geographic data), or can be more general covering several
> different areas of functionality (i.e. a "Full" profile which handles
> all VRML97 nodes). A profile can even contain the functionality of
> several profiles (i.e. the "Full" profile includes the functionality of
> the smaller geometry-based "Core" profile).
> 
> Once a group of profiles is deemed important for inclusion across many
> applications, a new version of X3D can be created which includes by
> default a set of profiles. A new Version implies more functionality than
> a lower Version number.
> 
> Companies can create X3D browsers, tools, importers, and exporters which
> support different Versions and Profiles. For example, a small player
> might be X3D-1 compatible. A full VRML97-compliant browser would be
> X3D-2 compatible. X3D-3 might include extra areas of functionality
> including NURBS, streaming, etc.
> 
> **************************************
> 
> 	Based on the above, couldn't we create a "Profile" for a model format
> to be used on rendering engines and animation libraries?
> 
> 
> > -On the other side I found things lacking which would make alot of sense 
> >  for game engines:
> >    -There's no notion of texture shaders
> >    -The IndexedFaceSet (=mesh) is not optimal since polygons don't need to 
> >     be convex (just non-self-intersecting), there's no default normal 
> >     calculated by the order of the vertices (it seems like they're always 
> >     double sided?), there only 1 texture allowed per meshobject.
> > 
> > It would of course be possible to try being close to this format. But I 
> > don't think that's a good idea for us. The format seems to be too general 
> > most of the time, while lacking core functionality and flexibility when it 
> > comes to game engines.
> 
> 	Haven't dived in the technical aspects of it yet, but if X3D lacks some
> core features that we really need, we could extend it and then propose
> the extension to be included in the standard. I haven't the slightest
> idea whether such a thing (convince the w3c to include something) is a
> reasonable expectation or if there is no way in hell that they'll listen
> to us, so I can't give a fully formed opinion on that.
> 
> 	All of this only matters if we'll be seeking compliance with X3D, of
> course. We can go any way we want. I'm all for defining first the data
> requirements and then talk about how can we serialize it (though it
> seems that the vast majority of the participants prefer an XML-based
> serialization).
Still x3d seems like a very bloated format to me... Also it's not really 
designed for 3d-game engine. We should rather try to produce a format 
which concentrates on the core IMO. Also because importers and exporters 
will be easier to code when the format is simpler.

Greetings,
	Matze