dgVoodoo Splinter Cell Games

General information and assistance with dgVoodoo.

dgVoodoo Splinter Cell Games

Postby daniel_u » 2017-1-10 @ 15:16

Bugs related to Splinter Cell games using DgVooDoo here.
Last edited by daniel_u on 2017-1-10 @ 15:30, edited 1 time in total.
User avatar
daniel_u
Member
 
Posts: 191
Joined: 2015-1-11 @ 12:19

Re: dgVoodoo Splinter Cell Games

Postby daniel_u » 2017-1-10 @ 15:19

For SC 1 (640x 480 no MSAA or reslution forcing) we have:
1.Shiny texture bug(it so appears that it behaves just a little bit different than in WIP 34. Might be me)
Bug
Image
Normal
Image

2.Z-Fighting?(notice the CIA logo on the floor) Resolution dependent. Higher res(ingame), through Dgvoodoo(no res forcing in dgvoodoo) doesnt show this issue. 640x480 seems to be troublesome.
DgVooDoo
Image
GF4
Image

--to be updated

Game bugs:
1.Shadows and light appear/disappear based on mouse movement or distance.
2.Missing shadows compared to the XBOX version.

Advices:
1.Play game without resoultion forcing or MSAA to avoid artifacts.(ex: water oil rafinery, begining of CIA level, etc )
2.To force resolution use games config.
3.Use 4800 preset for classic light(2.54)
Image

Use DgVoodoo-5700 Ultra for soft light
Image

Notes:
1.Game is dependent on the monitor refresh rate. 30 fps is the original. Going higher will cause some elements to 'move' too fast(light beams)

For SC 2 we have:
1.Color of the light is wrong.(better get used to it cause will stay like this for a long time. Dege informed us that this is not a priority)
(not my picture)
Image
2.Z-Fighting
3.Missing Bloom effect(might be wrong, maybe a port issue. Xbox has it for sure)
4. Big crosshair in the middle of the screen, flashing. Focus lost?(i 'm sure i was fullscreen)
--to be updated

Game Bugs:
1.Heat haze is resolution dependent.
Here's how it looks on 640x480(distorted image of the wood in the background). On higher res the effect will be less/small visible. The higher the res the less/small intense the effect will be. The heat haze on higher res will be at the bottom where the fire can barely be visible.
Image
2.Flickering of the corona of lights.(exterior button lights of elevator/lift, candles in the first level, etc)
Image
Image
3.Shadows and light appear/disappear based on mouse movement or distance.
--to be updated

Notes:
1.Game is dependent on the monitor refresh rate. 30 fps is the original. Going higher will cause some elements to 'move' too fast(light beams)

Big Note: I'm using Nvidia card

Recommended version(imho) for SC 1 & 2 : 2.54 .
Last edited by daniel_u on 2017-6-17 @ 13:05, edited 41 times in total.
User avatar
daniel_u
Member
 
Posts: 191
Joined: 2015-1-11 @ 12:19

Re: dgVoodoo Splinter Cell Games

Postby TomArrow » 2017-1-19 @ 15:01

Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom
TomArrow
Newbie
 
Posts: 20
Joined: 2017-1-19 @ 13:13

Re: dgVoodoo Splinter Cell Games

Postby daniel_u » 2017-1-19 @ 16:12

TomArrow wrote:Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom


Hi,
I dont have info on the algo but i can add that the PC version is a bit different than the xbox ,one .:)
The xbox version also has DOF, meaning you cant see too much at greater distances.

There is someting related to night vision in SC 2(might be similar to SC1)

https://thirteenag.github.io/wfp#splintercell

the settings file has this line: PostProcessFixedScale = 1 // Game uses 512 by default. Increasing the value makes night vision mode render in higher resolution. If set to 1, ResX will be used instead.

You can check the source code to see what the variables does/affect.
User avatar
daniel_u
Member
 
Posts: 191
Joined: 2015-1-11 @ 12:19

