eXtensible World File

[daeken_bb]

This thread will chronicle the creation of the XWF (eXtensible World File -- good name?) file format.

I believe we've pretty much agreed that the proper way to do this is an atomic structure where every atom either contains data directly or is a container for other atoms, or both. So, the first thing that needs to be decided is the structure of the atom header.

I propose the following:

struct Atom {
char type[4];
unsigned long children;
unsigned long size;
};


Where `type' is a FourCC (4 character code) representing the type of atom it is, e.g. vertex data, texture, placeable object, etc. `children' is the number of child atoms the current atom contains. `size' is the size in bytes of pure data that follows.
This would then be followed by `size' bytes of pure data and then `children' number of atoms.

I also propose we store all strings in this format: a 2-byte unsigned integer in network order followed by that number of bytes.

Now we need to figure out the FourCCs we will need for the initial version.

Please post your input here.

Happy Hacking,
Lord Daeken M. BlackBlade
(Cody W. Brocious)

Edit #1: Changed children to long from char as per WC's suggestion.
Edit #2: Changed longs to unsigned longs.

[Windcatcher]

I think children should be a long instead of a char. It eliminates the possibility of running out of headroom and modern PC's like grabbing entire long's at a time anyway. Lately I've been a fan of using 32-bit fields (longs and floats) by default unless there is a reason not to.

Edit #1: Well, some of the things we definitely need:
- texture
- vertex
- color (RGBA only?) (mapped to vertex)
- triangle
- texture coordinate (mapped to vertex)
- model
- bounding box (corner points)
- bounding sphere (center and radius, or maybe just radius if the center is implied)

[daeken_bb]

Ok, changed that :)

Now we need to figure out what FourCCs we need. We should use a standard naming convention... all lower case would be simplest. Also, when listing them, replace spaces with dashes ('-') but don't use that in the files themselves.

First we'll need textures. I propose that we have a FourCC called 'tex-' which stores the properties and filenames of a given texture. My current thought is that we simply have an unsigned long indicating the texture ID, then properties/filenames in the format 'string name, string value' for however many entries there are. This will keep some degree of simplicity.

Now the other three main things are vertices, polygons, and octree data.

Vertices, I think, should be stored in an atom with the FourCC 'vert'. The format should simply be an unsigned long indicating its vertex group id, then an unsigned long indicating the number of vertices, then an array of the following structs:


struct Vertex {
double x, y, z; // Position
double i, j, k; // Normal
double u, v; // Texture coords
};


The vertex group ID allows multiple 'vert' atoms in the same file to be addressed seperately.

Polygons should be in an atom with the FourCC 'poly'. To allow for addressing of vertex groups, the 'poly' atom should start with an unsigned long indicating the vertex group it will be dealing with, then an unsigned long indicating the number of polygons, followed by an array of the following structs:


struct Poly {
unsigned long v1, v2, v3; // Vertex indices in the indicated vertex group
unsigned long tex; // Texture id.
unsigned long flags; // If bit 1 is set, it can be walked through, if bit 2 is set, it is transparent.
};


Any input?

Edit #1: Added flags field to Poly
Edit #2: Added i, j, and k fields to vertices.
Edit #3: Switched the order of texcoords and normals.

[daeken_bb]

Moving on, we should have two different ways of creating meshes. A 'wld-' atom and an 'obj-' atom.

An 'obj-' atom should have the following things:

* A string in its data field containing its name
* A bunch of 'tex-' atoms describing all of the materials used in the object
* A 'vert' atom containing all of the vertices for the object
* A 'poly' atom containing all of the polygons for the object


A 'wld-' atom should contain the following:
* 'tex-' atoms containing material information
* A 'vert' atom containing all the vertices for the zone
* An 'octp' atom containing the octree for the zone

An octree should consist of two types of atoms, 'octp' and 'octe'. 'octp' would be an octree node with children, where an 'octe' atom would be an octree end node.

An 'octp' atom should contain the following in its data field:


struct OctP {
double cen[3];
double size[3];
};


