revelator

Thanks steve newer ABI should allmost allways give a performance improvement = (more functions move from CPU to GPU). GPU's are much faster in handling those kinda calls then a CPU cause thats there primary function. @Msep no worries but im glad you got it sorted out i bet some here might want to hear more about the modifications so if you got time to pop up a tutorial sometimes i think it will be appeciated.

Msep is just vocal about his beliefs i can respect that critisism is a helpfull tool in hunting down buggers you might have missed, allbeit it sometimes comes out badly especially when written (hard to gauge a persons intent via text sometimes). P.s Msep i hope to report back soon on a posibility to turn of the math for shadow generating completely.

I somehow doubt that the khronos group would throw away support for ARB assembly, they still support the old opengl 1.1 standard but yeah its becoming a bitch to keep compatibility, so i can be wrong but lets see. At some point GLSL will have to be worked in regardless, in case of new coders who are used to working with it and go ??? when someone says ARB assembly I dont think babystepping it moving to a newer ABI is a bad thing i broke most of my first tries at fixing vanilla's shortcommings, and it took up a huge amount of time moving the working parts to a new codebase so id rather take it slow from here and make sure i did not break anything before going further. I do plan to get crafty with a GLSL backend based on what i could glean from the BFG source, it might even go hand in hand with the old arb2 backend to keep compatibility. Atm the most complete non BFG based GLSL backend can be found in https://github.com/omcfadde/dante unfortunatly it uses GLES so a few parts need to be ported and mc fadden is dead so the project is stalled :S. Also all non BFG GLSL backends are missing the function to interact with vanillas material shaders, so we need to construct a parser that is able to read out GLSL info from the materials, BFG should give some clues as to how though. Im going to look over how to achive this soon but atm im bedridden with a somewhat nasty flu so it might take a few days before i can report anything.

