eXtensible World File - Page 3

daeken_bb · #1 10-03-2004, 08:56 AM

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 · #2 10-03-2004, 09:46 AM

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 · #3 10-03-2004, 10:09 AM

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 · #4 10-03-2004, 10:19 AM

Quote:

Originally Posted by 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?

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 · #5 10-03-2004, 10:26 AM

I've updated the docs

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

jbb · #6 10-03-2004, 10:40 AM

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 · #7 10-03-2004, 10:42 AM

Quote:

Originally Posted by 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.

Good point. Updated

jbb · #8 10-03-2004, 10:52 AM

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 · #9 10-03-2004, 10:55 AM

Quote:

Originally Posted by 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)

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 · #10 10-03-2004, 12:07 PM

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 · #11 10-03-2004, 12:45 PM

Quote:

Originally Posted by 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.

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

Windcatcher · #12 10-03-2004, 01:13 PM

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 · #13 10-03-2004, 01:26 PM

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 · #14 10-03-2004, 03:41 PM

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 · #15 10-03-2004, 03:54 PM

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.