Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Shadow Shader on transparent surface

Author
Message
Graphiboc
20
Years of Service
User Offline
Joined: 16th Jun 2006
Location:
Posted: 22nd Mar 2012 16:34
Hi verybody,
I am using the 2D Shadow Mapping shader from Evolved (the one that allows spotlight shadow mapping) and I want to achieve some kind of special effect but I don't know how to do it.
My goal is to project the shadow of an object on another one but so that only the projected shadow will be visible and not the second object itself.

For instance, let say that I have a spotlight, and a sphere on a plain. I want to project the shadow of the sphere on the plain so that the plain is fully transparent except where is the shadow of the sphere. So, when the plain will be rendered, only the shadow projected on the plain will be opaque and the rest of the plain will be transparent.

Any idea of how to perform this???
I thought of using dbSetBlendMappingOn but I didn't obtain any interesting result...

Thank you !

Please, correct my english
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 22nd Mar 2012 21:13
texture the plain with texture that has only one color. Set that color as image colorkey and set object transparency. I don't know will it work but you can try

Graphiboc
20
Years of Service
User Offline
Joined: 16th Jun 2006
Location:
Posted: 22nd Mar 2012 21:28 Edited at: 22nd Mar 2012 22:22
Thank you for your answer but it won't work because it is kind of soft shadow (blured) so I can't use a colorkey.
Is there a ghost mode that let white to be transparent and black to be opaque ?

EDIT:
I finally managed to achieve the wanted effect modifying directly the shader. I attached it, I think it's not perfect since some normal map code could be still removed, I have to analize more the code for that.
Note that you should specify set object transparency obj, 2 for it to work

Please, correct my english
MMM
17
Years of Service
User Offline
Joined: 21st Jan 2009
Location: NSW, Australia
Posted: 29th Jun 2012 08:54 Edited at: 29th Jun 2012 08:56
I'm still interested in this. It's been a few weeks since I touched on shaders (broken PC) and now I'm a little muddled up.

The attached image shows the problem I'm having with this shader example when used in the Shadow Mapping demo from Evolved. As advertised, I have a black teapot casting a shadow on a transparent plane. IGNORE THE CUBE.

The shadow is casting correctly, but the "clamp" of the projection image is messed up. I imagine this is because the "RETURN" value in the pixel shader no longer reads from the "IN" data. So how do we fix this?


The shader from first post: (remember objects using it need "set object transparency objID, 2" to work)






Quote: "it's not perfect since some normal map code could be still removed"


That's ok, I'm just interested in this one example shader you posted. More as an exploration of the original shader's expansion possibilities. Cool idea, by the way, I can see this being really useful.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 29th Jun 2012 13:10
Quote: "The shadow is casting correctly, but the "clamp" of the projection image is messed up. I imagine this is because the "RETURN" value in the pixel shader no longer reads from the "IN" data. So how do we fix this?"


Not really sure what you mean by that, but if this is based on the same demo then I believe Evolved used a masking image to hide those artefacts. Here are the relevant lines in Evolved's shader:



The present shader seems to have lost those.
MMM
17
Years of Service
User Offline
Joined: 21st Jan 2009
Location: NSW, Australia
Posted: 30th Jun 2012 13:26 Edited at: 30th Jun 2012 13:35
Quote: "The present shader seems to have lost those. "

Yup, that was it! The shadowmap only affects pixels colored by the projection image; without that image, the shadows are cast repeatedly over the entire clamp. Just needed the push to get the cogs working again. Thanks GG.



So I've gone a little further with this concept but I've run into trouble again and I'm concerned my problem is something I haven't learned about yet - so I don't know what to google.

The attached image shows what I'm trying to achieve. The floor and the teapot use Evolved's original shadowmapping shader, so forget them for now. BUT above the floor is a plane/box using a modified verson of that shader which only displays the "projection" and sends everything else (shadows) to alpha. Thus combined, the teapot casts two shadows and the two projection images multiply together. So far so good...






My problem is the shadowmap used by the transparent plane appears to delay its image-update when the position of the projection-camera is moved; as if it takes a few frames before the image updates. Does that make sense? Should I post the whole demo?

The dbpro code layout is almost unchanged from Evolved's original demo except that the transparent plane uses the "set image transparency 2" setting. And there's an extra camera - but the problem began before I started using 3 cameras, so that's not it. I'm pretty sure the problem is somewhere between the "transparency" setting in dbpro and the updated code in the shader.

Plus, you know, my first true experience with shader-alpha. Here is the modified shader so far:





Cheers.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 30th Jun 2012 16:59
Quote: "as if it takes a few frames before the image updates. Does that make sense?"


