S3D format question
 

This seems as good a place as any to ask this :

I've been trying to understand the S3D format and can sucessfully decompress all the records in one now.

I can get the record containing the "filenames" but they don't seem to be in any particular order I can find. The first filename doesn't seem to match the first directory entry...

How can I tie up the filenames with the directory entries?

Sort the directory entries by their CRC in ascending order :)

Ah thanks, that works :)
What a strange file format.

I've now downloaded your viewing program instead of looking for random web pages with the information although i can't build it as I only have windows handy. Hmm, I think there is enough in there for me to decode the WLD files too at least enough to build a list of untextured triangles I can draw.

Well, we hope to move fully away from wld soon. We're planning to convert all wld files to their new-style equivelents for efficiency and cleanliness reasons. Might want to look into how to read .TER files rather than wld hehe.

Well my main aim here was learning some more direct3d.
And the EQ files seemed like a good place to get some textures and verticies to draw :)

Ah, cool. I would help ya out, but I neither know d3d nor desire to learn it :P

Well the graphics API is the easy part. It's getting the right data to put into it that's hard.
DX9 and opengl seem pretty much the same anyway with just a different syntax for doing the same things.

Except OpenGL is cross-platform, and D3D isn't ;)

True, opegl itsself is cross playform although the programs that make use of it tend to be not so much.

Anyway, I'm already reasonably familiar with opengl and wanted to learn dx9 as well. You can never know too many things... And it seemed a good opertunity to combine that with learning about EQ file formats.

Are the other file formats of which you spoke in the earlier message any easier to process, or should I stick to WLD files given that for now I just want to extract some geometry to draw... Possibly doing something more advanced next project.

Ter files are soooooooooooooooooooooooo easy to draw. Seriously, I did it in less than 60 lines of python lol. My documentation on the file format is available on this forum.

Thanks for that it looks interesting.
I'll take a better look at it tomorrow :)

You are right it is an easy format.
I've rendered "anguish" zone although all the triangles have a single texture so far. Real textures are a project for another day...


Thanks for the help :)

http://img76.exs.cx/my.php?loc=img76...e=render01.jpg

(Bah, can't seem to add a proper image to this posting...)

This is how ya do it:
http://img76.exs.cx/img76/9436/render01.th.jpg
Click to Enlarge.

Thanks , I tried about 20 different times with html and [img] tags but the preview just showed what I typed in.

For future reference. (Imageshack images only)

Lets say is the picture. To get the preview version attach th. to the suffix. So its now .

So you use :D

Nice job :)

However, you seem to have your vertices wrong or something... It looks like it's in a mirror.

Oh yes there are lots of things wrong. I was just pleased to get something that looked like it was at least coming from the correct triangles after a lot of work.

It originally rendered it going up and down the screen (I'm probably getting my x and z coordinates switched somewhere) so I put in a quick rotate to turn it through 90 degrees. Just a hack really to get something working. I need to figure out the exact problem and fix it rather than hack the symptom...

Also I expect most of the triangles are "inward" facing so you're probably seeing the far inside walls and not the top of the buildings at all. It's only intended to be renderered from inside the walls but withoug proper textures it's very hard to tell what you're looking at.

Well, it's a great start :)

Just to let you know, we do the same rotation in OpenEQ, so don't feel bad :P

It's just the way they store their vertices I guess.

One question on texturing if you don't mind?

The "group" flield in your polygon structure in the TER file? Is that just an index to the appropriate texture? (Well the texture, bumpmap, effect etc. that you decoded in your other posting) or is it something more complicated? The group numbers I looked at all seem small enough to be indexes into that table?

Yep, that's a material group ID. If it's -1, then either leave it out, or render it with a pure color, at least until we figure out what we're supposed to do with those.

Well I got it partly working.
I seem to be getting group indexes which are larger than the number of textures I've loaded, and also I'm getting a lot of missing triangles it seems.

But it looks nice :)

http://img26.exs.cx/img26/3194/render3.th.jpg

