EQEmulator Forums - S3D format question

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Archive::Tools (https://www.eqemulator.org/forums/forumdisplay.php?f=623)

- - S3D format question (https://www.eqemulator.org/forums/showthread.php?t=15914)

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.

Code:

void ProcessTERFile(char* terdata, int size)

{

        int magic                = *(long*)(terdata+0);

        int unk                        = *(long*)(terdata+4);

        int list_length = *(long*)(terdata+8);

        int obj_count   = *(long*)(terdata+12);

        int vert_count  = *(long*)(terdata+16);

        int poly_count  = *(long*)(terdata+20);



        assert(sizeof(TERVertex) == 32);

        assert(sizeof(TERTriangle) == 20);



        char* verts = terdata + size - (vert_count * sizeof(TERVertex) + poly_count * sizeof(TERTriangle) + 4);

        char* tris  = terdata + sizeof(TERVertex) * vert_count;



        g_nVerts = vert_count;

        g_Verts  = (TERVertex*)verts;



        g_nTriangles = poly_count;

        g_Triangles  = (TERTriangle*)tris;



        /* Now process the texture names part */

        char* p = terdata + 24;

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?

Quote:

Heh, it's so incredibly fast it's not even funny Very Happy

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.

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.

Old zones use BSP trees, you have to create the octree yourself (very straighforward and takes like 2 hours max. to implement fully).

When you have that octree, group the faces by texture for each leaf in the tree. After that you can easily do frustum culling against the bounding boxes of the leafs. That's almost all you need to do to get fast rendering.

Yea, it's very easy to do frustum culling using the octree. If you want, pull octree.c/octree.h from OpenEQ's source... should help you quite a bit. It's released under the GPL, btw, though I haven't yet put it in the source :P

Thanks, I had a look at your code.

The idea seems pretty simple really but your code doesn't really work with the way I've stored things so I'll probably have to re-do it myself this time.