Where cen is the center of the octree node cube, and size is the distance from the center to the extreme x, y, and z... in other words, half of the total length, width, and depth of the cube. It should have 8 children atoms, all of which being with 'octp' or 'octe' atoms.


And 'octe' atom should have the same data field as an 'octp' atom. The difference is that an 'octe' atom has a 'poly' atom as its only child. This poly atom contains all of the polygons wihin this octree end node.

That should almost do it for an initial file format... anything I'm missing?

[Windcatcher]

Any proposition for vertex color/shading (resists going into a tirade on EQ's use of emissive coloring).

Also, we need to tag certain polys as "solid" or "non-solid". For instance, the player can walk through the leaves of a tree.

Alpha transparency. Part of color?

As a side note, Quake files have shaders as separate and you assign them to vertices...

Edit #1: for frustum culling, you'll need bounding spheres in addition to bounding boxes (sphere culling should be the first step as it's way faster)

[jbb]

One question -
what is the advantage of using "atoms"?
It seems to make it hard to get to the data you want without reading the whole file?

Why not store named "files" in a zip file format?

[daeken_bb]

Any proposition for vertex color/shading (resists going into a tirade on EQ's use of emissive coloring).

Also, we need to tag certain polys as "solid" or "non-solid". For instance, the player can walk through the leaves of a tree.

Alpha transparency. Part of color?

As a side note, Quake files have shaders as separate and you assign them to vertices...

How would you suggest the vertex color/shading be done? Likewise, how would you suggest the shaders be done? I'm not quite sure how it should be done :)

[daeken_bb]

One question -
what is the advantage of using "atoms"?
It seems to make it hard to get to the data you want without reading the whole file?

Why not store named "files" in a zip file format?

The primary advantage of atoms is you have a completely open-ended file format. You can change it majorly without breaking compatibility. It's also _very_ easy to read and write.

[Windcatcher]

Well, in OpenGL, we have ambient, diffuse, and emissive shading, and maybe some others, where most take an rgba value (emissive ignores the alpha component -- so to do transparency you have to set the ambient alpha value). I guess you could define a shader that says which ones to use and the values, and then the vertex group would have a shader list atom that had n shader atoms (1 per vertex). We should probably think it through before diving into it. What you have is probably fine as a first cut. The format is extensible, as you say.

Transparency is part of ambient alpha shading, though, so it will be an issue as soon as we have zone bounding polys (that keep you from walking off the world). Also, being able to tag polys as solid or not is a must, but maybe that should go into another atom?

[daeken_bb]

Ok, so do you think that the file format described above is good enough for an initial version? If so, I'll start work immediatly on getting it in place in OpenEQ so we can start using it and testing stuff :)

It shouldn't take long for you to make OZ work with it, nor should it take me long to get OpenEQ to work with it, I don't think :)

[Windcatcher]

Let's try it and see what we get. I already have OZ open and I've been working on it. I just changed ambient light to time-of-day and put in code to better simulate sky color, ambient light, and it even shows stars that wheel in the sky (one of the features I added to the engine was a star field). The bird's-eye view is still broken but everything else works...I can either try and fix that while you make a viewer or I can forget it for now and start on the exporter...what do you think?

[daeken_bb]

Let's try it and see what we get. I already have OZ open and I'v been working on it. The bird's- eye view is still broken but everything else works...I can either try and fix that while you make a viewer or I can forget it for now and start on the exporter...what do you think?

The sooner the exporter works, the sooner we have a viewer available to test stuff with hehe

[Windcatcher]

Okay, I'll get on it. One question: you mentioned bytes in network order. Is that big-endian? I think there's a standard Windows API call that will put them in network order for me, but I'm not sure.

[daeken_bb]

Okay, I'll get on it. One question: you mentioned bytes in network order. Is that big-endian? I think there's a standard Windows API call that will put them in network order for me, but I'm not sure.

Yea, I'd like to have everything in network order (big-endian) as it'll help with cross-architecture compatibility.

Simply use the function htonl() (or its Delphi equivalent) to convert to/from network order.

[jbb]

struct Vertex {
double x, y, z; // Position
double u, v; // Texture coords
};


You might want to add vertex normals to that.

[daeken_bb]

Edit #1: for frustum culling, you'll need bounding spheres in addition to bounding boxes (sphere culling should be the first step as it's way faster)

What I do is just take the longest side of the bounding box and treat that as the radius.

[Windcatcher]

The bit 2 in the polygon struct should be taken as temporary...at some point we'll need a full-blown alpha setting to handle semitransparency (e.g. windows), but this will do for now.

[daeken_bb]

struct Vertex {
double x, y, z; // Position
double u, v; // Texture coords
};


You might want to add vertex normals to that.

Done, thanks :)

