Doom3world

I get about double FPS (from 20 to 40) when using 128x72 feedback buffer, but i get the crazy incorrect lookups at borders. Using anything other than 128x72 or 1280x720 scrambles the screen.

Thoughts on getting lighting in without using generated normals or another page for normal lookup (just yet), you could generate them on the fly, but just use flat fixed values.

I think I've got a good idea of how I'd personally like the process to be:

new map:

• build basic shell from brushes, assigning traditional materials during the blockout stage.
• import fbx models, with materials backward compatible to vanilla idTech4
• fbx models may contain collision meshes- these would be indicated with standard nodraw materials. They can be toggled on or off in the modelStudio preview viewport
• on import, you have the option of assigning the model to a particular VT
• map editor allows you to view models with traditional texturing until you choose to compile the VT
• the VT is built, with pixels from traditional (tiling or otherwise) textures copied into their appropriate locations in a very large tga. This would be done by creating new UV's coordinates for VT, and sampling pixels from the original UV's.
• a model is created for painting, referencing large tga. This could potentially be broken up into several models (I think this is how .landscape files are used in RAGE). Ideally, UV grouping and relative scale is preserved from static model layouts.
• It would be nice if there was a facility for extracting regions of the megatexture (say 8-32k) and reinserted into large texture after editing.
• VT tiles can be regenerated any time the large tga is updated.

This would allow people to use the workflows they're used to as a starting point for the VT, would allow for light baking in DCC apps, and stamping/painting on the VT image in any 2d or 3d app capable of handling large images. It would be a complete pipeline to start building test scenes, without having to build out a massive VT editing infrastructure in engine tools.

Concerning lighting, you could potentially create a separate lightmap image to be composited into the large tga by external tools.

Also, I made a movie clip showing some of the VT debug commands in RAGE:
http://www.mixomracing.com/tmp/rageVTdebug.mp4

Interesting that they do not jitter their feedback buffer.
Many games jitter polygons between frames, so they will see small/thin polygons better. (polygon offset in screenspace, something like 0.5 pixels in both x&y.)

Yeah, I noticed that too. It's definitely used in Brink, their graphics guy mentioned doing it on beyond3d. http://forum.beyond3d.com/showpost.php? ... stcount=17

I'm not sure if it would even help the current issue here- it's always mentioned as solving failed lookups for small triangles, but the problem seems to be filtering at tile borders.

It's worth noting that the video was captured with a really bad config- no gpu transcoding, 4096 (as opposed to 8k) page cache, no disk cache. I get much better loading performance with a tuned cfg.

I actually figured out whats causing the nasty borders and its a drr mistake . Basically the way I was doing before was I would readback what tile is needed were from the feedback fbo(which is in screenspace), just changed over the pixels so they matched the current area on page were the tile got blitted to and wrote it back to the atlas texture. Obviously if the feedback fbo was out of perportion from the main screen fbo you would get a lot of nasty problems, like wise those nasty borders where actually aliasing from the feedback fbo/atlas texture.

To resolve this instead as before I render the scene to a small feedback FBO, instead of just replacing the data and uploading it to the atlas texture; I instead made the atlas texture a tex2Drect, and in the pre deferred rendering pass I render the default 4096 atlas(which points to the tile positions in the VT), and in the glsl shader I look into the atlas texture for the tile in the page were it got blitted to and replace it out in the shader.

I'm still having some issues with it but this will fix the nasty nasty border issue, the requirement for the feedback buffer to be so high, the border will still show a tiny bit but thats something to tackle next : ).

This post is probably going to be a bit redundant since most of the stuff has been mentioned already but I figured I'd add in my two cents anyway.
After playing around with the CVars last night I did notice that they seemed to increase the visual artifacts located around what I'm assuming are the edges of the tiles. The values tried were 1024x768, 800x66, 640x480 and 300x200. Since these were a different aspect ratio from 1280x720, this is the same behavior parsonsbear described earlier.I did notice another z-fighting issue along where the right wall from the starting position and the first set of stairs going down meet. I noticed that the scene FBO debug window displays the geometry upside down, I'm assuming that this is intentional. I also noticed that my machine didn't display a loading bar like the one seen in the video. Nothing major, but I thought I'd mention it. On the other hand, I did test this build on Wine 1.2.3 under Linux and it ran without any trouble.

