..:: PCSX2 Forums ::..

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89

I got per-pixel lighting working properly. you need the GSdx version I've compiled though, for it to work, so I dunno if I'll release it just yet. It's a subtle difference in the overall lighting, but it's nice, I like it. Plus is has no fps hit, which is always nice

per pixel lighting? how you got the normals and light positions outta the vu? you have a screenshot?

(07-10-2013, 03:15 AM)xstyla Wrote: [ -> ]per pixel lighting? how you got the normals and light positions outta the vu? you have a screenshot?

Let me reiterate. When I say I got it working, I meant I got it working in the sense I was aiming for, which is all I can do presently. I have to get the normals through texcoord1. I can't pass normal directly to the compiler, it craps out.

I should have made myself more clear, for anyone who wasn't following it's progress. Mostly, I'm just experimenting, and learning as I go tbh.

Just a code snippet from the VS (I have the VS compiled externally now)

Code:
float4x4 wvp = mul(mul(worldMatrix, viewMatrix), projectionMatrix);

float3 worldNormal =  mul(input.n, worldMatrix);

float4 worldPosition =  mul(input.p, worldMatrix);

worldPosition = worldPosition / worldPosition.w;

output.p = mul(input.p, wvp);

output.t = input.t;

output.wp = worldPosition;

float3 directionToLight = normalize(LightPosition - worldPosition.xyz);

float diffuseIntensity = saturate( dot(directionToLight, worldNormal));

float4 diffuse = LightDiffuseColor * diffuseIntensity;

float3 reflectionVector = normalize(reflect(-directionToLight, worldNormal));

float3 directionToCamera = normalize(CameraPos - worldPosition.xyz);

float4 specular = LightSpecularColor * specularIntensity * pow(saturate(dot(reflectionVector, directionToCamera)), SpecularPower);

I'll get a few screens up in a bit, I hate upping jpegs, you can't see any semblance of detail in them, but my upload speed is like 50kb/s, i'd be there for the night uploading a single uncompressed screenshot >.< really need to update my connection speed.

Edit: Two really bad off/on comparison screens below. Sorry about the quality, (blurry jpgs), but I cba spending ages to upload uncompressed atm.

view in fullscreen

OFF: [attachment=44941] ON: [attachment=44942]

Edit2:Ugh, Looks crappy when you're viewing in via a jpg screenshot, can't see it properly at all. I'll have to upload some decent pics in a bit later.

ahuh. yeah. still looks like color correction. it's really good. but... per pixel lighting? hell no. what you talking about? hype much? you have no lighting direction and no normals on the image plane. it doesn't do lighting. if you remove the textures and retrace and calculate on bare vertex stage and polygon lighting colors you're close to getting per pixel lit polygons in the actual internal rendering pass? but THIS is just an image filter. nothing else. and those textures have massive detail. there's no point asking for more. but this is my opinion. and i have that coder tag not for fun. you say "no performance hit"?. i'm sure your doing nuts or calcute air that gets optimized away by the shader compiler. Closedeyes

You need per pixel lighting to effectively do normals, you don't need normals to do per pixel lighting. You would use the normals to calculate the light intensity at a point. i.e. it calculates the angle between the direction of the plane that the point is on, and the light source position.

per pixel lighting is calculating light for each pixel, as opposed to per vertex, which calculates it for each vertex. PPL is just usually done with normals, bump mapping etc, if you were to do it in a proper game, on an engine level, because, what kind of game developer would implement PPL, without normals. You don't need normals to implement PPL, where did you hear this rubbish. Remember, this is emulation, not a PC game, I'm working on here...

Also, you're judging it from a 500kb jpeg image..If you can do it better, then by all means, please do.

Oh, and regarding the performance hit, what kind of system are you running, 5, 10 year old stuff? No feasible hit on a modern system, unless you were doing some crazy calculations for some big scene, in a proper PC game.

edit: Here's another example of PPL, off, and on, this time zoomed in, side by side.

[attachment=44957]

edit2: Here is another comparison, again zoomed, and side by side.

[attachment=44958]

I have this error warning X3206: implicit truncation of vector type. What is this error about? Will it cause some functions to turn off?

No, that's fine, it happens because in the contrast code, I'm assigning a float, a lerp float3 value. Ignore the compiler warnings

wow fast reply, thank you thank you

I have a question, I know FXAA is a post process effect, and I don't know how a lot of these shaders work, but do you think SSAO would be possible to implement? I saw a video on YouTube with PCSX2 claiming it had SSAO in the title, with custom shaders. I didn't really see any sign of SSAO in the video but it had me thinking if it were even possible. Also because of the ICEnhancer mod for GTA IV. I know that uses a different method since the extensions are different and they're coded differently, but that mod has SSAO and I'm pretty sure it's a post process thing, I think it uses ENB. I'm sure that games would look FANTASTIC if that worked together with the color correction and bloom shaders! (Not very intense bloom at that)

Love the shaders already available though! Smile

Whoever posted that video, was either lying, or just turned on the Nvidia control panel AO, and though he had it on \o/

I already tried it a while back, here in the Tales of the Abyss screens. It was only an experiment though. There are multiple reasons why SSAO won't work properly on PCSX2 as it is currently, but I won't get into them right now.

ENB/ICEnhancer etc intercept the games' API calls, and also modify the game's own files/shaders etc during runtime. That's why ENB is done on a per-game basis. Emulation is a different breed altogether from PC games. Ask Boris himself, he won't go near emulation with a 10-foot pole Tongue

Here's an example of the exact same shaders from PCSX2Fx, that I adapted a while back for a PC game (eg: Dark Souls), but I included SSAO in this one.`

View in full screen

Off: [attachment=44979] On: [attachment=44980]

Hopefully this explains it a bit for you.

Edit: link was pointing to the wrong post >.>

Asmodean

xstyla

Asmodean

xstyla

Asmodean

nightmares

Asmodean

nightmares

TyMiles2012

Asmodean