One thing in particular I noticed wrong (and I'm relatively sure that's not how it's supposed to be) is that some lit areas have hard edges. And many light cones with hard edges kinda overlap and it looks very "artsy", 2D art like, if you know what I mean. There is no fallof. This is very apparent in the Presidential Palace in the upper elevator room.
Without some pictures and save game is hard to know what are you talking about. 😀 Can you elaborate?
No problem. See these screenshots (same scene once with nightvision and once without). Also attached is the quicksave that will take you right there.
The attachment SplinterCell 2017-01-30 20-09-53-92.jpg is no longer available
The attachment SplinterCell 2017-01-30 20-09-57-28.jpg is no longer available
TomArrow wrote:No problem. See these screenshots (same scene once with nightvision and once without). Also attached is the quicksave that will […] Show full quote
daniel_u wrote:
TomArrow wrote:
One thing in particular I noticed wrong (and I'm relatively sure that's not how it's supposed to be) is that some lit areas have hard edges. And many light cones with hard edges kinda overlap and it looks very "artsy", 2D art like, if you know what I mean. There is no fallof. This is very apparent in the Presidential Palace in the upper elevator room.
Without some pictures and save game is hard to know what are you talking about. 😀 Can you elaborate?
No problem. See these screenshots (same scene once with nightvision and once without). Also attached is the quicksave that will take you right there.
SplinterCell 2017-01-30 20-09-53-92.jpg
SplinterCell 2017-01-30 20-09-57-28.jpg
Thanks. I will test using my trusty Geforce 4 Ti.
As a side note i've also seen something that didnt looked right when switching to night vision, same level. Might be related to light sources only. Never got the chance to test this but now with your post i really want to.
Thanks. I will test using my trusty Geforce 4 Ti.
As a side note i've also seen something that didnt looked right when switching to night vision, same level. Might be related to light sources only. Never got the chance to test this but now with your post i really want to.
Thanks.
My pleasure. Nightvision looked okay to me throughout the game, can't complain. My system is an i7-3930k with a GTX 760 and Windows 7 64 bit.
Thanks. I will test using my trusty Geforce 4 Ti.
As a side note i've also seen something that didnt looked right when switching to night vision, same level. Might be related to light sources only. Never got the chance to test this but now with your post i really want to.
Thanks.
My pleasure. Nightvision looked okay to me throughout the game, can't complain. My system is an i7-3930k with a GTX 760 and Windows 7 64 bit.
TomArrow wrote:So weird. Phong shading was active. I turned it off and it's better, thanks. But my shadows are not nearly as soft as yours... h […] Show full quote
So weird. Phong shading was active. I turned it off and it's better, thanks. But my shadows are not nearly as soft as yours... have a look.
SplinterCell 2017-01-31 22-13-16-16.jpg
They are kinda weirdly angled, like from very bad upsampling.
Here are my dgVoodoo settings:
Screenshot 2017-01-31 22.13.44.png
Screenshot 2017-01-31 22.13.42.png
Just use this. It increseas the resolution when using night vision(configurable in the ini file) https://github.com/ThirteenAG/WidescreenFixes … releases/tag/sc
Be careful to still use dgvoodoo's d3d8.dll. Also see my first post about the settings to use in SC or Scpt. Is right there.😀
I promised, so rendering a night-vision frame in Splinter Cell is the following:
In the first pass, only the light maps of the 3D world are rendered
1 vs.1.0 ; o** registers are output registers 2 3 dp4 oPos.x, v0, c2 4 dp4 oPos.y, v0, c3 5 dp4 oPos.z, v0, c4 6 dp4 oPos.w, v0, c5 ; v0: vertex position, c2-c5 are the columns or rows of the world*camera*projection matrix, 7 ; so this is a transformation 8 mov r0, v0 9 mov oD0, c1 ; constant color (modulating factor), going into the pixel pipeline 10 mov oT0, v3 11 mov oT1, v4 12 mov oT2, v3 13 mov oT3, v3 ; texture coordinates coming from the vertex, only T0 and T1 are used in the pixel pipeline 14 mov oFog.x, c0 ; some fog, but fogging is disabled here
(I think the 'lighter' rendering is controlled by the c1 constant. OK, it's not ambient lighting, because it's not an additive component, but instead it controls the intensity of the light maps drawn in the 1st pass.)
Pixel pipeline is fixed function:
1r0 = texture0 * diffuse ; r0 = lightmap0 * vertex color0 (coming through oD0 from the vertex shader) 2r0 = texture1 * r0 ; r0 = r0 * lightmap1, r0 is the final color output
Texture0 is a 256*512 DXT1, so I'm not sure if it's a lightmap. Texture1 is smaller, 64*16, it seems to be that.
Pass2:
textures and some surrounding objects are drawn, with a little different vertex shader
1r0 = texture0 * diffuse 2r0 = r0 * dstcolor ; this line is done in the alpha blender, dstcolor is the previously drawn light maps
Pass3: The thresholded image for light aura
Vertex pipeline is fixed function and not interesting, the previously drawn image is drawn further (scaled down) to a 256x256 texture
Pixel shader
1ps 1.0 2tex t0 ; sample image texture 3dp3 r0, t0, c4 ; dot (r0.rgb, c4.rgb) - seems to be converting to grayscale, c4 = (0.200000003, 0.393000007, 0.0732999966, 0), 4 ; so it also seems to contain a darkening factor (darkening the grayscale a little) 5cnd r0, r0.a, c6, c5 ; This is the thresholding: r0 = (r0.a > 0.5) ? c6 : c5 (previous result of the dot is replicated to all components of r0) 6 ; so if the grayscale is above 0.5 then the output color is c6 = (0.69, 1.0, 0.69, 0) (greenish), otherwise it's c5 = (0, 0, 0, 0) 7
After that, a few passes happens where the modulated and dilated versions of the threshold image is drawn onto each other with additive blending.
Vertex pipeline is fixed function, vertex data contains a color and texture coordinates for drawing the quads.
I couldn't see the vertex data when debugged because they were placed into a hw vertex buffer, but the intensity factor for modulation is coming from the vertex color (which is maybe incremented for each subsequent passes, but I guess it's not) and dilating is solved by using texture coordinates that are addressing slightly more and more into a sub-rectangle of interior of the threshold image (it's also a guess).
So, after the first blending pass the image is
I counted 9 repetative passes, after the 9th the image is
pixel pipeline
1r0 = texture0 * vertex color 2r0 = r0 + dstcolor ; dst color is the result of the previous pass (this line is done by the alpha blender)
This drawing process is repeated further: the previously got blended image becomes the source and it's drawn into a half size (128x128) texture this time, 9 passes again:
Then, as you may guessed, this final 128x128 image, as the new source, is drawn into a 64x64 texture, 9 passes again (the picture here is distorted because the output window reached it smallest allowed size, couldn't be 64x64, so it's stretched, don't let it mislead you)
This process is done again, 64x64 -> 32x32
So, at this point we have four textures generated from the threshold image: 256x256, 128x128, 64x64 and 32x32
These are simply stretched to 256x256 and added together to produce the final light aura image used for rendering the noised nightvision scene:
Final image in backbuffer:
I figured out the 9-passes mystery, I think. It's a box blur. Box-blurring the image gives exactly the same result. This means: Picture intensity is divided by 9, then this low intensity picture is transposed to 9 different locations, one of which is simply the original location, and the other ones are basically on the 1-pixel boundaries of the original location. Thus: 1 bright pixel becomes a small 1/9 intensity square of 9 pixels. Two bright pixels create two additively overlapping squares, and so on. A big area of bright pixels creates in effect ... a bright area of pixels.
Uh, I realize the 1/9th is just a wild guess, but it's somewhere in the ballpark anyhow. Probably would make more sense if I tried to figure it out in a [0 ... 1] sense than with 255 variations.
Anyhow, pretty inventive, and looks good too. Thanks, I hope that answers all my questions. If not, I'll come back to annoy you more.
Oh yeah, one more question: Is the intensity in the final stacking of the different-sized textures the same for all components? I have to say I'd be surprised if it were.
TomArrow wrote:Haaa! Fuckin amazing, mate. […] Show full quote
Haaa! Fuckin amazing, mate.
I figured out the 9-passes mystery, I think. It's a box blur. Box-blurring the image gives exactly the same result. This means: Picture intensity is divided by 9, then this low intensity picture is transposed to 9 different locations, one of which is simply the original location, and the other ones are basically on the 1-pixel boundaries of the original location. Thus: 1 bright pixel becomes a small 1/9 intensity square of 9 pixels. Two bright pixels create two additively overlapping squares, and so on. A big area of bright pixels creates in effect ... a bright area of pixels.
Uh, I realize the 1/9th is just a wild guess, but it's somewhere in the ballpark anyhow. Probably would make more sense if I tried to figure it out in a [0 ... 1] sense than with 255 variations.
Anyhow, pretty inventive, and looks good too. Thanks, I hope that answers all my questions. If not, I'll come back to annoy you more.
Oh yeah, one more question: Is the intensity in the final stacking of the different-sized textures the same for all components? I have to say I'd be surprised if it were.
Uhh.... indeed, box blurring, not dilating... Offseting the images into 8 different neighbor positions... 😎 I should have realize it. 😀
Intensity: no, I don't think it they are the same. The starter image coming from the thresholding has pixels of (.69, 1.0, .69) and those are modulated and added together multiple times, components are clamped to [0..1].
The most bright parts of the image turns into pure white because of that.
Now with all this knwoledge how hard it can be to add some depth of field effect to the Night Vision?
Xbox original title has this, meaning you cant see things too well at certain distance(far away things are blurry). 😀
I know, i know modding stuff, but this seems to be a perfect opportunity to do some thing with all this knowledge. 😁
daniel_u wrote:Now with all this knwoledge how hard it can be to add some depth of field effect to the Night Vision?
Xbox original title has th […] Show full quote
Now with all this knwoledge how hard it can be to add some depth of field effect to the Night Vision?
Xbox original title has this, meaning you cant see things too well at certain distance(far away things are blurry). 😀
I know, i know modding stuff, but this seems to be a perfect opportunity to do some thing with all this knowledge. 😁
I don't know much about modding and personally I don't miss that DOF, but here's an idea that would minimize the work on Dege's part. Basically, all that would be needed would be to deactivate the last pass that multiplies the noise into the picture.
Then (from how I understand it, haven't personally tried it) you could use Reshade to create the DoF and also to do the noise pass afterwards also with Reshade. To make sure it only gets triggered during night vision, you could implement some kind of "trigger pixel" with a concrete RGB value that will set this off (you could detect this pixel in Reshade I think). If Reshade allows more than that, maybe you could even set some kind of memory value instead of the pixel, as that is more elegant.
Pure conjecture, of course. Never worked with Reshade. In any case, the only reason I would personally want this effect would be for the sake of "authenticity", but then the real problem is that you can only guesstimate the exact algorithm to get it to lookalike as on the Xbox. I don't think there is any reasonable way to debug the Xbox game.
Oh and nevermind all the more subtle lighting effects and color correction etc., that the PC seems to miss (like the bloom in the Training mission).
Anyhow, that's how I would try to do it I guess. You'd have to find a solution for the zoomed-in versions of the rifle and ... goggles? ... too.
TomArrow wrote:I don't know much about modding and personally I don't miss that DOF, but here's an idea that would minimize the work on Dege's […] Show full quote
daniel_u wrote:Now with all this knwoledge how hard it can be to add some depth of field effect to the Night Vision?
Xbox original title has th […] Show full quote
Now with all this knwoledge how hard it can be to add some depth of field effect to the Night Vision?
Xbox original title has this, meaning you cant see things too well at certain distance(far away things are blurry). 😀
I know, i know modding stuff, but this seems to be a perfect opportunity to do some thing with all this knowledge. 😁
I don't know much about modding and personally I don't miss that DOF, but here's an idea that would minimize the work on Dege's part. Basically, all that would be needed would be to deactivate the last pass that multiplies the noise into the picture.
Then (from how I understand it, haven't personally tried it) you could use Reshade to create the DoF and also to do the noise pass afterwards also with Reshade. To make sure it only gets triggered during night vision, you could implement some kind of "trigger pixel" with a concrete RGB value that will set this off (you could detect this pixel in Reshade I think). If Reshade allows more than that, maybe you could even set some kind of memory value instead of the pixel, as that is more elegant.
Pure conjecture, of course. Never worked with Reshade. In any case, the only reason I would personally want this effect would be for the sake of "authenticity", but then the real problem is that you can only guesstimate the exact algorithm to get it to lookalike as on the Xbox. I don't think there is any reasonable way to debug the Xbox game.
Oh and nevermind all the more subtle lighting effects and color correction etc., that the PC seems to miss (like the bloom in the Training mission).
Anyhow, that's how I would try to do it I guess. You'd have to find a solution for the zoomed-in versions of the rifle and ... goggles? ... too.
Yes sir, it's hard for the untrained eye to see all differences. I also learned that Dege does emulation which is not quite the same. But dont get me wrong a normal person playing the game will never notice.
The color problem(SCPT experience is reduced with this issue) i noticed but i didnt quite manged to tell the difference between the PC /original PC version and Xbox regarding the bloom.
I've seen this first in SCPT looking at the windows in the first level near the shore. I knew there was something different there.
I will do some more comparisons now that i know what to look for/at. 😀 -
Regarding the dof efect, it shoud have a switch or something. Not every person likes this. 😀
"Depth map" based effects are hit and miss through Reshade3. I could not get DOF and Ambient Occlusion (MXAO) to work properly in Splinter Cell through Reshade3. Apparently, Reshade3 is having difficulty accessing the "depth map". I also couldn't get Nvidia's built-in HBAO through profile hack to work for this game. It seems like "depth map access" needs to be fixed through dgVoodoo.
Generally speaking, I would prefer built-in features within dgVoodoo to using Reshade3. dgVoodoo's MSAA is much faster and much better looking when compared to the anti-aliasing methods in Reshade3 (FXAA, MSAA, SMAA). When it works, Nvidia HBAO through profile hacking and dgVoodoo is much much faster and much better looking than MXAO through Reshade3.
Nvidia Gameworks has a feature called "Nvidia DOF (nvdof)", which looks much better than the standard DOF (which is just a circular/oval blur, with a clear center). Comparison is below. It is also supposed to be very fast since it uses hardware/driver/DX11 features.
Another interesting thing about Nvidia Gameworks is that, it works on all DX11 cards (nvidia, amd radeon, intel etc.). No matter what, it will certainly be much faster than Reshade3 on all DX11 graphics cards.
Either way, if Dege could come up with a way to implement DOF (either Nvidia's Hadware/driver DOF, or his own implementation) into dgVoodoo control panel, it would be nice.
Last edited by CoolGamer on 2017-02-07, 18:15. Edited 2 times in total.
Nvidia Gameworks has a feature called "Nvidia DOF (nvdof)", which looks much better than the standard DOF (which is just a circular/oval blur, with a clear center). Comparison is below. It is also supposed to be very fast since it uses hardware/driver/DX11 features.
I don't understand. That right picture (titled nvdof) simply shows some weird bloom effect plus lens flare, not DOF. I'd say this looks about the equivalent of getting water on the lens.
Nvidia Gameworks has a feature called "Nvidia DOF (nvdof)", which looks much better than the standard DOF (which is just a circular/oval blur, with a clear center). Comparison is below. It is also supposed to be very fast since it uses hardware/driver/DX11 features.
I don't understand. That right picture (titled nvdof) simply shows some weird bloom effect plus lens flare, not DOF. I'd say this looks about the equivalent of getting water on the lens.
DOF is a camera effect. In that example they show all DOF related features of Gameworks including camera lens flare. Fear not, it is supposed to be fully configurable.
Such additional rendering passes could only be done "inside dgVoodoo" (if we stick to D3D11 rendering techniques).
External post processors can only see the final frame image, including 2D HUD.
While I don't want to include any game-specific thing into core dgVoodoo, for some time I'm thinking about an internal hooking layer,
through which additional logic could be organized into separate modules (dlls).
The rendering part to be hooked could be identified by some uniqe renderstates and some extra rendering could be added in those case.
UCyborg mentioned Mafia Water Shader Mod, that one does the same (with a custom D3D8.dll for API hooking).
I think Reshade uses some kind of 2D mask to not affect the UI, at least that's as I understand it. How well that works likely depends on the implementation.
Dege wrote:This made me ponder. […] Show full quote
This made me ponder.
Such additional rendering passes could only be done "inside dgVoodoo" (if we stick to D3D11 rendering techniques).
External post processors can only see the final frame image, including 2D HUD.
While I don't want to include any game-specific thing into core dgVoodoo, for some time I'm thinking about an internal hooking layer,
through which additional logic could be organized into separate modules (dlls).
The rendering part to be hooked could be identified by some uniqe renderstates and some extra rendering could be added in those case.
UCyborg mentioned Mafia Water Shader Mod, that one does the same (with a custom D3D8.dll for API hooking).
I should whip up a proof-of-concept.
Yup, i remember you saying that for nvidia cards there is hack that creates a smooth shadow for Sam in SCPT. I think it's good ideea to use that for your example/move into the other dll.
You can then release the source code for hooking or whatever, an example to help other tap into whatever layer it's needed.(adding dgVoodoo water mark or some simple stuff). Maybe some people will be interested.
I have the feeling this will not be enough. It never is. Maybe you'll need to expose some other things from the core dll. Make yourself an API to be called if you go that route.
Better i shut up now, i dont know nothing about game programming. 😀
PS:
I was dreaming about a core dll and specific per game dll for a long time. 😉
Dege wrote:This made me ponder. […] Show full quote
This made me ponder.
Such additional rendering passes could only be done "inside dgVoodoo" (if we stick to D3D11 rendering techniques).
External post processors can only see the final frame image, including 2D HUD.
While I don't want to include any game-specific thing into core dgVoodoo, for some time I'm thinking about an internal hooking layer,
through which additional logic could be organized into separate modules (dlls).
The rendering part to be hooked could be identified by some uniqe renderstates and some extra rendering could be added in those case.
UCyborg mentioned Mafia Water Shader Mod, that one does the same (with a custom D3D8.dll for API hooking).
I should whip up a proof-of-concept.
Dege,
Did you have the chance to look into Nvidia Gameworks source code/examples? Can Gameworks effects (HBAO, DOF, etc.) be used in dgVoodoo's upcoming internal hooking layer through separate modules (dlls)?
I noticed something strange in Pandora Tomorrow. It is a small white cross flashing in the dead middle of the screen. I am not sure, but I think it happens more often when I use the mouse. Something Unreal-Engine related, perhaps. I can't show it to you, because it doesn't appear on my ShadowPlay recordings. It also doesn't appear when I use a different d3d8.dll from the Widescreen Patches pack. As for the looks ... it's just two perfect white lines crossed, static, not changing with motion or anything. If you need proof, I'll try and record it with my digital camera.