I would expect a delay of one or possibly two (because of double buffering?) frames since typically a scene has to be drawn using the most recently available camera renders and depending on when you move and render things in the cycle things can get slightly out of step. This sort of issue is usually noticeable only at low frame rates or when the cameras move a lot in one render cycle. If possible, make sure things move before you do the camera to image renders.

One way of seeing how many frames the delay is would be to pause at the end of each cycle and wait for user input such as return key etc. Then you can see exactly what is happening - especially if you move things in code carefully and print the movement to the screen.

If the delay really is more than one or two frames then yes a demo would be helpful.
MMM
17
Years of Service
User Offline
Joined: 21st Jan 2009
Location: NSW, Australia
Posted: 30th Jun 2012 19:21 Edited at: 1st Jul 2012 10:24
Quote: "when the cameras move a lot in one render cycle"

Spot on again! I think I have smoothed it down now. Cheers.


I've put together this demo and made it quite small. You'll notice a lingering problem where the shadowmap from the "ghost" camera sometimes appears clipped when its angle opposes the "solid" camera. I'm working on that but am stumped for now. I'll get back to it after some sleep.

Possibly something to do with view-matrix culling but may also be the vertex render-order being based on the wrong camera... I guess? Thoughts?


Demo attached. [deleted: see next demo attachment below]
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 1st Jul 2012 02:11
Quote: "Possibly something to do with view-matrix culling "


Culling could be an issue although I haven't tried your demo yet (it's too late tonight ).
MMM
17
Years of Service
User Offline
Joined: 21st Jan 2009
Location: NSW, Australia
Posted: 1st Jul 2012 09:11 Edited at: 1st Jul 2012 10:22
Quick note on this: with fresh eyes, I notice the GHOST shadowmap render (from CAMERA2) is being affected in real-time by the position of CAMERA1.

This should explain the clipping. I'll fix it now.



(EDIT: attached screenshot for next post)
MMM
17
Years of Service
User Offline
Joined: 21st Jan 2009
Location: NSW, Australia
Posted: 1st Jul 2012 10:21 Edited at: 1st Jul 2012 10:23
Ok, so the attached demo is a release copy. It should work as expected now. Obviously this whole system isn't very useful for most applications - but it has its uses.

I am disappointed about the speed of it. The program is as fast as the original demo UNLESS the two light-cameras are pointing at each other. As I understand it, this has always been a problem with that scenario. It's just particularly prevalent here because of the camera controls.

Does anyone know just why exactly two face-to-face cameras cause so much lag? I'm running this demo with my beefy new gfx card and still getting a 60-80% fps drop when the cameras look at each other (similar to my old gfx card).

Screenshot:


Pincho Paxton
23
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 1st Jul 2012 11:50
I might be wrong, but I was under the impression that overlayed shadows in real life don't change each other's shade....



Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 1st Jul 2012 11:56
Quote: "Does anyone know just why exactly two face-to-face cameras cause so much lag? I'm running this demo with my beefy new gfx card and still getting a 60-80% fps drop when the cameras look at each other (similar to my old gfx card)."


I've no idea either.

I get the lag when the cameras are at 90 degrees to each other as well as 180. In an extreme case the fps drops from around 930 to as low as 124. Still fast enough for most purposes but the slowdown with certain combinations is weird. I wonder whether this is a DBPro issue or something else.

At least I can confirm the symptoms this time.

There is the complicating issue of the scene changing when you move the cameras so the rendering effort varies. However it's hard to see that explaining the present symptoms but it's just possible I suppose.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 1st Jul 2012 11:59
Quote: "I might be wrong, but I was under the impression that overlayed shadows in real life don't change each other's shade...."


Only if they come from a single light source. Not if they are from different lights. Try it.
Pincho Paxton
23
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 1st Jul 2012 12:34
Quote: "Only if they come from a single light source. Not if they are from different lights. Try it. "


Oh yeah they multiply.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 1st Jul 2012 12:36
Actually, I think the light adds.
MMM
17
Years of Service
User Offline
Joined: 21st Jan 2009
Location: NSW, Australia
Posted: 1st Jul 2012 18:10
Quote: "I get the lag when the cameras are at 90 degrees to each other as well as 180. In an extreme case the fps drops from around 930 to as low as 124."



@GG - similar numbers to mine:



Forgive my non-math layman terms but this is my current understanding:


For every sync, the current camera populates a "view" matrix measuring approx 179.9 radians. This is the maximum view-angle of any camera; never extending beyond the furthest left or right peripheral. Furthermore, this "view" matrix is always populated in full, per sync, regardless of any user-settings. FOV and aspect subsequently crop the matrix for rendering to the screen but have no impact on populating it to begin with.

Essentially anything "forward" of the camera is taken into account. If you had two identical cameras, in the exact same position, with the exact same view-vector, the matrix would be combined and shared between them. Try this in the demo! Notice almost no additional lag!

