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

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?

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/showf...ckage_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.

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

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

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

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

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

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

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

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.

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.

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?