eXtensible World File
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: Code:
struct Atom { 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. |
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) |
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: Code:
struct Vertex { 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: Code:
struct Poly { 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. |
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: Code:
struct OctP { 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? |
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) |
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? |
Quote:
|
Quote:
|
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? |
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 :) |
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?
|
Quote:
|
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.
|
Quote:
Simply use the function htonl() (or its Delphi equivalent) to convert to/from network order. |
Code:
struct Vertex { |
All times are GMT -4. The time now is 03:43 PM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.