Volca on 14/9/2007 at 10:06
Quote Posted by SiO2
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 ].
Thanks for that! I think TDM will be the final answer for a new thief. OPDE is more about the past, and TDM more about the feature :)
Quote Posted by SiO2
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. ;)
I'll definitely take a look. Dark's maps use BSP as well. I rewritten the Ogre's BSPSceneManager into the DarkSceneManager for the purpose of OPDE.
Quote Posted by SiO2
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.
Yes, this was my concern. The current SceneManager uses BSP to find the root cell for a camera, then uses screen-space portal projections to find the visible cells.
Quote Posted by SiO2
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. ;)
The lightmaps are inserted ordered per texture ID, then by size to atlases. This means it's likely that the texture will be satisfied with one atlas, if it is not used excessively within the level. Maybe some smarter approach would minimize the number of combinations. I also realized that limiting the atlases to a certain size helps (This was the time I tested on old GeForce 2, now I test on NV 7600GT).
It's interesting, but rendering without lmaps gives nearly the same performance. Rendering with single material gives a huge performance boost. Thus it seems lightmap atlasing is not a big issue here.
Quote Posted by SiO2
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 absolutely agree. The problem with the low FPS probably comes from the fact that I fill index buffer every frame N times (where N is the count of the materials involved). I also tried creating a separate mesh for each cell, but as there are hundreds or thousands of those rendered in some cases, Batching again was an issue. Now I'd like to group the cells into larger chunks, but not use any dynamic index buffers.
Quote Posted by SiO2
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:
That is perfect for me! I do not have many problems besides the rendering stuff.
To save you some time: The SceneManager is located in src/DarkSceneManager, the WorldRep loader is in src/services/worldrep (there is the lmap atlas implementation as well). The code is a bit dirty, as I've rewritten it a couple of times.
To use irrlicht for the loading, You'll just have to reimplement some parts of the worldrep service, and probably a big part of WRCell. The loading uses File and FileGroup classes, implemented in base/file, but should not be hard to rewrite using a different file implementation (fstream).
I'll be glad to answer any questions for you. If you'd want, I may actually find the old loader for irrlicht too (very dirty).
SiO2 on 14/9/2007 at 12:01
First thing I'll do is build it "as-is" with Ogre and see what frame rates I get.
Careful with BSP. It's a spatial hierarchy system like octree. BSP is useful for traversing the scene front-to-back for the depth-buffered opaque pass and back-to-front for the transparent stuff. Quake3 does extra calculations (offline) to determine PVS. I don't know what PVS system Thief maps use but I doubt it's BSP on it's own. I'd imagine the portal system works out what's occluded and BSP system draws in the order you require (for opaque/transparent passes).
BTW I was recently recruited to TDM (The Dark Mod) but they haven't yet given me access to any assets, so I haven't done anything yet with it yet. :erg:
New Horizon on 14/9/2007 at 12:39
Quote Posted by SiO2
BTW I was recently recruited to TDM (The Dark Mod) but they haven't yet given me access to any assets, so I haven't done anything yet with it yet. :erg:
You were going to be looking into the Dark Radiant preview renderer, which will work with vanilla doom 3. :) You don't need the full Mod assets for that. If I recall, you said you already downloaded the Dark Radiant source code, so you should already have everything you need to work on it. We'll discuss it over PM.
Volca on 14/9/2007 at 12:50
Yep. BSP is solely used to determine a cell ID for a given position in the space, not for visibility determination. There is no PVS, only portals from cell to cell. Here start the problems, as the cells are very small chunks of geometry, thus ineffective for rendering on modern hardware. You get the back-to-front or front-to-back ordering easily from the portal traversal itself, as the cells are convex, so the traversal itself will sort front to back. It's easy to understand this if you see the algorithm used. There are some optimization to minimize re-traversal because there can be multiple paths for a given portal-cell subtree. I guess the visibility determination's speed is relatively ok.
I can assist you with the opde building, as it is a bit rough now, and the developers setup text is not 100% actual (because a lot of changes happened lately and I didn't find time to fix yet). I currently solve some problems with windows builds with one project member. Under linux, everything is easier. Just PM me, mail me, ICQ me, Jabber me, or anything, and I'll try to answer any questions :)
You'll be in the special/golden people list for this help! ;)
SiO2 on 14/9/2007 at 13:33
I would call a portal system "PVS" (Potentially Visible Set, for those who are wondering) as it is designed to cull cells that are not potentially visible.
You're not rendering cells within the traversal stage, are you? I'd expect that not to be an optimal way to batch. ;) The usual method is to traverse the portal graph and mark cells that are to be drawn "this" frame (usually with the frame number). Especially if you want to do reflections, refraction, etc as you need to render the scene more than once for those kind of things. :cool:
What you'd like is something like the following pseudocode:
for each lightmap L {
[INDENT]set texture unit 0 to L;
for each texture T {
[INDENT]set texture unit 1 to T;
build index buffer for geometry that require L and T;
render geometry;
[/INDENT]}
[/INDENT]}
The issue of sorting is one that you can't do perfectly. You can't sort by texture, lightmap and front-to-back simultaneously. These days you usually take the hit of overdraw in order to minimise hardware state changes. A portal system should give rough front-to-back order anyway. ;)
Also, when I say "sort" it is usually an implied sort, using something like a linked list (built during traversal).
Anyway, enough talk - I really need to go and take a look... :thumb:
Volca on 14/9/2007 at 13:49
Quote Posted by SiO2
I would call a portal system "PVS" (Potentially Visible Set, for those who are wondering) as it is designed to cull cells that are not potentially visible.
Ok, that makes sense :) I tend to call it dynamic-PVS, but I'm not a "pro" at these things.
Quote Posted by SiO2
You're not rendering cells within the traversal stage, are you? I'd expect that not to be an optimal way to batch. ;) The usual method is to traverse the portal graph and mark cells that are to be drawn "this" frame (usually with the frame number). Especially if you want to do reflections, refraction, etc as you need to render the scene more than once for those kind of things. :cool:
Nope, after the traversal. As you describe. Basically I build a list of cells, and this goes, after traversal, to methods that prepare the geometry before rendering. Same as BSPSceneManager does it.
Quote Posted by SiO2
What you'd like is something like the following pseudocode:
for each lightmap L {
[INDENT]set texture unit 0 to L;
for each texture T {
[INDENT]set texture unit 1 to T;
build index buffer for geometry that require L and T;
render geometry;
[/INDENT]}
[/INDENT]}
The issue of sorting is one that you can't do perfectly. You can't sort by texture, lightmap and front-to-back simultaneously. These days you usually take the hit of overdraw in order to minimise hardware state changes. A portal system should give rough front-to-back order anyway. ;)
Also, when I say "sort" it is usually an implied sort, using something like a linked list (built during traversal).
Anyway, enough talk - I really need to go and take a look... :thumb:
Now this is something I was not aware of. I tried to minimize the material counts, so basically I went a good way, but did not do any special material sorting, as those are quite equal in definition now. A good subject to think about.
Can't wait for a commentary (Any really, including how stupid I may be :idea: ) :thumb:
SiO2 on 14/9/2007 at 14:14
OK, just pulled the code down from CVS. I use Visual Studio 2005 - you wouldn't happen to have VS project files by any chance (any version - VS2005 should be able to open older versions)? I can build a project from the makefile but it would be much quicker if you (or someone you know) already have one. ;)
As I say, you can't sort perfectly. Sorting by lightmap-then-texture is usually good enough. Plus you don't want to burn cpu, as nearly all non-trivial games are cpu limited - you need as much cpu as possible for ai, physics, scripting, etc.
Volca on 14/9/2007 at 14:27
The project uses CMake now which will generate the VS Project (Solution) for you. I'm sorry, I use Code::Blocks under linux, and generate the project for it using CMake as well. There are some sharp edges. I'll gladly fix them for you...
I just realized I sort back-to-front for some reason. Stupid me :mad: A residual from the time I was sorting out the SKY_HACK. I don't have fam.crf here so I can't test the difference.
Anyway, I guess PM will be a better place to talk now. Should I PM you some instructions?
SiO2 on 14/9/2007 at 14:38
Quote Posted by Volca
Anyway, I guess PM will be a better place to talk now. Should I PM you some instructions?
Yes please - PM me. A bit of info on generating VS project files should be enough to get me going. :cool:
New Horizon on 14/9/2007 at 18:03
SiO2, did you get my PM's? :(