Re: dgVoodoo Splinter Cell Games

Postby TomArrow » 2017-1-19 @ 18:09

daniel_u wrote:
TomArrow wrote:Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom


Hi,
I dont have info on the algo but i can add that the PC version is a bit different than the xbox ,one .:)
The xbox version also has DOF, meaning you cant see too much at greater distances.

There is someting related to night vision in SC 2(might be similar to SC1)

https://thirteenag.github.io/wfp#splintercell

the settings file has this line: PostProcessFixedScale = 1 // Game uses 512 by default. Increasing the value makes night vision mode render in higher resolution. If set to 1, ResX will be used instead.

You can check the source code to see what the variables does/affect.


Heya, thanks for the tip. Unfortunately, the code only uses this value to inject it into memory, probably altering a variable in the algorithm, so it doesn't expose the algorithm itself.

If the algorithm is DirectX-based, my naive thinking would suggest that it could be 'grabbed' with something similar to a 3D ripper. That is, the instructions could be seen. But that would probably be a pain in the ass to filter out the correct ones from the ones that are unrelated, depending on how the data is arranged.

But I'm a newbie either way. I figured I'd ask here because someone might know a simple answer that may take me weeks to figure out.

Oh and I'm totally fine with the PC version. Xbox would be way too much work to figure out is my best guess.
TomArrow
Newbie
 
Posts: 20
Joined: 2017-1-19 @ 13:13

Re: dgVoodoo Splinter Cell Games

Postby daniel_u » 2017-1-19 @ 18:41

TomArrow wrote:
daniel_u wrote:
TomArrow wrote:Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom


Hi,
I dont have info on the algo but i can add that the PC version is a bit different than the xbox ,one .:)
The xbox version also has DOF, meaning you cant see too much at greater distances.

There is someting related to night vision in SC 2(might be similar to SC1)

https://thirteenag.github.io/wfp#splintercell

the settings file has this line: PostProcessFixedScale = 1 // Game uses 512 by default. Increasing the value makes night vision mode render in higher resolution. If set to 1, ResX will be used instead.

You can check the source code to see what the variables does/affect.


Heya, thanks for the tip. Unfortunately, the code only uses this value to inject it into memory, probably altering a variable in the algorithm, so it doesn't expose the algorithm itself.

If the algorithm is DirectX-based, my naive thinking would suggest that it could be 'grabbed' with something similar to a 3D ripper. That is, the instructions could be seen. But that would probably be a pain in the ass to filter out the correct ones from the ones that are unrelated, depending on how the data is arranged.

But I'm a newbie either way. I figured I'd ask here because someone might know a simple answer that may take me weeks to figure out.

Oh and I'm totally fine with the PC version. Xbox would be way too much work to figure out is my best guess.


There is a program called 3d-Analyze that has many video options including dumping the pixel and vertex shaders. Might help.
User avatar
daniel_u
Member
 
Posts: 191
Joined: 2015-1-11 @ 12:19

Re: dgVoodoo Splinter Cell Games

Postby Dege » 2017-1-19 @ 20:21

TomArrow wrote:Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom


Hi Tom,

well, I think the algorhytm could be reverse engineered.
I did tons of debugging on SC 1/2 when working fixing shadow buffers and rendering bugs related to those games. Millions of shaders to check out, etc.
I'm not sure (because I didn't specifically debugged night vision) but it's probably solved by a post process shader at the end of the frame rendering.
Since I can debug the process of the frame rendering at polygon level (I mean, Draw-call level), and the debug version of dgVoodoo disassembles all of the game shaders, I think I could figure it out what's going there.
My scruple is, is publicly reverse engineering a propietary game legal?
Dege
Oldbie
 
Posts: 928
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo Splinter Cell Games

Postby TomArrow » 2017-1-20 @ 02:07

Dege wrote:
TomArrow wrote:Hello Dege and others,

I already posted this comment in another thread, but was advised to do so here.

