Freddo on 13/9/2007 at 01:45

---

That's awesome Volca! Well done! :thumb:

Volca on 13/9/2007 at 10:07

---

Thanks again everyone!



I hope this is not too far away. Some problems will have to be solved. Maps are quite complex, and are too partitioned to be effectively rendered on modern hardware. This is the main reason for somewhat low FPS.

Thus, I plan to rewrite the visibility calculation to use larger chunks of the geometry, saving some traversal time and making the batching more effective. Dynamic shadows will be implemented as soon as the lightning will be handled. There are some problems to solve here too (Light counts may be big in some cases). The plan is to use stencil shadows (texture shadows can't do omni-directional lights if I'm not mistaken).

I'd like to use some entirely different visibility determination model for the static geometry (currently it is much like the Dark's one), but the levels are so big that using octrees for example would not be a good choice. The portals just have to stay there for the original levels... For new content, the possibilities will be much more flexible (For example using some landscape SceneManager etc.).

At least now we have a, hopefully good, Object system core to build other things upon.

Well, back to work :)

Volca on 13/9/2007 at 12:51

---

You're right.

The AI tunning - to act the same as the original one. It's not that hard to understand how AI works, but it is a complex system with lots of dependencies. Tuning it will probably be a hard thing.

From one point of view, the core of the AI is a simple state machine, but that is really the inner core of the AI. Then there is the hearing and vision system, AI to AI interaction, etc. Not to mention the motion schemas and their interpretation in OGRE :)

Then, there is the thing with rendering. I'm still not pleased with the current situation, as I written already. There are problems with both flexibility and performance. Both need some, not elementary, knowledge of graphics programming and experience. Now don't get it wrong. The renderer now works at about 90%-110% of the performance of the Dark's, which is not bad. The problem lies in the fact that the WR/WRRGB is optimized for old systems, where each pixel drawn was a huge penalty. Now you can just render a half of the map with a decent FPS, but if you'll enable lightning, the count of the lights will just kill it again.

I still search for an optimal way to overcome the limitations. The latest ideas are to try to use rooms for wr cell grouping and/or use the Ogre's static geometry instead of the dynamic index buffer building approach. I'll see what will do, if any of these.

SiO2 on 13/9/2007 at 23:03

---

Looks very interesting. I'll download from cvs and take a peek. I've been known to make some 3D stuff myself: (http://sio2.g0dsoft.com) :cool:

In one of my demos I get ~540fps with a Quake3 level, motion blur, rendering to an HDR rendertarget (fp16) and a full physics engine. Some of the OPDE screenshots seem to have pretty low fps compared to this.

SiO2 on 14/9/2007 at 09:15

---

I really like what you're trying and do and hope you have much success. It would be ironic if Thief4 was made using OPDE. :laff: Does OPDE run on consoles? [Only joking! :D ].

I wrote my own SceneManager plugin dll for Ogre so I'm quite familiar with it. The SceneManager was for the OpenBSP format but this format has died (especially since id made Q3 build tools GPL). If you search the Ogre forums you'll probably find my posting asking if people were interested in an OpenBSP SceneManager. ;)

The use of either Ogre or Irrlicht isn't important in my opinion - both should be able to handle the "small" amount of rendering load in TDP and TMA levels equally well.

Octrees: note that these give you spatial hierarchy but not what I would call PVS. Worst-case scenario with an octree is that the whole level is drawn, as it does not take into account occlusion. Example: if you're standing in front of a high wall looking toward a mansion an octree will return the wall polys *and* the whole set of polys for the mansion; a PVS system will just return the wall polys.

Are you sorting by lightmap and then texture in order to increase batching? In one screenshot I saw ~850 polys with ~45 batches at ~50fps. Recent hardware should be in the 100's if not the 1000's. ;)

Thief was written in a time when saving overdraw was a major concern. These days we utilise the depth-buffer more but still don't draw the entire level every frame due to the amount of detail usually associated with each polygon. Thief has tiny textures, few of them and a tiny amount of polys compared to today's 3D games. To start off with we could just use a brute-force approach but as we add more rendering detail some form of PVS will be needed, I think.

I'll see if I can take a look at the source in CVS over the weekend and try a build. As you mention, I am currently an Irrlicht user (though I'm using a performance-enhanced version called IrrSpintz) so my own rendering tests may be using that. I will separate the 3D rendering and Thief level building into separate classes so it's 3D engine-neutral as much as possible (if you've already done that then you've saved me a bundle of time).

BTW My interest is really only in the 3D rendering side (though perhaps I could sort out the physics too). I see you are taking on the whole thing (AI, scripting, etc) - best of luck with that hugh task! :cheeky: