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 / Camera clipping not behaving as expected

Author
Message
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 13th Oct 2013 17:29 Edited at: 13th Oct 2013 20:43
I've been having some problems getting a directional shadow mapping system working as of late.
I recently decided to get back to the absolute basics in order to figure out where I was going wrong and in doing so have found out that objects seem to get clipped from the depth rendering camera even when they are clearly in its view.
I've attached an example program showing this in action.

I was wondering if anybody have any clue as to why this is happening?
I thought at first that maybe the objects were clipped based on the main camera's settings (camera 0) but that doesn't seem to be the case. The depth camera further renders the floor beneath clipped away objects just fine so it doesn't seem to be a camera range issue either.


=================================
Controls for the demo program
=================================
Press and hold the right mouse button to control the camera. Look around by moving the mouse, move straight ahead in the camera's direction by holding the left mouse button down. If the control key is also held down, the camera will instead go backwards when pressing the right and left mouse buttons.
Scrolling the mouse wheel will change the altitude of the imagined shadow casting light source.
Left-clicking anywhere on the floor (when not holding the right mouse button) will position a blue test cube there.
Holding down the shift key will change the technique used by the depth mapping camera. This is good for seeing what objects it clips and which it retains (the depth mapping technique will only render a red image that is pretty hard to make out any details from).
The sliders are relatively self-explanatory. If not, just try them out to see what they do.


Finally yes, I know there are still some issues with the bounding box generation for the depth camera. That's most likely my own fault, but before addressing that I want to get this clipping issue resolved.


Edit: updated the attached program. It now features a proper bounding box for the depth camera as well as the possibility to manually choose the depth map size.


"Why do programmers get Halloween and Christmas mixed up?"
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 13th Oct 2013 20:33
i tried the exe - it works at incredibly fast 1 fps

Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 13th Oct 2013 20:43
Hah, guess my graphics card is better than I thought then.

As I said, it's just a test so I kept it as simple as possible rather than trying to optimize anything.
I've recompiled it to give you the option to change the depth map size, hopefully that should make it a bit more efficient (the original version used a fixed depth map of 8192^2 pixels).

I've also fixed the bounding box so that it snaps to the main camera's view frustum better.
It would seem that the problems are associated with the angle of the main camera somehow, but I can't put my finger on it still.


"Why do programmers get Halloween and Christmas mixed up?"
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 13th Oct 2013 23:47
much better, now i get between 60 and 70 fps (depth map size:512).

Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 14th Oct 2013 00:07 Edited at: 14th Oct 2013 00:09
In the top is says DEBUG CAMERA(x,x,x) < what do these 3 variables represent?

Also, those slider bars need fixing

"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 14th Oct 2013 00:21
Quote: "much better, now i get between 60 and 70 fps (depth map size:512)."

Glad to hear it, too bad it looks so bad at that resolution
But hopefully that can be fixed later on.

Quote: "In the top is says DEBUG CAMERA(x,x,x) < what do these 3 variables represent?"

The debug camera is the one with the purple backdrop, it is an orthographic view of the entire scene from above, showing the main camera's view frustum in green and the depth camera frustum in red.
That line near the top is for the depth camera, the values are simply its current coordinates in world space.

Quote: "those slider bars need fixing"

They were just sloppily added in when it got too confusing to use keyboard keys for changing settings. This is just a means to prototype a technique; the project I'm making it for uses DGDK.


"Why do programmers get Halloween and Christmas mixed up?"
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 14th Oct 2013 00:39 Edited at: 14th Oct 2013 00:40
Quote: "The debug camera is the one with the purple backdrop, it is an orthographic view of the entire scene from above, showing the main camera's view frustum in green and the depth camera frustum in red.
That line near the top is for the depth camera, the values are simply its current coordinates in world space."


Now it makes sense.

Quote: "They were just sloppily added in when it got too confusing to use keyboard keys for changing settings. This is just a means to prototype a technique; the project I'm making it for uses DGDK."


My suggest there is to make an On Demand Gui (small library) you can use for things like this that you can drag and drop between projects. On Demand meaning that the GUI itself doesn't store anything. (I really should put mine on code snippets)

"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 14th Oct 2013 21:38 Edited at: 14th Oct 2013 21:39
I'm fairly confident I could make an as advanced gui as I would need, should I actually need one

No offense, but the sliders being off were hardly the issue at hand here.

That said, your suggestion is valid and appreciated.


"Why do programmers get Halloween and Christmas mixed up?"
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 14th Oct 2013 22:02 Edited at: 14th Oct 2013 22:26
No offence sorry

I've followed most of your work and a few of other guys that create interesting content. Yep, you've got the skillz

Haha, my suggestion isn't really necessary, probably more of a personal preference but yeah your right, it's not the main issue.

Is this based of an example that I could possible look at, an shadow mapping example?

Edit:
What looks odd to me is the Depth View Matrix. Thinking about it, the values should only change when the light source changes, but it looks like the main camera is altering it < I think this is the issue

"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 14th Oct 2013 22:59
Haha, thanks for the (probably misplaced) praise xD

It's based on the second post from here, which is about the only source on this I've been able to find. I've also read lots of different papers and pages on directional lighting and shadow mapping so there might be influences from more places too.

Here's my interpretation of the method described over there (I don't use -maxZ for the zNear value and -minZ for the zFar by the way, because that just doesn't seem right at all and results in nothing being rendered at all).
CornerPoint is a 8-element array of a struct of 3 floats (x, y, z). I'm using pick screen for simplicity, a mathematical solution would be faster but much harder to overview and thus making for more possibilities to screw up since you have to do all vector / matrix math step by step in DBPro.
The main camera's far range is expected to be 1024, and the near range 1.



"Why do programmers get Halloween and Christmas mixed up?"
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 14th Oct 2013 23:03
Quote: "What looks odd to me is the Depth View Matrix. Thinking about it, the values should only change when the light source changes, but it looks like the main camera is altering it"