First off thanks a million for the work you have done. I have been wanting to replay SC1 for forever. Now I have the ability.

I have a question that is not related to your software directly and maybe someone else can help out too.

I am thinking about a video project in Splinter Cell style and since I am a little nitpicker, I was wondering if it was possible to get information about the exact algorithm used for creating the night vision effect in Splinter Cell 1. It's probably some kind of simple ambient light shader + glow + wiggling noise texture overlay but it'd be great to have the exact algorithm with the exact numbers etc, to recreate it "perfectly".

Tried finding it in the Echelon.u files, but I am a newbie and I have no idea whether such a thing would even be done in native code or with shaders or with Unreal Scripts or whatever. So any input would be appreciated.

Best regards,
Tom


Hi Tom,

well, I think the algorhytm could be reverse engineered.
I did tons of debugging on SC 1/2 when working fixing shadow buffers and rendering bugs related to those games. Millions of shaders to check out, etc.
I'm not sure (because I didn't specifically debugged night vision) but it's probably solved by a post process shader at the end of the frame rendering.
Since I can debug the process of the frame rendering at polygon level (I mean, Draw-call level), and the debug version of dgVoodoo disassembles all of the game shaders, I think I could figure it out what's going there.
My scruple is, is publicly reverse engineering a propietary game legal?


Hi Dege,

I would be very grateful if you did that, but I am no lawyer, so I have no idea about that. All I can say is you could send it to me personally and I would be fine keeping it to myself. Also, it's imo hardly a very sophisticated algorithm that would qualify as some kind of intellectual property. As I said, I am not interested in it because I am unable to come up with something that looks like it, but because I want the exact thing, for shits and giggles. Either way, it's your call. I don't want to get you into trouble.
TomArrow
Newbie
 
Posts: 20
Joined: 2017-1-19 @ 13:13

Re: dgVoodoo Splinter Cell Games

Postby Dege » 2017-1-20 @ 15:38

OK, after all I did it in the other thread when debugged light beams...

So, look at this scene, normally without NightVision:

Image

The steps of NightVision rendering is:

1. At first, the scene seems to be rendered as normally, but with some ambient lighting

Image

2. You can see 3 light emitter objects here: Moon and 2 lamps. Their lights are rendered into a smaller texture

Image

3. The image of those lights are blurred and dilated in a more step process (e.g. blurring the texture by drawing into a half a size texture, then blending this texture (back) onto the original one), this will serve as the aura of the light sources.
Step 2 and 3 are not NightVision specific because you have light aura normally as well, but their extent are larger in NightVision.

Image

4. Finally the game does the postprocess with 3 textures, to get the final image

texture 0 - the rendered scene (step 1)
texture 1 - a 128x128 texture, must be containing the 2D noise as an image (which must have more than one frames for animation)
texture 2 - 256x256 texture to which the light aura was rendered

The shader used for drawing a screen quad (with my comments):

Code: Select all
 ps.1.1

     def     c4, 0.300000, 0.590000, 0.110000, 0.000000         ; coefficients for converting to grayscale (r,g,b weights)
     def     c5, 0.900000, 1.000000, 0.900000, 0.000000         ; coefficients for domination of 'green'
     tex     t0                                                                       
     tex     t1
     tex     t2                                                 ; sample textures
     add     r0, t0, t2                                         ; r0 = rendered scene + light aura (additive blending of light aura to the scene)
     add     r0, r0, r0                                         ; r0 = 2*(rendered scene + light aura)
     dp3     r0, r0, c4                                         ; r0 = dot(r0.rgb, c4.rgb) converting to grayscale
     mul     r0, r0, c5                                         ; r0 = bend the result toward a little greenish
     mul_x2     r0.rgb, r0, t1                                  ; result = 2 * r0 * 2dnoise texure

and then clamp the result into [0, 1].



Image
Dege
Oldbie
 
Posts: 928
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo Splinter Cell Games

