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?