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

[Aglanor]

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.

> 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).

	Regards,

	Aglanor