Postby TomArrow » 2017-1-20 @ 16:53

Hah! Fuckin brilliant, mate. Thank you! Just what I wanted.

Only thing that surprised me is the weighting of color information for greyscale generation. Didn't expect that!

Now I told you I'm a nitpicker, so if and only if you find the patience and time, can you elaborate more on the steps that came without code examples?

Namely:

- How much ambient lighting is used? If it is a fixed value, what is it? And is it in RGB 255 255 255 mode or fractions of 1 just as the coefficients? Is it global or specific for every material? (in which case of course you don't need to list every material's value, haha)

- The smaller texture from step 2 is not the light emitter itself, if you look closely, but rather a snap of the scene rendered in 1 bit (kind of!), with a certain brightness treshold for determining whether the pixel is bright or black. The 'active' pixels have a color value of 177,254,177. Is this always the case or does it depend on variables? Is it constant or does it change over time?

- What exactly is the brightness treshold for triggering a pixel to be "bright" instead of black?

- How is the (pseudo) 1 bit representation sampled and reduced in size? Is it by creating a full-scale sample of the scene and then subsampling it or does the renderer directly sample the scene in a lower resolution? If the first is the case, the downsampling algorithm would matter (is it some kind of bilinear interpolation or just "nearest neighbor"?).

- How exactly is the aura created? I tried your remark about using a half-size version and blending it back onto the original by ADD (sampling down and back up using Bilinear), but it doesn't look the same way. (It looks too sharp and actually it seems a little like there is less detail in some areas than in the final aura you posted, see my attachment). So there must be some more nuanced process to it.
Light_Srcs-TryWithNormalAndAddedHalfSizeBlur.png
Try with Normal Version Plus Added Half-sized blurred version
Light_Srcs-TryWithNormalAndAddedHalfSizeBlur.png (21.32 KiB) Viewed 1075 times

Light_Srcs-TryWithTwoHalfSizeBlursAddedTogether.png
Try with two half-sized blur versions added together
Light_Srcs-TryWithTwoHalfSizeBlursAddedTogether.png (22.23 KiB) Viewed 1075 times


- For the noise, does it simply tile the texture over the whole image? (looks that way)

- Assuming you posted actual code from the debugging process, how come that the add-process seems to scale texture 2, but the mul_x2 process tiles texture 1?

- Is normal bilinear sampling used to upscale the aura back onto normal size?

- In the "add r0,r0,r0" line, is there some particular reason you wrote 2*(rendered scene + light aura) in the comment instead of 2*r0?

