shadow shader

Started by
8 comments, last by kauna 9 years, 6 months ago

hello all

please don't answer me if you :

1/ doen't interest by the question;

2/ if you are not concentrating;

3/ no hazardeuos answers;

this is my opinion, is it correct :

the picture below describes a method to draw shadow in 3D space using a simple technique, if we have the P as a point light AND we have the vertices of the object as N (example = teapot) AND we have the vertices of the shadowed object as M (example = floor or plane),

if (dot(NP, NM) == -1)

the vertex M is in shadow

else

the vertex M is not in shadow

(we all know the vertices NP & NM must be normalized) & using the floor() function of HLSL because the dot() function gives us a value like -0.999999 so we down to the least integer (i mean floor(dot(NP, NM)) == -1).

Advertisement

don't forget that the angle (NP, NM) has the value 180° so dot product will be -1

You'll need some kind of a tolerance since testing == 1.0 with floats will not produce many shadowing values. I'm not sure why would you want to use just point shaped occluders.

However, I don't really see how this algorithm would work on GPU - practically, for each pixel in the viewport you'll access a list of points (in the pixel shader), and then calculate if the point occludes the pixel or not - it will be highly inefficient when the amount of points gets bigger.

A traditional shadow map or stencil shadows will be much more efficient (and they work on triangles instead of points).

Cheers!

why ""testing == 1.0 with floats will not produce many shadowing values""


why ""testing == 1.0 with floats will not produce many shadowing values""

typically with floats, you'll need to use some tolerance value because it is unlikely that the value is _exactly_ what you expect it to be. You can test this by generating randomly 2 unit vectors and doing a dot product between them - gather some statistics how many dot products produce exactly 1.0 or -1.0.

Consider your algorithm drawing a plane and performing the described point occlusion algorithm - say that for one pixel the dot product results 0.99999 which is pretty close to 1.0, but it isn't one exactly (so the pixel won't get shadowed). You'd expect that some of the pixels around it would have dot product of exacly 1.0 - but that's not the case - the exact value could be (for example) half a pixel apart, but it won't be found because the algorithm works on full pixels - even if you increase the resolution, it isn't quaranteed that even one pixel gets shadowed.

So for that reason, you'll need some tolerance value. One way of seeing it is that a single point has no dimensions, it is infinitely small, and hitting it with a ray is quite difficult - you'll need to consider something bigger, like a sphere, which is a point with a radius.

Cheers!

This technique would only work with solid objects with a convex profile, right? It seems like something as simple as a torus wouldn't shadow correctly.

[size="2"]Currently working on an open world survival RPG - For info check out my Development blog:[size="2"] ByteWrangler

can any one from you build the shader file .fx for me

You'll need some kind of a tolerance since testing == 1.0 with floats will not produce many shadowing values. I'm not sure why would you want to use just point shaped occluders.

However, I don't really see how this algorithm would work on GPU - practically, for each pixel in the viewport you'll access a list of points (in the pixel shader), and then calculate if the point occludes the pixel or not - it will be highly inefficient when the amount of points gets bigger.

A traditional shadow map or stencil shadows will be much more efficient (and they work on triangles instead of points).

Cheers!

abdellah you really should again focus on the kaunas's post. What exactly are you trying to do - do you have really some special situation that the algorith would work well for you? Generally, the idea is not good, because:

You will be checking each vertex of all the shadow recievers (or do you really have just one?) against all vertices of all possible shadow casters (or do you really have just one?). That's not really efficient and it's quite hard to achieve, because when you are drawing a certain vertex (you are in its vertex shader), you don't have information about other vertices - unless you pass them to the shader somehow.

Also a very important thing to keep in mind - a vertex will be in shadow only if it there is some vertex of the shadow caster PRECISELY on the line between the said vertex and the point light. In fact you have just a bunch of point occluders with infinitely small size (ideal points), casting shadows in infinitely thin lines on another set of infinitely small point receivers. What are the odds that you will ever get a single shadow?

Don't think about it because i am taliking too much without reaching any results.

(because i use vbNET & Managed DirectX , so the ressources , is verry low (= 0), & especially when i see the people use the C++ native & DirectX11 , so i hide from pasting my code , also, my code of HLSL, is verry logic.

Shadow map rendering is still better than the algorithm your proposed - you'll be using much less computing resources. Shadow mapping has been around for a long time already and isn't an issue for any GPU younger than 10 years.

Cheers!

This topic is closed to new replies.

Advertisement