That's actually intentional, the purpose is to shift it so that it looks at the center of the main camera's view frustum at all times (from a position along the light's direction vector).
This is to make it so that only shadows that are actually seen by the main camera get rendered.


"Why do programmers get Halloween and Christmas mixed up?"
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 15th Oct 2013 00:00 Edited at: 15th Oct 2013 00:06
That's alot to sift through but this has peaked my interest, love learning new stuff, so gimme a sec to go over this.

Edit: Nevermind, just found the math
But one thing: In the CreateOffCenterOrthoMatrixLH function, for matrix(1,1) the height component you've got 2 / (t - b) . Wouldn't that put it in the minus? I just guess that it should be 2 / (b - t). What do you think?

(can't find any math on that function yet)

"Get in the Van!" - Van B
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 15th Oct 2013 00:48 Edited at: 15th Oct 2013 00:55
The CreateOffCenterOrthoMatrixLH function actually looks different to other examples I could find. It's a long shot but would this help. Just edited your function:




"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 15th Oct 2013 01:05
Quote: "The CreateOffCenterOrthoMatrixLH function actually looks different to other examples I could find."

Oh really?

I copied it from the MSDN page on D3DXMatrixOrthoOffCenterLH. It seems to hold because it yields the exact same results as the built in DBP function build ortho lhmatrix (which is just a wrapper for D3DXMatrixOrthoLH) when l = -w/2, r = w/2, b = -h/2 and t = h / 2.


Anyhow, I tried it with your version and it seemed to come up with top and bottom values that were just ~1 unit apart. That doesn't sound realistic when the camera is ~600 units away. Also it did invert the resulting extreme Z coordinates, but only about half of them. As for the visual results with that calculation it is unfortunately completely off. But if there are other sources on how to build the matrix that don't agree with MSDN you may be right that that part could be at fault.


"Why do programmers get Halloween and Christmas mixed up?"
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 15th Oct 2013 01:20 Edited at: 15th Oct 2013 01:23
Whoops made a tiny mistake in that code, correction:


I was looking at this and flip codes examples and noticed that a few components of the matrix were negative: http://www.scratchapixel.com/lessons/3d-advanced-lessons/perspective-and-orthographic-projection-matrix/orthographic-projection/

"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 15th Oct 2013 01:57
Actually that matrix results in the exact same thing only with the Z coordinates negated. Unfortunately that only seems to increase the afforementioned problems even further. But that is a good thing as it would indicate that the projection matrix indeed has something to do with it, so thanks for that

If you want to investigate this further I can send you the full source (although the part in the snippet is really the heart of it all, other than that you just set up a second camera to render the depth map, use the techniques in the shader and render the cameras separately).
I'll read through that page you posted tomorrow (it's rather late here at the moment). One thing to look out for is that any OpenGL techniques and code snippets are not directly compatible with DirectX as DX uses left-handed coordinates and OGL uses a right-handed system.


"Why do programmers get Halloween and Christmas mixed up?"
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 15th Oct 2013 02:18
Sure, I don't mind taking a look at it

"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 15th Oct 2013 18:47 Edited at: 15th Oct 2013 18:56
I rewrote it using DarkGDK in case the error was indeed in the math, and it seems that may have been the case.
Moving the main camera about this simple test scene at least seems to draw shadows for all visible objects.

Here's the GDK source for you; I can still send you the DBP project if you're interested but it seems like the issues from that one are solved here, when using the native DXMath functions:


Edit: sorry for the messed up tab spacing in the snippet. Copying it over to a proper text editor with 4 spaces / tab should (hopefully) make it look as intended again though.


"Why do programmers get Halloween and Christmas mixed up?"
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 16th Oct 2013 00:00
Quote: "sorry for the messed up tab spacing in the snippet. Copying it over to a proper text editor with 4 spaces / tab should (hopefully)"


I hate it when that happens with my code...

Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 16th Oct 2013 13:42
Hmm... If you could send the DBP project that would be great so we (I) can compare the GDK one to it if you don't mind. I better with DBP ATM, haven't really dipped my toes into GDK yet though I can understand it.

"Get in the Van!" - Van B
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 16th Oct 2013 20:43 Edited at: 16th Oct 2013 23:28
Oooooooooh!

I was just looking at something and realised that your TrasformVector3 function is incorrect. You need to add the translation (and mat(3,3)) from the matrix to the end and not times it by the w# component which isn't supplied other wise it'll return the result vector as a zero vector!

To this:


"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 17th Oct 2013 00:09
Oh, well actually that's just a lost-in-copy-pasting error where I removed lots of outcommented lines from that function; the original sets w# = 1.0 at the beginning

On a side note, I've sent my DBP source for this project to the mail associated with your profile on here.


"Why do programmers get Halloween and Christmas mixed up?"
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 17th Oct 2013 16:51 Edited at: 17th Oct 2013 19:09
Okay, nearly got it, soon there will be victory !!!



After testing I found that overrideCameraViewMatrix doesn't actually work.

Also just sent you the project. Enjoy

"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 19th Oct 2013 02:29 Edited at: 19th Oct 2013 02:29
Awesome, sorry for not noticing your mail earlier...

I'm currently working on setting it up to use cascaded shadow maps for better resolution and depth map usage, I figure I'll try to port it back over to DBPro in case other people would be interested in it - I'm sure your work will be of great use then

For the time being I've also figured out that the approach of using pick screen to retrieve the frustum corners doesn't work since it's distance parameter is the absolute distance of the pick ray rather than just along the Z-axis. I'm currently trying to do it by transforming clip-space coordinates (x, y, z where each coordinate ranges from -1 .. +1 and represents the frustum planes at their extremes) using an inverted view matrix but that doesn't seem to work too well either.
This is the whole code I'm using for doing that (per corner point):

If you can spot the issue there I think this might just be the last obstacle to overcome; I already have multiple depth maps being rendered (albeit incorrectly due to the above) and sampled depending on z-distance from the camera in my shader.


"Why do programmers get Halloween and Christmas mixed up?"
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 19th Oct 2013 06:22 Edited at: 19th Oct 2013 06:24
I see. Well I believe I already solved this in your previous thread by scaling the direction vectors of the camera:



So this would be:


This should work, but I'll have a look at the code to see what's up with it.

"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 19th Oct 2013 12:57
Oh right, almost forgot about that thread.
Thanks yet again

It turned out the problem with the clip de-projection was twofold; for one the Z coordinate is non-linear. This was to be expected when you think about it I guess. The other was that while OpenGL (which as usual is all there seems to be information about on the net...) uses Z coordinates [-1 .. +1], DirectX uses [0 .. 1]. And due to the non-linearity even the positions closest to the near plane seems to lie at 0.9... values.


"Why do programmers get Halloween and Christmas mixed up?"
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 19th Oct 2013 22:55
I see. So how close are you now to victory?

"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 20th Oct 2013 01:20
I want to say close, but everytime I do I seem to have to regret it

I'm at the stage where everything seems to render fine if I use just the tight fitting bounding box of the main camera frustum, including sub frusta for the depth maps. However the projection box needs to be expanded a bit or shadow casters that lie outside the main camera's view but cast shadows into it will be clipped. Easy enough to solve one would think, but I'm currently getting some out of bounds sampling of the depth maps when I try it.
My code is a mess at the moment though, maybe I should tidy it up first, might make solving it a lot easier... Also I haven't had a good night's sleep the last two days so maybe I should just come back to it in the morning (yeah, yeah, nice excuses, I know.. haha).


"Why do programmers get Halloween and Christmas mixed up?"
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 30th Oct 2013 18:53
Well... turns out I was rather defeated yet again than victorious.

I've made some changes with the intention of making the code both easier to read and more efficient after finding some more reading material on the topic as well as some personal reflection over what actually needs to be done.
Unfortunately, even after rewriting this literally 5 times and picking everything apart in-between I still fail to see where it goes wrong. As far as I can tell, this should work. Or at the very least it shouldn't result in shadows that move with the main camera.
There are still things to add to make it work well in all situations, but this is about the core, "essential" code, decently commented:

Renderer.h

Yes, that's an ugly blend of function declarations and definitions in the same header file. It's just a quick test, get over it.

CSM.fx



There are some utility functions called from the Renderer class as well; here they are:

All they do is set a DB indexed vector4 / matrix resource from their D3D9 equivalents. I use these for setting shader constants.


Also, I'm using a function called dbGetEffectConstantPointer from the renderer that is not exposed in DGDK out of the box. It is used to set more complex shader constants than is allowed by DGDK by default (namely vector / matrix arrays). I've attached a recompiled version of Basic3D.lib that contains this function; this is the debug version of the library so you'll have to use it with the other files from that persuasion. I believe this function returns exactly the same effect pointer as the DarkShader function dbGetEffectPtr, so you can probably use that instead if you have it.


Here is my version of DarkSDKBasic3D.h, in case you want to copy it if you use my attached library file:




As for the remaining code necessary to run this, it is really just a matter of creating a depth map camera and setting it to render to a depth map image, using format 116 (D3DFMT_R32G32B32A32). Then make some objects, set a diffuse texture to stage 0 for them and the depth map to stage 1.
Renderer::RenderDepthMaps() has to be called once per frame. You can just call dbSync() as usual directly after that.

If you'd prefer I can post my entire test project, but the main file is currently rather distracting with ~2000 lines of various out-commented sections, functions main1() ... main8() and so on


Sure hope someone can see what's wrong here, the only other option would be for me to shelve this project and join some friends on a silly mobile phone game made with Unity... oh the shame..


"Why do programmers get Halloween and Christmas mixed up?"
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 30th Oct 2013 23:32
I'm gonna scout round the net and ask some friends about this who have more experience than I do cause this problem is interesting and must be solved! No promises of a solution, but lets hope someone can solve this!

"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 31st Oct 2013 11:07
Indeed, would very much appreciate that


"Why do programmers get Halloween and Christmas mixed up?"
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 4th Nov 2013 12:19
Continued here since it isn't really about camera clipping any longer.


"Why do programmers get Halloween and Christmas mixed up?"

Login to post a reply

Server time is: 2026-07-07 11:21:47
Your offset time is: 2026-07-07 11:21:47