- Is some kind of preprocessing used on the noise texture after loading it from the files? (I looked at it and while it didn't seem exactly dark, I figure that the noise would be a little stronger if you just multiplied it with the picture)

That's all I can think of right now...
TomArrow
Newbie
 
Posts: 20
Joined: 2017-1-19 @ 13:13

Re: dgVoodoo Splinter Cell Games

Postby Dege » 2017-1-20 @ 18:57

TomArrow wrote:Hah! Fuckin brilliant, mate. Thank you! Just what I wanted.

Only thing that surprised me is the weighting of color information for greyscale generation. Didn't expect that!


Well, the human eyes are sensitive at different degrees to red, green and blue color, that's why it is.
It has its on studies, see e.g. 'Luma coding in video systems'.

TomArrow wrote:Now I told you I'm a nitpicker, so if and only if you find the patience and time, can you elaborate more on the steps that came without code examples?

Namely:

- How much ambient lighting is used? If it is a fixed value, what is it? And is it in RGB 255 255 255 mode or fractions of 1 just as the coefficients? Is it global or specific for every material? (in which case of course you don't need to list every material's value, haha)

For this, the vertex shader(s) the game using should be examined. Unfortunately they are way more difficult than pixel shaders but could be figured out. It's indeed possible that the exact value varies for different scenes, materials, etc.
For vertex shaders normalized [0..1] or signed normalized [-1..1] space is more convenient.
Unnormalized space would just be painful (multiplying two unnormalized values would require an explicit additional normalization, etc.).


TomArrow wrote:- The smaller texture from step 2 is not the light emitter itself, if you look closely, but rather a snap of the scene rendered in 1 bit (kind of!), with a certain brightness treshold for determining whether the pixel is bright or black. The 'active' pixels have a color value of 177,254,177. Is this always the case or does it depend on variables? Is it constant or does it change over time?

Ok, it's true. It indeed seems to be a thresholded monochrome bitmap, but
TomArrow wrote:
- What exactly is the brightness treshold for triggering a pixel to be "bright" instead of black?

I didn't checked the details on shaders.

TomArrow wrote:- How is the (pseudo) 1 bit representation sampled and reduced in size? Is it by creating a full-scale sample of the scene and then subsampling it or does the renderer directly sample the scene in a lower resolution? If the first is the case, the downsampling algorithm would matter (is it some kind of bilinear interpolation or just "nearest neighbor"?).

- How exactly is the aura created? I tried your remark about using a half-size version and blending it back onto the original by ADD (sampling down and back up using Bilinear), but it doesn't look the same way. (It looks too sharp and actually it seems a little like there is less detail in some areas than in the final aura you posted, see my attachment). So there must be some more nuanced process to it.
Light_Srcs-TryWithNormalAndAddedHalfSizeBlur.png

Light_Srcs-TryWithTwoHalfSizeBlursAddedTogether.png


Good question, the detail should be checked.

TomArrow wrote:- For the noise, does it simply tile the texture over the whole image? (looks that way)

I think it's tiled, as it's only a 128x128 compressed texture and it has fine granurality on the final image.

TomArrow wrote:- Assuming you posted actual code from the debugging process, how come that the add-process seems to scale texture 2, but the mul_x2 process tiles texture 1?

The 2 'add' intructions produces 2*(rendered scene + light aura). (2*(t0+t2))
The '_x2' modifier only means that the result (that is, r0*t1 here) has to be further multiplied by 2.

TomArrow wrote:- Is normal bilinear sampling used to upscale the aura back onto normal size?

It should be, after all the point is the blurriness.

TomArrow wrote:- In the "add r0,r0,r0" line, is there some particular reason you wrote 2*(rendered scene + light aura) in the comment instead of 2*r0?

Hurry, copypaste... it's actually only means that r0 = r0 + r0. :)

TomArrow wrote:- Is some kind of preprocessing used on the noise texture after loading it from the files? (I looked at it and while it didn't seem exactly dark, I figure that the noise would be a little stronger if you just multiplied it with the picture)

I don't know what happens with the texture until it's passed for rendering. It's a compressed one, so probably there is no any preprocessing on it.
Dege
Oldbie
 
Posts: 928
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo Splinter Cell Games

Postby TomArrow » 2017-1-20 @ 19:16

Dege wrote:Well, the human eyes are sensitive at different degrees to red, green and blue color, that's why it is.
It has its on studies, see e.g. 'Luma coding in video systems'.

That's true, but I don't think that this matters significantly when we are talking about a simulated night vision mode for a video game which is already unrealistic due to the ambient light feature. ;) Besides, in black=and=white photography many different color filters are used depending on the desired effect and I have yet to hear someone call such a picture unrealistic. I mean, how can a black-and-white picture be realistic in the first place?

Dege wrote:For vertex shaders normalized [0..1] or signed normalized [-1..1] space is more convenient.
Unnormalized space would just be painful (multiplying two unnormalized values would require an explicit additional normalization, etc.).

I don't understand. Shouldn't ambient light not basically be just a kind of "pad" that can be universally applied to the calculated lightmap/shadowmap/whatever level? What do matrices and vertices have to do with it? (I have to admit my 3D knowledge is rather rusty)

Dege wrote:Ok, it's true. It indeed seems to be a thresholded monochrome bitmap, but
TomArrow wrote:- What exactly is the brightness treshold for triggering a pixel to be "bright" instead of black?

I didn't checked the details on shaders.

Are you sure it's a shader? This seems like an obvious post-processing step to me. Or are they the same?

Dege wrote:
TomArrow wrote:- How is the (pseudo) 1 bit representation sampled and reduced in size? Is it by creating a full-scale sample of the scene and then subsampling it or does the renderer directly sample the scene in a lower resolution? If the first is the case, the downsampling algorithm would matter (is it some kind of bilinear interpolation or just "nearest neighbor"?).

- How exactly is the aura created? I tried your remark about using a half-size version and blending it back onto the original by ADD (sampling down and back up using Bilinear), but it doesn't look the same way. (It looks too sharp and actually it seems a little like there is less detail in some areas than in the final aura you posted, see my attachment). So there must be some more nuanced process to it.
Light_Srcs-TryWithNormalAndAddedHalfSizeBlur.png
Light_Srcs-TryWithTwoHalfSizeBlursAddedTogether.png

Good question, the detail should be checked.

Would you check on those details for me or am I asking too much?

Dege wrote:
TomArrow wrote:- Assuming you posted actual code from the debugging process, how come that the add-process seems to scale texture 2, but the mul_x2 process tiles texture 1?

The 2 'add' intructions produces 2*(rendered scene + light aura). (2*(t0+t2))
The '_x2' modifier only means that the result (that is, r0*t1 here) has to be further multiplied by 2.

Yeah I got that. My confusion lies in the fact that you said those textures are 256*whatever/128*128 pixels big. So how can you add the rendered scene (at 1024*whatever) to the 256*whatever texture with proper scaling, but get tiling with the 128*128 texture?

Dege wrote:
TomArrow wrote:- Is some kind of preprocessing used on the noise texture after loading it from the files? (I looked at it and while it didn't seem exactly dark, I figure that the noise would be a little stronger if you just multiplied it with the picture)

I don't know what happens with the texture until it's passed for rendering. It's a compressed one, so probably there is no any preprocessing on it.

Compressed you say? The original is a BMP file. Hmm.
TomArrow
Newbie
 
Posts: 20
Joined: 2017-1-19 @ 13:13

Re: dgVoodoo Splinter Cell Games

Postby Dege » 2017-1-20 @ 20:09

TomArrow wrote:That's true, but I don't think that this matters significantly when we are talking about a simulated night vision mode for a video game which is already unrealistic due to the ambient light feature. ;) Besides, in black=and=white photography many different color filters are used depending on the desired effect and I have yet to hear someone call such a picture unrealistic. I mean, how can a black-and-white picture be realistic in the first place?

Yes, you're right.
But I guess the developers just took the usual grayscale coefficients for the conversion, that's all. I use to do the same. :)

TomArrow wrote:I don't understand. Shouldn't ambient light not basically be just a kind of "pad" that can be universally applied to the calculated lightmap/shadowmap/whatever level? What do matrices and vertices have to do with it? (I have to admit my 3D knowledge is rather rusty)

No, I'm not talking about the normalized vertex (coordinate) space.
Ambient light is indeed just a plain additive component in the lighting calculations. But the lighting calculation formula as a whole is much more complex, e.g. you have to multiply the incoming light color with the material diffuse color. For those calculations it's handy to have even the color information in normalized [0..1] range, that's all what I meant. If the [0..255] range were used then a simple multiplication would leave the range (for example, 255*255 = 65025), so additional operations for 'normalizing it back' would be needed.
That's why defining constant values are more common in [0..1] range for shaders rather than [0..255].

TomArrow wrote:Are you sure it's a shader? This seems like an obvious post-processing step to me. Or are they the same?

Quite sure, thresholding pixels needs a pixel shader.

TomArrow wrote:Would you check on those details for me or am I asking too much?

I could have another look. :)
But, since I only debug a particular scene, I'm not sure if the values (like ambient) are constant in general.