[daeken_bb]

The bit 2 in the polygon struct should be taken as temporary...at some point we'll need a full-blown alpha setting to handle semitransparency (e.g. windows), but this will do for now.

Shouldn't that stuff be done in textures, though?

[Windcatcher]

I don't know...we should probably talk about it. That's the way it's done in WLD, but I'm not sure it's the best way. Is it better to tie alpha to polygons or textures? When rendering, alpha is done at the poly level.

Edit: Here's what I've got so far:

Unit XWFFiles;

Interface

Uses Classes;

Const
fourccTexture = 'tex ';
fourccVertex = 'vert';
fourccPolygon = 'poly';
fourccObject = 'obj ';
fourccOctreeParent = 'octp';
fourccOctreeEndpoint = 'octe';

Type
TFourCC = Packed Array[0..3] Of Char;

TXWFAtomRec = Packed Record
FourCC : TFourCC;
Children : LongWord;
Size : LongWord;
End;

TXWFVertexGroupRec = Packed Record
GroupID : LongWord;
NumVertices : LongWord;
End;

TXWFVertexRec = Packed Record
X,Y,Z : Double; // Position
U,V : Double; // Texture coordinates
I,J,K : Double; // Normal
End;

TXWFPolygonGroupRec = Packed Record
VertexGroupID : LongWord;
NumPolygons : LongWord;
End;

TXWFPolygonRec = Packed Record
V1,V2,V3 : LongWord; // Vertex indices in the indicated vertex group
TextureID : LongWord; // Texture ID
Flags : LongWord; // Bit 1 ... 0 = solid, 1 = can be walked through
// Bit 2 ... 1 = transparent (TEMPORARY UNTIL SHADERS ARE DEFINED)
End;

TXWFOctreeNodeRec = Packed Record
Center : Packed Array[0..2] Of Double;
Size : Packed Array[0..2] Of Double;
End;

// Classes for dealing with atoms

TXWFAtom = Class
Atom : TXWFAtomRec;
Data : Pointer;
Children : TStringList; // Child atoms
Constructor Create(Const AtomRec: TXWFAtomRec);
Destructor Destroy; Override;
Procedure ReadFromStream(Stream: TStream);
Procedure WriteToStream(Stream: TStream);
End;

Implementation

Uses Math,SysUtils;

// ------------------------------
// Utility routines
// ------------------------------

Function StrLPas(P: PChar; MaxLen: Integer): String;
Var
I : Integer;
St : String;

Begin
I := Min(MaxLen,StrLen(P));
St := '';
While Length(St) < I Do St := St + ' ';
Move(P^,St[1],I);
Result := St;
End; // StrLPas

// ------------------------------
// TXWFAtom
// ------------------------------

Constructor TXWFAtom.Create(Const AtomRec: TXWFAtomRec);
Begin
Atom := AtomRec;
Children := TStringList.Create;
If Atom.Size > 0 Then GetMem(Data,Atom.Size) Else Data := Nil;
End; // TXWFAtom.Create

Destructor TXWFAtom.Destroy;
Var I: Integer;
Begin
For I := 0 To Children.Count - 1 Do Children.Objects[I].Free;
Children.Free;
If Data <> Nil Then FreeMem(Data,Atom.Size);
End; // TXWFAtom.Destroy

Procedure TXWFAtom.ReadFromStream(Stream: TStream);
Var
ChildAtom : TXWFAtomRec;
Child : TXWFAtom;

