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

Matze Braun matze at braunis.de
Wed Jul 2 19:47:51 PDT 2003


Hi,

Seems I missed introducing myself :) I'm involved in the Crystal Space 
engine and was hacking alot at the 3ds2cs converter and now I'm actively 
working on the blend2cs converter. So I was happy to hear plans about an 
open "standard" exchange format :-)

On Wed, 2 Jul 2003, Ton Roosendaal wrote:

> Hi all,
> 
> ...
> Then on the exchange format topic itself;
> 
> - At the web page about this format (and in the threads after july 1  
> here), I miss an analysis of the problem definition. Typically  
> something you do before pinning down the functional specification,  
> which seems to be the discussion topic already. Maybe I've missed it,  
> but it's very interesting to know. Have existing formats been rejected,  
> like X3d or so? The mentioned objective: "to define a free, extensible  
> 3D model format standard... etc" is general, but the rest of the page  
> mostly mentions game engines as being the focus.
> 
> - I have an Amiga background (sweet 80ies!) and quite familiar with  
> IFF. The binary .blend format has been derived from it, but extended  
> with a header with information about the actual data that's in the  
> chunk. Each header has an pointer to a designated 'structure DNA'  
> chunk, describing the types & names of the chunk contents. This enables  
> quick reading/writing, plus keeps internal structure changes  
> forward/backward compatible, as would an ascii format do.
> Don't know if this method should get a following, it was nasty to code!  
> But we've been using it in Blender since '95 with good (user)  
> satisfaction. In theory it's possible to make a 1:1 lossless conversion  
> of XML<->binary with such a system.
Yes, we've got such a binary xml system like that working in CS, but the 
interesting result: Nearly noone is using it. Seems xml is fast enough 
for most games.

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

Greetings,
	Matze


More information about the Protocols mailing list