TomArrow wrote:Yeah I got that. My confusion lies in the fact that you said those textures are 256*whatever/128*128 pixels big. So how can you add the rendered scene (at 1024*whatever) to the 256*whatever texture with proper scaling, but get tiling with the 128*128 texture?

It's only a matter of the properly chosen texture coordinates. Scaling the scene into 256*256 (for generating auras) won't preserve the aspect ratio but it's not a problem at all. That texture will be stretched back to the scene texture size later, when the final image is calculated.
Texture coordinates are also normalized [0..1, 0..1], but coordinates outside of that range can be used, so e.g. [0..4, 0..4] means 4x4 tiling a texture, if the texture addressing mode is set to 'wrap mode'. But these are really deep details of the rendering. :)

TomArrow wrote:Compressed you say? The original is a BMP file. Hmm.

You mean, it's stored as a BMP in the game data files?
Then SC may compress them after reading them in to save video memory.
Dege
Oldbie
 
Posts: 928
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo Splinter Cell Games

Postby TomArrow » 2017-1-21 @ 06:03

Dege wrote:
TomArrow wrote:That's true, but I don't think that this matters significantly when we are talking about a simulated night vision mode for a video game which is already unrealistic due to the ambient light feature. ;) Besides, in black=and=white photography many different color filters are used depending on the desired effect and I have yet to hear someone call such a picture unrealistic. I mean, how can a black-and-white picture be realistic in the first place?

