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

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?

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

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.

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.

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?

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

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