But when you have multiple cameras facing different directions, the defined line between "forward" and "backward" (ie; <=179.9 radians and =>180 radians) is distorted and lag occurs for what appears to be no visual reason. Of course, the lag is because the combined "view" matrix is combining and resizing on-the-fly. And remember, it is based on radians - so the lag effect is doubled for each extra angle of opposition between cameras!

You can see this in the example quoted above. The ammount of lag is proportional to the opposing angles of the two cameras: the greater the opposing camera angles, the greater the lag. And yet, the lag is disproportional to the number of renders - so a spotlight depth-camera is MUCH hungrier than a fullscreen shader camera.

Just imagine the chaos this must inflict on the rendering pipeline!

So what I REALLY want now is to cull the depth-camera "view" matrices according to the "view" matrix of the scene camera... Per-pixel culling maybe? You can actually demonstrate this visually with shaders that use stored view-matrices (similar to our spotlight); they do in fact cull per-pixel, based on their "view" matrix.


But the above is really just observation on my part: not any low-level understanding.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 1st Jul 2012 20:22
You may be right but I fail to see what particular mechanism is doing this combining that you refer to. I'm not sure I understood your argument about view matrices. Computing those should be trivial. I'm sure it's the rendering process itself that's the issue here.

Every theory that I've come up with fails to explain such a big drop in fps. I was going to suggest that switching between completely different camera angles/positions during the render cycle could upset DBPro's sorting in preparation for each render - especially if it re-sorts the previous sort for each render. If this is done per polygon rather than per object then this alone might cause the lag with high poly objects. But your demo only has four simple objects, i.e. boxes and cubes, so even a per poly re-sort each render should be a trivial task. In short, I'm still unsure what the cause is.

Interesting issue and I hope someone can explain what's going on.
MMM
17
Years of Service
User Offline
Joined: 21st Jan 2009
Location: NSW, Australia
Posted: 3rd Jul 2012 07:57 Edited at: 3rd Jul 2012 08:25
Quote: "I'm sure it's the rendering process itself that's the issue here."


I feel certain that the lag is imposed by the rendering process, sure. But everything in the scene is handled by shaders and this lag issue appears regardless of the [multicam shadow] shader used. It is dependent on multiple cameras. I don't know how dbpro prepares its information for sending to the shader but I'm just concerned (as above) that the info is becoming convoluted before being sent.

How or why, is my issue. I'm still looking into this. It's hard to know what to search for.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Jul 2012 14:13
Quote: "How or why, is my issue. I'm still looking into this. It's hard to know what to search for. "


Another possibility which makes more sense than my earlier sorting suggestion is the two cameras are rendering the objects in different orders. For example, if one camera is effectively drawing far objects first but the other drawing near objects first then there could be a very noticeable effect on performance as the first case would be doing a lot of wasted drawing.

If the cameras use the same fixed order for drawing objects then you could see this effect - but the effect on fps would vary depending on the position of the cameras and in fact you should see an increase in fps when they face each other in some cases.

It would help if I could recall precisely how DBPro sorts things before rendering.
MMM
17
Years of Service
User Offline
Joined: 21st Jan 2009
Location: NSW, Australia
Posted: 4th Jul 2012 09:04 Edited at: 4th Jul 2012 09:08
Quote: "It would help if I could recall precisely how DBPro sorts things before rendering. "


Well it may not be precise but objects are natively sorted by their "position" distance from the current camera (not camera zero). This can be changed with the "set global object creation" command and to a lesser extend with the "set object transparency" command, which are both documented. I guess that doesn't explain what happens when two object positions are exactly the same. Nor does it explain how shader-drawing is handled - especially in cases where objects use multiple texture stages and where different objects use different textureID combos for each stage (ie; objects using the same "spotlight" image but different "depthmap" images).

Is it possible these features might cause the objects to be drawn inappropriately?


Also, I'm bailing on my "messed-up matrix" theory. I basically stripped down the number of matrices sent to the shaders (the current/original demo updates the matrices in the shaders more often than necessary to accomodate the spinning object). Result is: even frames where no more than one matrix is sent to the shader, and where no camera movements are applied, the lag still occurs based on the angle of the scene-camera. Like you said, the matrices appear to be trivial.

That said, maybe I've just hugely underestimated how laggy those conditional-checks in the shadowmap passes are? I do gain 200-300fps without them. That is no surprise and the numbers do make a little more sense that way too. I'm just suspicious there's something else going on still. Ala this thread.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 4th Jul 2012 15:27
Yes, we'd need to delve deeper into the inner workings of DBPro to explain this one.

Login to post a reply

Server time is: 2026-07-07 17:08:59
Your offset time is: 2026-07-07 17:08:59