Begin
If Atom.Size > 0 Then Stream.Read(Data^,Atom.Size);
Stream.Read(ChildAtom,SizeOf(ChildAtom));
Child := TXWFAtom.Create(ChildAtom);
Children.AddObject(StrLPas(Atom.FourCC,4),Child);
Child.ReadFromStream(Stream);
End; // TXWFAtom.ReadFromStream

Procedure TXWFAtom.WriteToStream(Stream: TStream);
Var I: Integer;
Begin
If Atom.Size > 0 Then Stream.Write(Data^,Atom.Size);
For I := 0 To Children.Count - 1 Do TXWFAtom(Children.Objects[I]).WriteToStream(Stream );
End; // TXWFAtom.WriteToStream

End.

[daeken_bb]

I don't know...we should probably talk about it. That's the way it's done in WLD, but I'm not sure it's the best way. Is it better to tie alpha to polygons or textures? When rendering, alpha is done at the poly level.

I personally would prefer have it as a texture issue. It'd greatly simplify things from a rendering perspective... I'd assume that it'd simplify texture creation as well.

[Windcatcher]

Well...there's more than one kind of alpha we're dealing with. There's alpha in the texture data, for instance tree leaves have the transparent bits with alpha = 0, and there's also overall polygon alpha (for semitransparency). It's possible to have masked textures with transparent bits that also use polygon alpha. A good example is a texture that represents glass -- most of the texture has the alpha at 0, but those parts that don't should be semitransparent. It can be done either in the texture or in the polygon, but not supporting both means needing a separate texture for every different overall alpha level you want to use in a zone.

[daeken_bb]

Well...there's more than one kind of alpha we're dealing with. There's alpha in the texture data, for instance tree leaves have the transparent bits with alpha = 0, and there's also overall polygon alpha (for semitransparency). It's possible to have masked textures with transparent bits that also use polygon alpha. A good example is a texture that represents glass -- most of the texture has the alpha at 0, but those parts that don't should be semitransparent. It can be done either in the texture or in the polygon, but not supporting both means needing a separate texture for every different overall alpha level you want to use in a zone.

Hm, ok.

Can we put that off until the second revision of the file format? :)

[jbb]

You're going to want alpha in the textures, at least allowing 0% and 100% transparency so you can texture things like leaves on trees that have gaps between them.

Using values inbetween is of course harder as it required you to depth sort the polygons before drawing them to work right.

On the Vertex format - you might want to have location, normal, texture coordinates in that order rather that the one you have now. I know you're using opengl but if it doesn't matter for opengl then you might as well well make it as easy to use for all possible platforms.

As for the main file format, it would seem easier to me to load an index to all the file fragments rather than have to skip through the file looking for what you wanted. That's really what I mentioned zip for, was the index at the end of the file

EDIT: I meant to say the DirectX is slightly easier if the vertex compoents are in that order so why make it harder if it doesn't matter to opengl

[Windcatcher]

One thing I'd like to point out is how the vertex group and polygon group structures all start with two ulongs, group ID and count. Tnis is a good thing because as I implement this I can implement them as one generic container class and use the same code for both (where the constructor takes an extra argument specifying the size in bytes of the individual records they contain).

[Windcatcher]

