revelator

Ok to get this far and because it might be off interrest to others create this in Image_Init.cpp static void R_DepthBufferImage(idImage *image) { byte data[DEFAULT_SIZE][DEFAULT_SIZE][4]; memset(data, 0, sizeof(data)); data[0][0][0] = 16; data[0][0][1] = 32; data[0][0][2] = 48; data[0][0][3] = 96; image->GenerateImage((byte *)data, DEFAULT_SIZE, DEFAULT_SIZE, TF_LINEAR, false, TR_CLAMP_TO_BORDER, TD_HIGH_QUALITY); // now reset it to a depth image glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT24_ARB, DEFAULT_SIZE, DEFAULT_SIZE, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, data); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_MODE_ARB, GL_COMPARE_R_TO_TEXTURE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_FUNC_ARB, GL_LEQUAL); // explicit zero depth border float color[4]; color[0] = color[1] = color[2] = color[3] = 0.0f; glTexParameterfv(GL_TEXTURE_2D, GL_TEXTURE_BORDER_COLOR, color); } second change currentDepthImage = ImageFromFunction("_currentDepth", R_RGBA8Image); to currentDepthImage = ImageFromFunction("_currentDepth", R_DepthBufferImage); This example taken from draw_exp.cpp ok next off change the old CopyDepthBuffer to void idImage::CopyDepthbuffer(int x, int y, int imageWidth, int imageHeight, bool useOversizedBuffer) { this->Bind(); // if the size isn't a power of 2, the image must be increased in size int potWidth, potHeight; IMAGE_ROUND_POWER2(imageWidth, potWidth); IMAGE_ROUND_POWER2(imageHeight, potHeight); // Ensure we are reading from the back buffer glReadBuffer(GL_BACK); // only resize if the current dimensions can't hold it at all, // otherwise subview renderings could thrash this if ((useOversizedBuffer && (uploadWidth < potWidth || uploadHeight < potHeight)) || (!useOversizedBuffer && (uploadWidth != potWidth || uploadHeight != potHeight))) { uploadWidth = potWidth; uploadHeight = potHeight; if (potWidth == imageWidth && potHeight == imageHeight) { glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT, x, y, imageWidth, imageHeight, NULL); } else { // This bit runs once only at map start, because it tests whether the image is too small to hold the screen. // It resizes the texture to a power of two that can hold the screen, // and then subsequent captures to the texture put the depth component into the RGB channels: (steveL) glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT24_ARB, potWidth, potHeight, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL); glCopyTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, x, y, imageWidth, imageHeight); } } else { // otherwise, just subimage upload it so that drivers can tell if we are going to be changing // it and don't try and do a texture compression or some other silliness. glCopyTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, x, y, imageWidth, imageHeight); } glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); backEnd.c_copyDepthBuffer++; } I know this seems like something that should not be but we cannot guarantee that we did copy a depthbuffer so just do it lastly if you use sikkmods shaders find the RenderDepth function and change it to this void idPlayerView::RenderDepth(bool bCrop) { // modify player related models in depth render. if (!player->IsHidden() && !pm_thirdPerson.GetBool()) { player->ToggleSuppression(true); } if (!bDepthRendered) { if (bCrop) { int nWidth = renderSystem->GetScreenWidth() / 2.0f; int nHeight = renderSystem->GetScreenHeight() / 2.0f; renderSystem->CropRenderSize(nWidth, nHeight, true); // set our depthView parms renderView_t depthView = hackedView; depthView.viewID = -8; depthView.globalMaterial = depthMaterial; // render scene gameRenderWorld->RenderScene(&depthView); // capture image for our depth buffer renderSystem->CaptureDepthToImage("_depth"); renderSystem->UnCrop(); } else if (!bCrop) { // uncropped depth is used specifically for soft shadows // set our depthView parms renderView_t depthView = hackedView; depthView.viewID = -8; depthView.globalMaterial = depthMaterial; // render scene gameRenderWorld->RenderScene(&depthView); // capture image for our depth buffer renderSystem->CaptureDepthToImage("_ssDepth"); } bDepthRendered = true; } // Restore player models if (!player->IsHidden() && !pm_thirdPerson.GetBool() && player->bViewModelsModified) { player->ToggleSuppression(false); } } and find RB_STD_DrawShaderPasses and make it look like this. static int RB_STD_DrawShaderPasses(drawSurf_t **drawSurfs, int numDrawSurfs) { int shaderPasses; // only obey skipAmbient if we are rendering a view if (backEnd.viewDef->viewEntitys && r_skipAmbient.GetBool()) { return numDrawSurfs; } // if we are about to draw the first surface that needs // the rendering in a texture, copy it over if (drawSurfs[0]->material->GetSort() >= SS_POST_PROCESS) { if (r_skipPostProcess.GetBool()) { return 0; } // only dump if in a 3d view if (backEnd.viewDef->viewEntitys) { // copy of framebuffer revelator. globalImages->currentRenderImage->CopyFramebuffer( backEnd.viewDef->viewport.x1, backEnd.viewDef->viewport.y1, backEnd.viewDef->viewport.x2 - backEnd.viewDef->viewport.x1 + 1, backEnd.viewDef->viewport.y2 - backEnd.viewDef->viewport.y1 + 1, true); } backEnd.currentRenderCopied = true; } // copy of depthbuffer revelator. // might also be used by post process shaders. // viewID -8 is sikkmods id for the depthbuffer. if (backEnd.viewDef->renderView.viewID <= -8) { if(r_skipDepthCopy.GetBool()) { return 0; } // only dump if in a 3d view if (backEnd.viewDef->viewEntitys) { globalImages->currentDepthImage->CopyDepthbuffer( backEnd.viewDef->viewport.x1, backEnd.viewDef->viewport.y1, backEnd.viewDef->viewport.x2 - backEnd.viewDef->viewport.x1 + 1, backEnd.viewDef->viewport.y2 - backEnd.viewDef->viewport.y1 + 1, true); } } GL_SelectTexture(1); globalImages->BindNull(); GL_SelectTexture(0); glEnableClientState(GL_TEXTURE_COORD_ARRAY); RB_SetProgramEnvironment(); // we don't use RB_RenderDrawSurfListWithFunction() // because we want to defer the matrix load because many // surfaces won't draw any ambient passes backEnd.currentSpace = NULL; for (shaderPasses = 0; shaderPasses < numDrawSurfs; shaderPasses++) { if (drawSurfs[shaderPasses]->material->SuppressInSubview()) { continue; } if (backEnd.viewDef->isXraySubview && drawSurfs[shaderPasses]->space->entityDef) { if (drawSurfs[shaderPasses]->space->entityDef->parms.xrayIndex != 2) { continue; } } // we need to draw the post process shaders after we have drawn the fog lights if (drawSurfs[shaderPasses]->material->GetSort() >= SS_POST_PROCESS && !backEnd.currentRenderCopied) { break; } RB_STD_T_RenderShaderPasses(drawSurfs[shaderPasses]); } GL_Cull(CT_FRONT_SIDED); GL_Color(1.0f, 1.0f, 1.0f); return shaderPasses; } and delete the old CopyDepthbuffer code bit from RB_STD_FillDepthBuffer. now SSAO works allmost without bugs but be aware that the change to use the real depthbuffer breaks sunshafts.

SSAO now without the outline bug breaks sunshafts though (massive lightbleed) so unless someone can fix that part it would have to stay off. Aye sikkmods softshadows are a bit buggy especially on ATI/AMD where the shadows turn up green in gausian and box but atleast they work pretty well with the poisson filter allbeit ultra slowish.

Not sure why it would be needed for a screenshot of some work in progress but if you wonder yes soft shadows still suck FPS wise, mostly because the shader needs work to use the new depthbuffer access code correctly, atm both SSAO and soft shadows use a physical image to emulate a depthmap instead of the one copied off the depthbuffer and as you can see it causes all sorts of problems

Sikkpins SSAO bug. Soft Shadows with Depth Clamping instead of depthbuffer testing.

Oh i might have given you to much hope then no they do not run well together so either you use depthbounds testing (settable with a cvar) else it will use depth clamping. Im not 100 but it might be caused by the support code for depthbounds testing, anyway if we end up needing depthbounds testing we could easily create a simple boolean switch to alternate between the two methods instead of a cvar, so far sikkmods soft shadows seem to work just fine with depth clamping.

Ok fixed sunshafts take a look at the hackedview function in the game code it tries to use CaptureRenderToImage("_CurrentRender") to emulate a depth copy so i changed it to CaptureDepthToImage("_CurrentDepth") instead and it looks like it works now yay. Sadly sikkpins ssao shader uses a hack to make the depth image and it still causes artifacts on heathaze / portals and some particles (ghostly outlines on the effects but less visible now).

I think i heard mention of what you describe at the inside3d forums, ill see if i can find the post ARB_depth_clamp was actually a nvidia extension back in the days but got added to the OpenGL spec from version 2.0 i think. Old extention was named NV_depth_clamp and was only avaliable on nvidia cards, not sure why the documentation for what it does is so hard to find .

If i understood correctly it just adds a small offset to the shadow volumen to avoid Z fighting (its kind of a hack but hard to get around without when using stencil volumes). Btw i just got SSAO / SSIL / and softshadows working with the new depth renderer but it causes massive problems with sikkpins sunshaft code if its enabled, if not it works like a charm The sunshafts causes some really nasty overdraw making the scene look like you are looking through a lens directly at the sun ouch my eyes . Looks like this without sunshafts

Ahaaa !!! seems i finally cracked how to get ARB_depth_clamp working Problem: when combined with depthbounds testing it causes really bad artifacting in shadows. Solution: I created code paths to either use depth clamping or depthbounds testing (also for light volumes -> RBDoom3 code). So far it seems to be a good tad faster than depthbounds testing but ill test a bit further before comitting it to darkmod

CodeBlocks can also use msvc but ill keep the msvc projects so no worries. It would only mean more options, besides one could toy with a clang build with a codeblocks workspace and gcc is not half bad when it comes to optimization compared to msvc either.

Uploaded my Revelation Engine here https://github.com/revelator/Revelation-Engine This is windows only and all editors have been removed as well as all the old backends + support code. It also uses defered interactions and uses a somewhat modified stencil shadow code based on the omp patch from linux. Besides that i added the light depthbounds code from RBDoom3 and the work me and steve done with depthbuffer access. Also removed the unused glasswarp code from this one, as well as a ton of fixes for bugs pointed out by dhewm3 and fabian sanglard. The matrices are reset to a default value every pass which fixes bugs in the gui in case you use Sikkpins parallax shaders. Included are game code for mods that work with it (SikkMod Grimm Quest Classic Doom) with the same fixes to the game code as the vanilla code. It works quite well as is for Doom3 While not darkmod compatible there might be a few interresting things devs can have a look at for use with darkmod, or even use it as a base if you like.

cmake is fine and i might use it, setting up my own workspaces saves me having to tell cmake where the nessesary libraries are every time though (atleast on windows) but maybe something can be thrown together for autodetecting those on windows as well. atm dhewm3 cannot find the system libraries if i use mingw64 because some of the headers are in subfolders of the include dir (autotool builds do that unfortunatly). Maybe i can use pkg-config to pick up the correct paths somehow .

As is no, but the changes nessesary to the main executable code should be easy. That said my port does not rely on boost so i need to check out what parts of the darkmod executable code needs boost. The game code needs no change if i just copy in the game code from darkmod so that part is easy, what i need to know are the changes to the rest of the code -> renderer / framework etc. Ill do a diff by the weekend to see what changes are nessesary, and then ill start porting it over. The benefit would be native IDE support on linux as well as windows and the port would be able to use mingw64 on windows instead of msvc . A 64 bit port might also be possible with the dhewm3 changes though i have to check darkmods gamecode and see if the dhewm3 changes can apply without to much work for a 64 bit port.

Hmm i wonder if i should upload my Revelation branch to github for people to hack at. Its probably the cleanest port i made so far of Doom 3 but i removed all editors and build systems for anything but windows (plan was to use the dhewm3 changes and then create a CodeBlocks workspace for Windows and One for linux) but first i needed to update my Compiler suite which is done now. Since it uses Glew i would keep off the SDL changes from dhewm3 since its not needed, glew is useable on linux to. One could probably make the changes for darkmod to run on it pretty easily by keeping darkmods gamecode and do the nessesary changes needed on my port.

Looking to get away with scons completely by replacing it with a project generator named MPC http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/MPC/docs/html/MakeProjectCreator.html I discovered this tool when i looked for a high performance socket library that would be usable with games such as Doom 3. MPC can create make files / autotool based build scripts / msvc project files / borland projects / mac projects, and many more . Could Ofc also use cmake as it also supports multiple IDE's / Compilers but cmake cannot create autotools based build scripts which would probably fly better with linux. MPC is perl based btw.

Ok should be fixed now.

need to remove the source files for those two from the scons build system to, just havent gotten around to it yet but should be easy.

Or use the old code for light as a fallback ? Removing the old backends is easy compared but you will learn something from it. Else id go with something like steve said. Ugh im wasted :S internet went down at work and spent most day trying fixing what turned out to be a broken router (facepalm).

Ok fixed crash and removed all backends besides ARB2 Reformatted sources.

one could probably yank something together from this part of R_LoadARBProgram // vertex and fragment programs can both be present in a single file, so // scan for the proper header to be the start point, and stamp a 0 in after the end start = NULL; if (progs[progIndex].target == GL_VERTEX_PROGRAM_ARB) { if (!glConfig.ARBVertexProgramAvailable) { common->Printf(S_COLOR_RED ": GL_VERTEX_PROGRAM_ARB not available\n" S_COLOR_DEFAULT); return; } start = strstr((char *)buffer, "!!ARBvp"); } if (progs[progIndex].target == GL_FRAGMENT_PROGRAM_ARB) { if (!glConfig.ARBFragmentProgramAvailable) { common->Printf(S_COLOR_RED ": GL_FRAGMENT_PROGRAM_ARB not available\n" S_COLOR_DEFAULT); return; } start = strstr((char *)buffer, "!!ARBfp"); } if (!start) { common->Printf(S_COLOR_RED ": !!ARB not found\n" S_COLOR_DEFAULT); return; } end = strstr(start, "END"); if (!end) { common->Printf(S_COLOR_RED ": END not found\n" S_COLOR_DEFAULT); return; } These defines are allways a part of ASM shaders so they should be exactly what you need

Aye that was one approach i tried and it actually worked but you need the shader.vfp to have the exact name pointed to by the enum. But then its not really a dynamically loaded shader anymore but rather a predefined one.

Voted

Maybe delinquent ?

Then it should work allthough a bug snuck up when i reverted nbhor1mores code so i need to have a look at the latest commit as it crashes on windows. But maybe it does not affect linux so feel free to try.

unless libglew version 1.5 is to old (it was not on my machine) it should be enough i removed the glew include dir from the scons project so that it picks up the system provided one instead. Also changed the include path for glxew.h to <GL/glxew.h>