Yes, you're right.
But I guess the developers just took the usual grayscale coefficients for the conversion, that's all. I use to do the same. :)

I see. Wasn't aware of that practice. Always thought it'd be straightforward to just average the values. And more efficient. But maybe that's not true.

Dege wrote:
TomArrow wrote:I don't understand. Shouldn't ambient light not basically be just a kind of "pad" that can be universally applied to the calculated lightmap/shadowmap/whatever level? What do matrices and vertices have to do with it? (I have to admit my 3D knowledge is rather rusty)

No, I'm not talking about the normalized vertex (coordinate) space.
Ambient light is indeed just a plain additive component in the lighting calculations. But the lighting calculation formula as a whole is much more complex, e.g. you have to multiply the incoming light color with the material diffuse color. For those calculations it's handy to have even the color information in normalized [0..1] range, that's all what I meant. If the [0..255] range were used then a simple multiplication would leave the range (for example, 255*255 = 65025), so additional operations for 'normalizing it back' would be needed.
That's why defining constant values are more common in [0..1] range for shaders rather than [0..255].

Oh! Right. Lol. For some reason I thought those numbers in brackets were vectors ... silly.
Dege wrote:
TomArrow wrote:Are you sure it's a shader? This seems like an obvious post-processing step to me. Or are they the same?

Quite sure, thresholding pixels needs a pixel shader.

But it would then be a pixel shader applied over the entire image, not individual vertices, no? (If that's possible). I just don't see why one would bother implementing such a feature by cluttering vertex rendering code with it instead of just taking it from the final image. (That's how it is done in video production too, where you obviously can't access "vertices" retroactively)
Dege wrote:
TomArrow wrote:Would you check on those details for me or am I asking too much?

I could have another look. :)
But, since I only debug a particular scene, I'm not sure if the values (like ambient) are constant in general.

That'd be great. No problem whatsoever about being sure if they are constant. I take whatever I can get, heh. Of course, if you feel super excited about comparing it to a random second scene, I won't protest.
Dege wrote:
TomArrow wrote:Yeah I got that. My confusion lies in the fact that you said those textures are 256*whatever/128*128 pixels big. So how can you add the rendered scene (at 1024*whatever) to the 256*whatever texture with proper scaling, but get tiling with the 128*128 texture?