Should we always insist that the first node in the tree is an octp node (that is, it's divided at least once), or should we allow the initial node to be an octe node if the zone is (very) small? For that matter, is it really necessary to have two types, or can we just have one type and know if it's the end node by the number of children (either 8 or 1)?

[daeken_bb]

Should we always insist that the first node in the tree is an octp node (that is, it's divided at least once), or should we allow the initial node to be an octe node if the zone is (very) small? For that matter, is it really necessary to have two types, or can we just have one type and know if it's the end node by the number of children (either 8 or 1)?

Well, not every file will have an octree at all. Only zones will have the octree, so I think that requiring an octp is a bad idea. I think we should have to have an octp in a wld-, that way we can combine a world, objects, and other things in a single file.

[Windcatcher]

Sorry, that's what I meant. I'm looking at integratnig this with OpenZone, after all. In a wld-, should we demand that the first node of the octree is an octp or can we allow it to be an octe? It relates to the logic when exporting the zone, whether or not to divide it based on the zone size. For instance, right now I do BSP division only if an extent is larger than some threshold. It seems to me that it would be a lot cleaner to just have octp nodes, since the renderer has to process them all anyway...but I'm more familiar with BSP trees so it's hard for me to say.

[daeken_bb]

Sorry, that's what I meant. I'm looking at integratnig this with OpenZone, after all. In a wld-, should we demand that the first node of the octree is an octp or can we allow it to be an octe? It relates to the logic when exporting the zone, whether or not to divide it based on the zone size. For instance, right now I do BSP division only if an extent is larger than some threshold. It seems to me that it would be a lot cleaner to just have octp nodes, since the renderer has to process them all anyway...but I'm more familiar with BSP trees so it's hard for me to say.

Hmm... I think an octr node wouldn't be such a bad idea. Then we just look at the _types_ of the children, not the number. This also allows us to have less than 8 children in an octree node, that way we don't have any empties.

So it's just the Octree header and then either 1 poly node or 2-8 other octr nodes. Simple enough.

[Windcatcher]

Okay, that's how I'll code it then.

[daeken_bb]

Great :)

I'm strugling to remember how to use certain functionality of classes in C++ lol, it's been so long. Luckily most of my existing C structs and such can be merged over no problem.

[daeken_bb]

Well, I just wrote up some docs on the file format. They're available at http://home.archshadow.com/~daeken/xwf.html

I hope they're of use to people :)

[jbb]

A few more comments and questions on your document.
It's looking good but I have some questions...

Alignment - It might be a good idea to require that atoms start on a 4 byte boundary as it's very painful to read longs at non aligned addresses on some architectures and slower even on x86.

Poly structure - I'd suggest having a Material id rather than a Texture id as you need to have more than just a single texture for anything but the simplest case. (Detail textures, Normal Maps, Shader effects, etc...)

Do you really want to require big endian numbers given that probably 90% of people use x86 machines? Guess it doesn't matter all that much.

Is the "octr" atom optional for the "wld-" atom? Or is it required to make an octree? If so will a simple octee with everything in the root node do? (I'm thinking you might not want to rebuild it all the time while testing stuff out)

Can an "obj-" atom not have an octree? I'm thinking that if you have transparent textures in the model you'll need to depth sort to render it and an octree could speed this up potentially.

Is there any reason to have wld and obj atoms being any different?

Is the obj- atom really a model - and you'll somewhere else have something to place multiple instances of this model in the world?

Sorry for all the questions.


Also I see you have specified double. it's more usual to use float types for this kind of thing, is that deliberate?

[daeken_bb]

A few more comments and questions on your document.
It's looking good but I have some questions...

Alignment - It might be a good idea to require that atoms start on a 4 byte boundary as it's very painful to read longs at non aligned addresses on some architectures and slower even on x86.

Poly structure - I'd suggest having a Material id rather than a Texture id as you need to have more than just a single texture for anything but the simplest case. (Detail textures, Normal Maps, Shader effects, etc...)

Do you really want to require big endian numbers given that probably 90% of people use x86 machines? Guess it doesn't matter all that much.

Is the "octr" atom optional for the "wld-" atom? Or is it required to make an octree? If so will a simple octee with everything in the root node do? (I'm thinking you might not want to rebuild it all the time while testing stuff out)

Can an "obj-" atom not have an octree? I'm thinking that if you have transparent textures in the model you'll need to depth sort to render it and an octree could speed this up potentially.

Is there any reason to have wld and obj atoms being any different?

Is the obj- atom really a model - and you'll somewhere else have something to place multiple instances of this model in the world?

Sorry for all the questions.


Also I see you have specified double. it's more usual to use float types for this kind of thing, is that deliberate?

Hrm... thank you for pointing out some really stupid flaws in my logic hehe.

First, I don't think that alignment is that big of a deal, and will just overcomplicate the file format. We're talking about such a slight bit of overhead that it's not even worth considering since it's only at loadtime. Also, the reason I suggest big-endian for everything is that we can simply use htonl/ntohl to do the conversion rather than having to code our own byte-swapping function. Makes it simpler to port to other archs.

The polygon texture ID really is a material ID since it references the tex- atoms which are materials under the guise of normal textures hehe.

Yes, all wld- atoms should have an octree, if only a single end node containing the polygons. And the reason the wld- and obj- atoms are seperate is because the obj- atoms contain a name.

obj- atoms don't have an octree because for such a small polygon count, it's simply not neccesary. It'd just add bloat.

And thank you for pointing out that we need a way to place objects... it completely passed over my head while we were designing it hehe.

So, I'll fix the docs in a sec.

[daeken_bb]

I've updated the docs :)

Should scale be a single factor or should there be a scale for x, y, and z?

[jbb]

I'd say all 3. There is little cost for doing so and some benefit,

One example of why:
You might have an archway as a model because you wanted 20 similar ones at intervals through a corridor but the corridor might be changing height. It would be useful to be able to scale the height of the arch and not the other dimensions to make it fit.

[daeken_bb]

I'd say all 3. There is little cost for doing so and some benefit,

One example of why:
You might have an archway as a model because you wanted 20 similar ones at intervals through a corridor but the corridor might be changing height. It would be useful to be able to scale the height of the arch and not the other dimensions to make it fit.

Good point. Updated :)

[jbb]

Ok, my last comment for tonight

Your probably going to need a atom for zone related information such as the zone name, far clipping plane, sky colour or texture or whatever, fog type & colour.

And also if you want this to be an extensible file format I think you should have some way for each atom to indicate if that atom MUST be understood by the loader. For example you might add a new atom with lighting information. An old loader could still load and show the zone without lighting just by ignoring the atom. Or you might introduce a new and improved 'VER2' vertex information atom. If the loader sees this and doesn't know about it then it can't continue.

I'd suggest making the atom name upper case if the loader is required to understand the contents and lower case if the loader can plausibly render the zone while ignoring the contents. For example the octree information might be lower case because a renderer which doesn't understant that atom type could still render the zone (just more slowly)

[daeken_bb]

Ok, my last comment for tonight

Your probably going to need a atom for zone related information such as the zone name, far clipping plane, sky colour or texture or whatever, fog type & colour.

And also if you want this to be an extensible file format I think you should have some way for each atom to indicate if that atom MUST be understood by the loader. For example you might add a new atom with lighting information. An old loader could still load and show the zone without lighting just by ignoring the atom. Or you might introduce a new and improved 'VER2' vertex information atom. If the loader sees this and doesn't know about it then it can't continue.

I'd suggest making the atom name upper case if the loader is required to understand the contents and lower case if the loader can plausibly render the zone while ignoring the contents. For example the octree information might be lower case because a renderer which doesn't understant that atom type could still render the zone (just more slowly)

Well, I think these are things that can be remedied in the next revision. Right now is really just a rough draft and the file format may change drastically by the next revision, but then it will stay pretty much the same (just atom changed)

[Windcatcher]

We probably want another polygon flag so we can have polygons that don't have textures (like transparent bounding polys). If the flag is set, then the texture id should be ignored and the polygon doesn't have a texture.

[daeken_bb]

We probably want another polygon flag so we can have polygons that don't have textures (like transparent bounding polys). If the flag is set, then the texture id should be ignored and the polygon doesn't have a texture.

If the polygon's flag has its 2nd bit set, then it's fully transparent, otherwise normal alpha is respected.

[Windcatcher]

Well I've managed to export Veldona to veldona.xwf...the file looks okay when I look at it in DOS with a hex-dumper...the file is 14mb in size. Do you have a place where I can upload it so you can try it out?

[daeken_bb]

I'll PM you the details. You'll be able to scp things up, as well as have ssh access to the box.

[daeken_bb]

Well, I wrote a simple loader and tested it against veldona. It seems that you byte-swapped some integers, but not others, or my loader sucks ;)

Would you be able to check over your code to make sure you always put them in network order? I'm going to double-check my code in the morning because I'm far too tired to do it tonight :P

I'm heading off to bed, so I'll talk to everyone tomorrow.

[Windcatcher]

Yup, I found it. I wasn't swapping the children count and the size in the basic atom. I'll re-export it and upload it.

Edit: I re-exported all four of my large outdoor zones and uploaded the .XWF files to your server. Right now they don't separate placeable objects from the rest of the world geometry (and there are a few other things not implemented yet -- like non-solid polys) but hopefully they'll at least load for you.

[daeken_bb]

Hmm... it looks like you're adding about 8 nulls in between the children count and size of the tex- atoms. Either that or it's far too early and I'm reading it wrong :P

[jbb]

I have a couple more questions about your format?
Where is the actual texture data stored?
How can you tell how many atoms there are at the top level? Is the whole thing wrapped up in a single atom?

[Windcatcher]

I think the textures themselves should be in separate files...right now I'm exporting the tex- atoms with the filename after the key "filename".

By the way, all of the textures for my zones are available at:

http://sourceforge.net/project/showfiles.php?group_id=41381&package_id=34673

under "OpenZone Textures 1.4".

Edit: I made a change and re-uploaded the Veldona export (and got rid of the others)...let me know how it works out.

[jbb]

Is there a chance I could get a copy of a converted zone to have a play with?

[Windcatcher]

We really need a public place to host these once they're ready for people to use. I don't have a problem posting them anywhere, if there's a place for them. Of course until daeken_bb gets back to us I don't even know I'm exporting it correctly. In the meantime I'm closing memory holes in OpenZone (I found out that it leaks like a sieve).

[daeken_bb]

Well, just loaded (but not rendered) Veldona... looks good :)