Looks pretty damn good so far. Nice work :)

Thanks :)

I'm probably not going to go too much further with this although it's awfully tempting to fix the bugs, and implement lighting and bump mapping properly as well as a way to move around the map. But I don't have the time with work and all really, but I might be interested in helping out in a small way with your project should you need any help in the future.

Cool, thanks :)

Speaking of OpenEQ... I just fully finished the octree and culling code... it rocks :D

Excellent. Does it speed up rendering much?

Hmm, still can't get the converter to work. I suppose I could build it under linux and compare the output files maybe.

Heh, it's so incredibly fast it's not even funny :D

Still stuff I can do... in particular, using vertex buffers where supported. Right now, each end octree node has a compiled display list on it that we execute to render that node, and replacing that with a vertex buffer in video RAM might help a bit.

Be careful, though: Since you have to group the faces by texture you might end up with many small vertex buffers, which won't help you much in VRAM. It all depends on the size of your octree leafs :)

The vertex buffer object (ARB) extension should be supported on almost all vid cards, even my old GF4 Ti 4200 supports it.

Hrm... yea...
I'm really new to doing advanced OpenGL optimization, so this is all new to me hehe. I'm mainly just experimenting and benchmarking right now to find the best way.

I'm having big problems reading TER files properly at the moment.
I'm trying to decode "wallofslaughter.eqg"

I extract ter_fortress.ter from the file which is at offset 19733813 and decompressed size is 9425438 bytes.

It has 29 texture entries, 190961 vertexes, 165352 triangles.

The problem I have is that this seems to be wrong because when I calculate the start location of the vertex data it seems to work out in the middle somewhere of the vertex data so I'm assuming I'm getting either the counts or the total size of the "file" wrong.

If you are able to decode this EQG file properly can you check my numbers please?

Thanks.,

Are you skipping past the unknown data before the vertex list?

Well I'm doing this... Based slightly on your code... It's not perfect code but I've been hacking it a lot as I go, it could do with some proper structures and stuff. Too many global variables :(

I'm hoping that "verts" and "tris" will contain pointers to the vertex and triangle structures based on counting back from the end of the file. Which is why I suspected that either I've somehow got yhe counts, or the file size wrong.

Ok there is a big mistake there calculating "tris" - the location of the triangle structures, but the problem is that the verts are not right either.

Oops, I found my problem. My zlib code earlier on was faulty and was leaving a byte between uncompressed chunks so all the data was in the wrong place. I'm amazed it worked at all.

So it works now? Cool :)

I gotta go to the doctor in a few, but I'll be back shortly hehe.

Yes it works! Amazing how trying to explain the problem causes you to suddenly realise what the problem it is

http://img68.exs.cx/img68/5009/render03.th.jpg

Next I'll try converted potranquility

Looks great man. Nice work :D

http://img69.exs.cx/img69/5350/render04.th.jpg

and

http://img69.exs.cx/img69/1870/render05.th.jpg


Thanks to your work figuring out the file format and making the converter :)

No problem, it looks great :D

I notice that in the poknowledge file there is a lot missing, like trees, the portal stones etc.

I presume these are added as objects onto the basic map.

Do we have any information on the file formats for these objects & their locations at all?

On my directX9 renderer at the moment I'm just creating one huge vertex buffer with all the vertices in and one huge index buffer with all the triangles in.

And then I'm going through every triangle and setting it's texture and then drawing it via the index buffer. The only optimization I'm doing is checking if the texture is the same for two consecutive triangles and not setting it again.


Even drawing every triangle individually I'm getting about 3 frames per second on poknowledge.

My next plan would be to pre-sort all triangles into a seperate list for each texture so I can draw many triangles with a single index buffer.

Not sure how culling triangles for visibility fits in with this... I suppose that every frame I need to check each triangle for potential visibility using the octree stuff (Does it have this information for the older zones?) and build a new index buffer containing only the triangles I want to draw for each frame.