It's only a matter of the properly chosen texture coordinates. Scaling the scene into 256*256 (for generating auras) won't preserve the aspect ratio but it's not a problem at all. That texture will be stretched back to the scene texture size later, when the final image is calculated.
Texture coordinates are also normalized [0..1, 0..1], but coordinates outside of that range can be used, so e.g. [0..4, 0..4] means 4x4 tiling a texture, if the texture addressing mode is set to 'wrap mode'. But these are really deep details of the rendering. :)

Aah! So the texture has an addressing mode set (that is invisible in the example you posted) which determines how and if it will be stretched to fit onto another texture of another size?

Dege wrote:
TomArrow wrote:Compressed you say? The original is a BMP file. Hmm.

You mean, it's stored as a BMP in the game data files?
Then SC may compress them after reading them in to save video memory.

Yup. BMPs. There are four. I converted two to PNG (for the forum upload), look:
Noise0_gauss.png
Noise0_gauss.png (27.31 KiB) Viewed 1028 times
Noise1_gauss.png
Noise1_gauss.png (27.35 KiB) Viewed 1028 times


Histogram shows a tone range between roughly 70 and 191, which would translate normalized to roughly 0.27 to 0.74. Multiplied with 2 (since mulx2) it's roughly 0.5 to 1.5. So the normal values of the image would fluctuate by 50%. Now this is a purely subjective statement, but it doesn't seem that strong to me in the final image. But then, it's a bell curve (Gauss), so maybe that's why it looks okay. Can you 'grab' one of the noise textures from the "t1" variable, to compare it to the one I posted?
TomArrow
Newbie
 
Posts: 20
Joined: 2017-1-19 @ 13:13

Re: dgVoodoo Splinter Cell Games

Postby Dege » 2017-1-23 @ 11:52

Still had no time for this one but going to have a look. :)
Dege
Oldbie
 
Posts: 928
Joined: 2003-9-04 @ 11:06

Re: dgVoodoo Splinter Cell Games

Postby TomArrow » 2017-1-23 @ 12:13

Cool bro, no hurry!
TomArrow
Newbie
 
Posts: 20
Joined: 2017-1-19 @ 13:13

Re: dgVoodoo Splinter Cell Games

Postby alien41 » 2017-1-29 @ 05:11

I would first like to thank everyone involved in this project.

I do not know if it's a bug, but compared to the XBOX version, SC 1 still has some places missing shadows and in some cases, the shadow disappears as the character approaches.

I can put some pictures if the guys want.
alien41
Newbie
 
Posts: 3
Joined: 2015-7-05 @ 16:59

Re: dgVoodoo Splinter Cell Games

Postby daniel_u » 2017-1-29 @ 12:35

alien41 wrote:I would first like to thank everyone involved in this project.

I do not know if it's a bug, but compared to the XBOX version, SC 1 still has some places missing shadows and in some cases, the shadow disappears as the character approaches.

I can put some pictures if the guys want.


Yeah, theres quite a lot of small differecens.

MIssing effects, shadows and some bugs. It would be nice if a modder would fix these but Dege only restores the original PC things.
He is not willing to add new stuff to the games, altough he added 'soft' shadow for Sam in SCPT. ;) He's a busy man not sure if there is some way to convice him to fix the game. Maybe some donations? :)
Either way i'm happy because now we can play SC1 & 2 on PC without retro hardware. Thanks Dege.

Maybe Komat is more willing to change the original programming but he is long gone.
User avatar
daniel_u
Member
 
Posts: 191
Joined: 2015-1-11 @ 12:19

Re: dgVoodoo Splinter Cell Games

Postby TomArrow » 2017-1-29 @ 18:24

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.
TomArrow
Newbie
 
Posts: 20
Joined: 2017-1-19 @ 13:13

Re: dgVoodoo Splinter Cell Games

Postby daniel_u » 2017-1-30 @ 07:40

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?
User avatar
daniel_u
Member
 
Posts: 191
Joined: 2015-1-11 @ 12:19

Next

Return to dgVoodoo General

Who is online

Users browsing this forum: No registered users and 2 guests