I took a look at SCons yesterday and started reading the user's manual. So far so good, doesn't seem to be overly complicated. I'll probably pick at this over the next day or so.

EDIT: Updated Wine to the latest stable release 1.4 and the test release continues to work as well as it does under windows.

Alright I fixed the nasty border issue, including the readback border issue, its in SVN ill get up a new binary build in a bit for those that want to try it. Also the vtatlas texture is now compiled when the VT is loaded, rather than it being saved out to the HD(reduces the build by 64mb).

Also put back in the lighting code. Right now the light code is causing a bit of a bottleneck because of the bumpmap offset code reading the incorrect height of the texture(this is becuase I'm forcing the height of each pixel in the image to 1). Like wise since I'm not loading bumpmaps spec code is commented out in the shader, and the bumpmap is hardcoded to 0.45, 0.45, 1.

But now you should get around 60fps and you can change the vt readback buffer to any size you want and it won't cause any nasty issues(this is because the readback system is now coded properly ).

Keep in mind I'm using integer textures for the vt atlas, which is a GL 3.0 feature. I'll fix this soon so the engine will be compatitble with 2.0 cards again.

I uploaded a new binary(still doesn't include the tools just as a fyi, if you are building from SVN you will need to recompile the tools dll), I quick commented out the bumpmap offset stuff just to demonstrate it runs properly now at 60fps. Also put back in the post process code, and fixed the issue were some cards that returned "shader compiled successfully" would cause a error.

I changed a few materials as well so I recommend downloading this build even if you already downloaded test01 to ensure you don't have any deprecated data(make sure you don't have ANY of the old assets in your base directory, so unrar this to a new folder just to be safe).

Just want to ensure the new VT Readback code works properly on everyone's cards.

http://www.blackenmace.com/test02.rar

EDIT:

I also uploaded a new binary that includes the toolset for those that want to play around with it. Its important to understand these tools currently have a lot of errors(simply because I haven't updated them to support VT). You should not open any of the editors except radiant(the gui editor also works as well). These tools do not represent anything more than a temporary means to make and test the virtual texturing code.

Downloaded it, unziped it, ran the batch, watched it crash: http://img694.imageshack.us/img694/9349/errortest02.jpg

Computer Specs:
OS: Windows 7 Home Premium Edition [6.1 Build 7601] (x64)
CPU: AMD Phenom II X4 970 Black Edition(Quad Core, clocked at 3.5(stock))
RAM: G Skill DDR3-PC3-12800 16GB
VRAM: 1,024MB (1GB)
GPU: ATI Radeon HD 5770

Driver:
Driver Packaging Version: 8.95-120214a-134393C-ATI
Catalyst Version: 12.3
2D Driver Version: 8.01.01.1235
Direct3D Version: 7.14.10.0894
OpenGL Version: 6.14.10.11554
AMD VISION Engine Control Center Version: 2012.0214.2218.39913

Can you download the SVN and build the code and see exactly where this is crashing? I need to get in debug code to see where its crashing. Off hand I would say since I haven't updated the main menu map with VT, and your using a ATI card, its probably something to do with that. Thats good to know though if that is indeed the issue I'll get that fixed in the next release.

If you are able to build the code comment out all the code in Game_mainmenu.cpp and it should fix the issue.

ATI cards tend not to be as forgiving as NVIDIA boards, but this def good to know.

Also in the SVN I got in automatic vt_blocksize setting so you no longer have to manually set this value. So by default all your UV's for the VT should now be built properly.

I've already hit my download cap for today. But tomorrow(Wednesday) I can. It should compile fine with VS Express 2010 right?

Yup if you have any problems with MFC just don't build the tools DLL.

I just downloaded it. I thought it was going to be bigger filesize-wise. (For example; HL2/Source2007 mod code is 800+MB.)


Anyways... I attached VS to the process after running the batch file. I got this:
http://img853.imageshack.us/img853/5497 ... test02.jpg
Not very useful. I know the crash happened in/because of atioglxx.dll. But my drivers are the latest, so I doubt that is the problem.

Could someone who can run it with an ATI card check the version of their atioglxx.dll? It's in :\Windows\SysWOW64 or :\Windows\System32 Just right click it -> Properties... -> Details -> File version:
Mine is 6.14.10.11554
I've tried doing the Rage fix, of copying it to the game folder. And I've tried using the older 6.14.10.11318 version of the dll. All results in the same crash.


One other thing, I get three errors, saying how I don't support folders in VS. Is this okay? (You can see in the above picture, they are marked Unavailable )


Edit: Trying to build the DeadlyLaw project results in quite a few errors:
http://pastebin.com/J4bdYSuC

I tried the test out last night. It worked okay, got about 60fps on average as I should. I did notice, however, that when moving towards the second stair case that in certain positions the lighting will seem to change or shift causing areas that were lit to be shadowed and vice versa. I did still notice some seams along the edges of the tiles, but I think you mentioned that's the next thing to fix. I haven't played around with the CVars yet, so that will probably be the next thing.

Note: This was tested on Linux with Wine 1.4. I'll do another test on windows to make sure it isn't a wine problem.

The borders still aren't 100% yet and the lighting error your seeing is the shadow mapping code doing nasty self shadowing. This only happens on the world.

Works well for me. 30 fps increase from Test01 to Test02. Pegs at 60 in Test02 (any cvar to disable the 60fps cap? com_fixedtic doesn't work, and no com_unlock cvars like ETQW).

Specs: Core i5-2400, GTX 460, 8gb Ram, Windows 7 64bit.

I'd like to second whoever asked for global illumination. I'm a total noob, though, so I'm not sure if this is doable given the non-baked lighting approach. This was the biggest sticking point for me in deciding not to use Doom3 for my current project. Also if anyone wants to try a Linux build I'm down for testing it.

Comment out all the code in all the functions in game_mainmenu.cpp and change all the project settings to debug inlines, if you get those errors that means the project build target got changed.

should be totally doable it just has to be a real-time solution otherwise (imho) it could clash with tech 4s real-time lighting solution

as i have stated here already i feel like global illumination and radiosity will be neccissary to compete with other solutions however maybe its something that should not be worried about just yet

i mean it might be a good idea to get the self shadowing issues nixed first and the VT solution running pretty before tackling something like radiosity etc

anyway here's some fun reading materials on real-time GI and Rad

http://realtimeradiosity.com/

http://www.liensberger.it/Web/Blog/wp-c ... y_kl08.pdf

http://www.cg.tuwien.ac.at/research/pub ... -paper.pdf

There is a middleware called enlighten that offers realtime GI with Rad and i have to say it looks gotdamned sexy
http://www.geomerics.com/enlighten/features.html

it was used in the frostbite 2 engine:
http://www.youtube.com/watch?v=O8730SR1POk

I tried test02 under windows and was playing around with the FBO size CVars and everything seems to be in order...though this was expected behavior. I didn't realize that the self-shadowing bug was still there, but I recalled something mentioned earlier about the fact that since this is only present on brushes then it may have something to do with how Doom 3 does its culling. I tried playing around with a few CVars to see if I noticed anything changing then I noticed the bug. After first discovering that the r_showTris CVar doesn't seem to work in your code base. I tried a few things and discovered, and this may not be any revelation at all, but the self-shadowing bug seems to be eliminated by setting r_useCulling to 0. There is still something odd happening once you reach the top of the second stair case, but I have noticed that it did stop the shifting shadows when moving that I had mentioned earlier.



Global Illumination is still sorta new tech wise, though so is virtual texturing. Unreal Engine 3 only added static GI support with the UDK. Cryengine 3 supports real-time GI, though only used with sun light, but they didn't utilize it at all in Crysis 2. At least with Cryengine 3's implementation, there ended up being some errors that surface like light bleeding through geometry when activated. I like the feature and would like to see it added as well since it can greatly enhance the look of game environments. I do realize, however, that its implementation and integration into the existing code base might not be the simplest task. While a royalty-free implementation of real-time GI similar to the one used in Cryengine 3 is available at the NVIDIA's developer's website, it is in Direct3D and not OpenGL. This would have to be rewritten before one would even think about its integration.

EDIT: Okay, shadowscrawl beat me to this a little bit, but I'll leave it as is.

I might be mistaken but i think at least one of my links above has some OpenGL solutions with source code in GLSL to simplify here's a direct link to the page: http://realtimeradiosity.com/demos/

Commented out the code in the functions. And changed the projects over to Debug with Inlines:




Something is definitely wrong. I can't even use the standard game stuff(like idCVar, idVec3, etc.).