Was explained earlier in this thread, but to sum it up (it would at its current state be to much work to port all the changes made to darkmod's source to a new engine). btw i just stumbled upon something, it seems gpu skinning is actually possible with ARB assembly, its just not very well documented so hard to find any examples on how to do it. gpu skinning requires gpu matrix operations which have been part of OpenGL since 2000 so yes it can be done, but it will take some experimentation since theres nearly no documentation on it. reason theres no documentation seems to be that by the time where GPU's actually had the muscle to do it people had pretty much switched to GLSL so noone ever made an attempt at documenting it.

maybe this can shed some light on it (phun intended) http://docs.unity3d.ru/Components/class-Light.html not directly related to Doom3 but theres some good pointers in there for how to cope with the performance loss.

Hey steve. Well here in denmark its quite late hehe so good evening. Sikkpins shaders are more of a test i presume so it might not fit all purposes but its a good start . And to nbor1more looks a bit like the same method sikkpin used to split out parts of the interaction shaders, making it possible to have different ones for say POM (parallax mapping does not fit all image types, banding problem on some texture types. Need a perfectly flat image or it fucks up majorly). You should have a look at the changes he made to the editor for supporting ambient lights natively allthough the static version in his mod works it has the same level all through the game, but with the changes to the editor code its possible to code in different levels and colors pr map. Probably a lot of work left even if his code is a good start.

Aye vanilla could use cubemaps instead of math to normalize specular. # instead of using math, normalize with the normalization cube map TEX specular, fragment.texcoord[6], texture[0], CUBE; MAD specular, specular, scaleTwo, subOne; found these two in sikkpins feedback engine, might help a bit with soft particles the PBAO version seems rather large ? seems to use self occlusion maybe thats why , its one of the larger bits of code in that shader.

Got prey can try and run some of the shaders with it if they can be used without material support, else someone would have to guide me through creating those. Or if someone can create a test i could try out ?.

Aye some of it i can probably work out but theres also a new function for parsing fragment maps which im not to sure how to use, unless ofc prey has something similar . Ill see what i can dig up.

Yeah i newer got his engine to run but i know why now atleast. Some of the shaders in there need material support that vanilla Doom3 does not have (yet) unfortunatly without asking him directly it will be a pile of guesswork and take quite some luck to get it all running. A few of the things in his feedback engine has been moved to revelation, mostly small fixes like saving the alpha channel to the normalmap instead of just assuming its full alpha and increasing the number of interactions vanilla can run. Also a small piece of code in there to run gamma normalization on the diffuse maps but it makes the game really dark so i removed it again for now, untill i can boost lightlevels a bit without breaking everything else. If you want to try its in tr_render.cpp and it makes colored light really stand out but again its to dark to really be fun to play. increasing the max number of interactions was not even noticeable on performance so it seem safe. atleast he allways comments his code so its easy to follow the various parts

Been a ton of mods with all kinds of shader based magic for vanilla might be inspiration from one of them, like the brilliant highlights mod, then again that mod is from before vanilla went opensource so hmmm. Anyone had a look at this btw https://github.com/RobertBeckebans/Sikkpin-Feedback

Thanks m8 i allways said give people time and they will figure out vanilla's inner workings, Seems i was not wrong. Still many things that could need an overhaul like implementing FBO's, and removing the ancient OpenGL 1.4 calls which according to gDebugger are the worst offenders resource wise. I have faith that it will come if not ill do it myself but im no ace when it comes to C++ so it may take a while .

Looks really nice steve Had no idea my small contribution would have such an impact, especially when someone seems to understand quite a bit on how to use it, good job man.

I think nbor1more has a link to a heavily modified vanilla source from justin marshall with FBO support. Its a bit of a mess to read unfortunatly and i newer managed to get it to compile because justing used managed extentions from msvc, the code helps a bit though. If i find anything else ill let you know

Heh actually was a similar bug that was patched by copying of some pixels in quake allthough in quake, it was bsp box models that showed a few pixels at the edge of the models as all white Oo i find it rather funny that something similar also happens in vanilla. Oh and probably a good idea getting FBO's for vanilla as well, should make it a bit easier to implement more modern code.

Looks good would have thought it would have a slight impact on fps but no change it seems, maybe need to try this out on something that effects the whole scene like SSAO to see any difference ?. If it has no effect on SSAO or soft shadows fps wise then ouch :S. Also have to take into account that vanilla is hardlocked at 60 fps unless you turn off vsync. Btw i also got amd gfx, 2x R270x in xfire. Cheap card (atleast untill the bitminers started buying all of them) pretty good performer to.

Your a freaking machine steve Stared myself blind sometimes when i tried to get my head around the shader interface to the renderer . I guess you noticed the transposeglmatrix function ? that one had me a little thrown of untill i noticed that vanilla does'nt use standard matrix calls.

Your welcome my mistake anyway, should get around to fixing it soon.

Go into the project properties in the general tab and check which version is shown in the platform version, it should be v100. I forgot to change it back when i made my new branch. edit: need to do this on DoomDLL game game-d3xp idlib typeinfo and MayaImport (not really nessesary unless you have the maya sdk).

Thanks guys yeah proper shadow mapping would blow blurred stencil shadows out of the water performance wise, so even though this would help its still a performance hog, but might not be fatal. Only testing will tell. will it help SSAO performance ? definatly .

Yeah the softshadows are a huge FPS hammer, even worse i found than the hacked SSAO. I can run sikkmod with everything but that on and its still playable but then again my PC is a beast that i doubt many could afford :S. Fixing access to the depthbuffer will most likely make SSAO viable, and it does indeed make the game darker but coupled with sikkpins HDR shaders it looks rather amazing and not dark at all. Shot from a certain secret area in Doom3 uses SSAO SSIL HDR and Colorgrading.

Heres sikkpins SSAO shader from sikkmod. !!ARBvp1.0 OPTION ARB_position_invariant; # input: #-------------------------------- # texcoord[0] = TEX0 texcoords # # local[0] = sample radius, darkening, amount MOV result.texcoord[0], vertex.texcoord[0]; MUL result.texcoord[1], program.local[0].x, { 1.0, 1.0, 2.0, 4.0 }; MOV result.texcoord[2], program.local[0].y; MOV result.texcoord[3], program.local[0].z; END #===================================================================================== !!ARBfp1.0 OPTION ARB_precision_hint_nicest; # texture 0 = _depth # # env[0] = 1.0 to _currentRender conversion # env[1] = fragment.position to 0.0 - 1.0 conversion OUTPUT oColor = result.color; ATTRIB fPos = fragment.position; ATTRIB TC = fragment.texcoord[0]; ATTRIB Radius = fragment.texcoord[1]; ATTRIB Bias = fragment.texcoord[2]; ATTRIB Amount = fragment.texcoord[3]; PARAM nonPoT = program.env[0]; PARAM invRes = program.env[1]; PARAM dcode24 = { 1.0, 0.003921568627450980392156862745098, 0.000015259021896696421759365224689097 }; PARAM farClip = 8192.0; PARAM inv8 = 0.125; PARAM HQScale = 0.5; PARAM DefVal = 0.55; PARAM randUV = 0.25; # 0.25 = 4x4; 0.0625 = 16x16; 0.015625 = 64x64 # pre-normalized w/ other necessary math done PARAM vec1 = { 0.01262953713852306359863762957346, 0.01262953713852306359863762957346, 0.01262953713852306359863762957346 }; PARAM vec2 = { -0.02525907427704612719727525914692, -0.02525907427704612719727525914692, -0.02525907427704612719727525914692 }; PARAM vec3 = { -0.03788861141556919079591288872038, -0.03788861141556919079591288872038, 0.03788861141556919079591288872038 }; PARAM vec4 = { -0.05051814855409225439455051829384, 0.05051814855409225439455051829384, -0.05051814855409225439455051829384 }; PARAM vec5 = { -0.06314768569261531799318814786729, 0.06314768569261531799318814786729, 0.06314768569261531799318814786729 }; PARAM vec6 = { 0.07577722283113838159182577744076, -0.07577722283113838159182577744076, -0.07577722283113838159182577744076 }; PARAM vec7 = { 0.08840675996966144519046340701422, -0.08840675996966144519046340701422, 0.08840675996966144519046340701422 }; PARAM vec8 = { 0.10103629710818450878910103658768, 0.10103629710818450878910103658768, -0.10103629710818450878910103658768 }; TEMP depthEnc, depth, random, ssao, uv; TEMP radius, dist, aspect, diff, res; TEMP SampleScale, distScaled, DepthRangeScale, DepthTestSoftness, RangeIsInvalid; TEMP R0, R1, R2, R3, R4, R5, R6, R7, R8; TEMP S0, S1, S2, S3, S4, S5, S6, S7, S8; TEMP D1, D2, D3, D4; # calculate the screen texcoord in the 0.0 to 1.0 range # MUL R0, fPos, invRes; # scale by the screen non-power-of-two-adjust # MUL R0, R0, nonPoT; # scale by the screen non-power-of-two-adjust # MUL R0, TC, nonPoT; MOV uv, 0.0; MUL uv.xy, fPos, invRes; # calculate screen width/height RCP res.x, invRes.x; RCP res.y, invRes.y; # calculate aspect ratio MOV aspect.x, 1.0; MUL aspect.y, res.x, invRes.y; # load the depth render TEX depthEnc, uv, texture[0], 2D; DP3 depth, depthEnc, dcode24; # range conversions MUL depth.z, depth, farClip; # MAX depth.w, depth.z, 64.0; # RCP depth.w, depth.w; MUL_SAT R1.x, depth.z, 0.0078125; # make area smaller if distance less than 128 units MAD R1.y, depth.z, 0.001953125, 1.0; # make area bigger if distance more than 512 units MUL R1.x, R1.x, R1.y; MUL SampleScale.xyz, R1.x, Radius; RCP R1.x, SampleScale.z; MUL R1.x, farClip, R1.x; MUL DepthRangeScale, R1.x, 0.85; # convert from units into SS units RCP R1.x, depth.z; MUL SampleScale.xy, SampleScale, R1.x; MUL SampleScale.z, SampleScale.z, 0.000244140625; MUL SampleScale.xy, SampleScale, aspect; RCP R1.x, SampleScale.z; MUL DepthTestSoftness, 32.0, R1.x; # load random vector map MUL R0.xy, fPos, randUV; TEX random, R0, texture[2], 2D; MAD random, random, 2.0, -1.0; DP3 random.w, random, random; RSQ random.w, random.w; MUL random.xyz, random, random.w; ###================================================= # calculate offsets DP3 R1.w, random, vec1; MUL R1.xyz, random, R1.w; MAD R1.xyz, R1, -2.0, vec1; DP3 R2.w, random, vec2; MUL R2.xyz, random, R2.w; MAD R2.xyz, R2, -2.0, vec2; DP3 R3.w, random, vec3; MUL R3.xyz, random, R3.w; MAD R3.xyz, R3, -2.0, vec3; DP3 R4.w, random, vec4; MUL R4.xyz, random, R4.w; MAD R4.xyz, R4, -2.0, vec4; DP3 R5.w, random, vec5; MUL R5.xyz, random, R5.w; MAD R5.xyz, R5, -2.0, vec5; DP3 R6.w, random, vec6; MUL R6.xyz, random, R6.w; MAD R6.xyz, R6, -2.0, vec6; DP3 R7.w, random, vec7; MUL R7.xyz, random, R7.w; MAD R7.xyz, R7, -2.0, vec7; DP3 R8.w, random, vec8; MUL R8.xyz, random, R8.w; MAD R8.xyz, R8, -2.0, vec8; MUL S1.xyz, R1, SampleScale; MUL S2.xyz, R2, SampleScale; MUL S3.xyz, R3, SampleScale; MUL S4.xyz, R4, SampleScale; MUL S5.xyz, R5, SampleScale; MUL S6.xyz, R6, SampleScale; MUL S7.xyz, R7, SampleScale; MUL S8.xyz, R8, SampleScale; # snap texcoord to pixel center MUL S1.xy, S1, res; FLR S1.xy, S1; MUL S2.xy, S2, res; FLR S2.xy, S2; MUL S3.xy, S3, res; FLR S3.xy, S3; MUL S4.xy, S4, res; FLR S4.xy, S4; MUL S5.xy, S5, res; FLR S5.xy, S5; MUL S6.xy, S6, res; FLR S6.xy, S6; MUL S7.xy, S7, res; FLR S7.xy, S7; MUL S8.xy, S8, res; FLR S8.xy, S8; # do first sample set MAD_SAT R1.xy, S1, invRes, uv; MAD_SAT R2.xy, S2, invRes, uv; MAD_SAT R3.xy, S3, invRes, uv; MAD_SAT R4.xy, S4, invRes, uv; MAD_SAT R5.xy, S5, invRes, uv; MAD_SAT R6.xy, S6, invRes, uv; MAD_SAT R7.xy, S7, invRes, uv; MAD_SAT R8.xy, S8, invRes, uv; # sample depth texture TEX R1, R1, texture[0], 2D; TEX R2, R2, texture[0], 2D; TEX R3, R3, texture[0], 2D; TEX R4, R4, texture[0], 2D; TEX R5, R5, texture[0], 2D; TEX R6, R6, texture[0], 2D; TEX R7, R7, texture[0], 2D; TEX R8, R8, texture[0], 2D; # decode 24-bit depth DP3 D1.x, R1, dcode24; DP3 D1.y, R2, dcode24; DP3 D1.z, R3, dcode24; DP3 D1.w, R4, dcode24; DP3 D2.x, R5, dcode24; DP3 D2.y, R6, dcode24; DP3 D2.z, R7, dcode24; DP3 D2.w, R8, dcode24; ADD D1.x, D1.x, S1.z; ADD D1.y, D1.y, S2.z; ADD D1.z, D1.z, S3.z; ADD D1.w, D1.w, S4.z; ADD D2.x, D2.x, S5.z; ADD D2.y, D2.y, S6.z; ADD D2.z, D2.z, S7.z; ADD D2.w, D2.w, S8.z; # do second sample set MUL S1.xyz, S1, HQScale; MUL S2.xyz, S2, HQScale; MUL S3.xyz, S3, HQScale; MUL S4.xyz, S4, HQScale; MUL S5.xyz, S5, HQScale; MUL S6.xyz, S6, HQScale; MUL S7.xyz, S7, HQScale; MUL S8.xyz, S8, HQScale; MAD_SAT R1.xy, S1, invRes, uv; MAD_SAT R2.xy, S2, invRes, uv; MAD_SAT R3.xy, S3, invRes, uv; MAD_SAT R4.xy, S4, invRes, uv; MAD_SAT R5.xy, S5, invRes, uv; MAD_SAT R6.xy, S6, invRes, uv; MAD_SAT R7.xy, S7, invRes, uv; MAD_SAT R8.xy, S8, invRes, uv; # sample depth texture TEX R1, R1, texture[0], 2D; TEX R2, R2, texture[0], 2D; TEX R3, R3, texture[0], 2D; TEX R4, R4, texture[0], 2D; TEX R5, R5, texture[0], 2D; TEX R6, R6, texture[0], 2D; TEX R7, R7, texture[0], 2D; TEX R8, R8, texture[0], 2D; # decode 24-bit depth DP3 D3.x, R1, dcode24; DP3 D3.y, R2, dcode24; DP3 D3.z, R3, dcode24; DP3 D3.w, R4, dcode24; DP3 D4.x, R5, dcode24; DP3 D4.y, R6, dcode24; DP3 D4.z, R7, dcode24; DP3 D4.w, R8, dcode24; ADD D3.x, D3.x, S1.z; ADD D3.y, D3.y, S2.z; ADD D3.z, D3.z, S3.z; ADD D3.w, D3.w, S4.z; ADD D4.x, D4.x, S5.z; ADD D4.y, D4.y, S6.z; ADD D4.z, D4.z, S7.z; ADD D4.w, D4.w, S8.z; ###============================================= # calculate occlusion ADD dist, depth.x, -D1; MUL distScaled, dist, DepthRangeScale; ABS_SAT R1, distScaled; MOV_SAT R2, distScaled; ADD R1, R1, R2; MUL RangeIsInvalid, R1, 0.5; MUL_SAT R1, -dist, DepthTestSoftness; LRP ssao, RangeIsInvalid, DefVal, R1; ADD dist, depth.x, -D2; MUL distScaled, dist, DepthRangeScale; ABS_SAT R1, distScaled; MOV_SAT R2, distScaled; ADD R1, R1, R2; MUL RangeIsInvalid, R1, 0.5; MUL_SAT R1, -dist, DepthTestSoftness; LRP R1, RangeIsInvalid, DefVal, R1; ADD ssao, ssao, R1; ADD dist, depth.x, -D3; MUL distScaled, dist, DepthRangeScale; ABS_SAT R1, distScaled; MOV_SAT R2, distScaled; ADD R1, R1, R2; MUL RangeIsInvalid, R1, 0.5; MUL_SAT R1, -dist, DepthTestSoftness; LRP R1, RangeIsInvalid, DefVal, R1; ADD ssao, ssao, R1; ADD dist, depth.x, -D4; MUL distScaled, dist, DepthRangeScale; ABS_SAT R1, distScaled; MOV_SAT R2, distScaled; ADD R1, R1, R2; MUL RangeIsInvalid, R1, 0.5; MUL_SAT R1, -dist, DepthTestSoftness; LRP R1, RangeIsInvalid, DefVal, R1; ADD ssao, ssao, R1; ###================================================= DP4 ssao.x, ssao, inv8; ADD ssao.x, ssao, -Bias; MOV oColor, depthEnc.xxyy; LRP_SAT oColor.x, Amount, ssao.x, 0.9; END

Sikkpins SSAO used a vile hack to get the depth image aside from that it works quite ok but breaks when colliding with some shader effects like the heathaze and skybox shaders. The effect caused outlines to be drawn on alpha materials so whenever there was one of said effects you could see the outlined box. It looked quite ghastly whenever that happened, but in the places where it worked it looked bloody amazing

Checked again, and small whoops it is indeed GL_BACK not GL_NONE GL_NONE was for FBO rendering but the depthbuffer copy needs GL_BACK. Should actually have thrown an exception there but may not have been fatal so it passed anyway, probably a good idea with a GL_CheckError in that function just to make sure.

Sounds good, yeah that one had me a bit baffled. And thanks but i could not have completed it without someone like you who could do the shader part for testing . So now onto hacking apart sikkmods SSAO kinda wish sikkpin was here, i think he would love getting his hands dirty now that the code for getting the depthimage is complete.