I'll post code when I can.

Btw, you can download veldona from me at http://home.archshadow.com/~daeken/veldona.xwf.bz2
Please mirror it if you can, as that's on my home connection :P

[jbb]

Thanks,
I've grabbed a copy and put it up at
http://eqengine.fx2100.com/veldona.xwf.bz2

[daeken_bb]

Great, thank you :)

Btw, I created a dump of the atoms in veldona.xwf. It's available at http://home.archshadow.com/~daeken/veldona.txt :)

[Windcatcher]

I just uploaded my other three outdoor zones as XWF files...

[jbb]

I noticed that the length field of the wld chunk right at the start doesn't seem to be set.

I'm writing a loader for this to try it out.
For me it would be easier to load (certainly for me, and I suspect for anyone) if instead of having the polygons in the octree there was a simple list of all the polygons and then the octree contained the index number of the polygon instead polygon data itself.

[daeken_bb]

I noticed that the length field of the wld chunk right at the start doesn't seem to be set.

I'm writing a loader for this to try it out.
For me it would be easier to load (certainly for me, and I suspect for anyone) if instead of having the polygons in the octree there was a simple list of all the polygons and then the octree contained the index number of the polygon instead polygon data itself.

Hmm, I was considering this, but it'd take up more ram, and it'd be a bit slower because it'd have to dereference from the polygons each time it has to draw one. I'd personally rather keep it the way it is, but if others share your views, I'm willing to change it :)

[jbb]

Well, I need to create vertex buffers during loading for each material and octree node so one extra indirection during loading isn't going to be a big problem. And in fact it's probably going to be faster to sort the indicies in the octree by material than it is to sort the actual polygons objects.

I realise that in opengl you don't actually need to create vertex buffers, you can just call glvertex for each point, but you're going to want to at some point :)

EDIT: But it probably doesn't matter, it's easy enough to load the polygons into an array if I want them that way.

[jbb]

Is the sample data I've got the double values aren't byte reversed. If you are going to have the ints in big enidan format then presumably the doubles should be too...?

[daeken_bb]

Is the sample data I've got the double values aren't byte reversed. If you are going to have the ints in big enidan format then presumably the doubles should be too...?

I'm not sure, actually. I was under the impression that doubles are the same on x86 and ppc at the least.

[jbb]

I'm 99% sure they will have the bytes in reverse order.

You've got 8 byte doubles in your file format for all the floating point values. Everything else uses 4 bytes floats for this. Are you sure you want 8 byte doubles?

[Windcatcher]

I was wondering why they were doubles instead of floats in the spec...

[KhaN]

Where i can download converter ? I have made some zones i would like to test :p