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 / Getting corner points of near and far planes?

Author
Message
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 12th Sep 2013 18:26
Like the title suggests, do anybody know of a efficient and simple way to accomplish that?
I've been struggling with various weird approaches that attempt to infer the corner coordinates from the view matrix, but they never seem to do what they're supposed to in the end.

Thanks in advance for any suggestions,
Rudolpho


"Why do programmers get Halloween and Christmas mixed up?"
pictionaryjr
17
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 12th Sep 2013 19:20 Edited at: 12th Sep 2013 19:42
This is really quite simple to achieve with rotation matrices.

You would have to invision the plain at 0 with 0 rotation so if you had a 10 by 10 plain at 0 with no rotation it's top left corner would be -5,5,0. It's top right would be 5,5,0. It's bottom left would be -5,-5,0. It's bottom right would be 5,-5,0. You could then use rotation matrice's to calculate where the points would be at the actual rotation and then add the plains center coordinates onto the rotated corner coordinates. Bam you've got ure corners. I'll write a function for you in 1 sec.
mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 12th Sep 2013 19:40
Maybe do reversal (2d-to-3d) of this?

pictionaryjr
17
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 12th Sep 2013 19:47
This should work as long as you don't rotate the z axis. I made it for camera use originally so there was no z axis rotation. I'll fix for you though.
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 12th Sep 2013 20:49
Thanks for your suggestions.
I however don't have any actual plane object, but was rather referring to the near/far planes of a camera's view frustum. As such I don't know the dimensions of the planes. However, maybe that can be calculated from the fov, aspect ratio and near/far distances, in which case your approach might work. Will look into it


"Why do programmers get Halloween and Christmas mixed up?"
mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 12th Sep 2013 21:13 Edited at: 12th Sep 2013 21:27
You need to get 4 vectors (are red), from camera to each of the corners (direction). From camera view that vectors would be seen as red dots, because they are view vectors. Then you get 3d coords from 2 distances - near and far. Look at that thread with matrices.



pictionaryjr
17
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 12th Sep 2013 21:37 Edited at: 12th Sep 2013 21:40
Edit:
Read comment sorry

DOUBLED EDIT:
MR Handy pretty much explains what you're looking for, but random question as to why. We might be able to help you further if you explain you're reason for finding the viewing planes
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 12th Sep 2013 22:15 Edited at: 12th Sep 2013 22:16
@Mr Handy: Your solution makes sense, but how would I find a vector between two points to figure out the second point when all I have is the first?
Or maybe I'm missing something?

@pictionaryjr: The reason for this is so that I can create a bounding volume for what is seen by the main scene camera. The volume will then be used to build an orthographic projection matrix for a depth rendering camera, thus allowing for better shadow detail in large scenes by only considering the areas that are actually seen on screen.


"Why do programmers get Halloween and Christmas mixed up?"
pictionaryjr
17
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 12th Sep 2013 22:35 Edited at: 13th Sep 2013 07:37
Use it each function twice for each corner of the screen. First time will be cast at the distance of 1 or 0 and second will be cast at whatever you want the edge of your bounding volume to be. Bam. All 8 corners with xyz


Edit:
You could actually just apply it to the four corners using the desired distance and then just use a rotation matrix to calculate what the closest points would be

Double Edit:
Sorry I know I'm being cryptic, but if you'd like I could write up a function for that as well.
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 13th Sep 2013 00:05
The 3D corner coordinates of the near and far planes are equal to the pick vectors of the viewport corner pixels using the near and far distance as the pick distance.

Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 13th Sep 2013 04:05 Edited at: 13th Sep 2013 04:24
Wouldn't it be easier to just:

1: Work out offset distances from centre for vertical and horizontal
2: Get the camera Look, Up and Right vectors
3: Scale them by plane distance, vertical and horizontal distances
4: Add all vectors to camera position

For instance, this would calculate all points for a plane at any distance/angle:


"Get in the Van!" - Van B
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 13th Sep 2013 05:51
Looks good

Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 13th Sep 2013 14:35
Quote: "The 3D corner coordinates of the near and far planes are equal to the pick vectors of the viewport corner pixels using the near and far distance as the pick distance."

Hah, I guess you're right about that, should've thought of that

@Sasuke: That's pretty much what I've been trying to do lately, albeit through vector math that gets weird when you cannot write it contiguously in DBPro and have to break it down. Not that that's hard per se, but it gets really funky to read 50 lines with copying to temporary vectors etc. because you can't just write (a * b) inline. Anyhow, your solution seems to yield the correct results, I will compare it to my code and see where I went wrong. Thank you very much


"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: 13th Sep 2013 15:16 Edited at: 13th Sep 2013 15:17
Quote: "albeit through vector math that gets weird when you cannot write it contiguously in DBPro and have to break it down. Not that that's hard per se, but it gets really funky to read 50 lines with copying to temporary vectors etc. because you can't just write (a * b) inline."


Yeah, I just write wrappers to a temp vector for example:


I also have a function set to just alter that temp vector so I only extract the final result, really cuts down on the work.

Quote: "Thank you very much "


No problem, I've found that the right, up and look vectors are extremely useful but not many people know of them. Maybe a tutorial should be written

"Get in the Van!" - Van B
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 13th Sep 2013 16:00 Edited at: 13th Sep 2013 16:01
True that.
Here are some direct-access wrapper functions for retrieving the internal camera vectors that I use. Saves on all the extraneous trigonometric function calls (not that I think they will really slow down your application unless used way too often though).



You can get all other relevant camera data (as well as set it) in the same way. The same goes for objects, images etc. Also something not too many seems to know about but that can indeed come in handy at times


"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: 13th Sep 2013 16:55
Yeah I remember those, I tested the speed difference a while back, the only noticeable difference is the math equivalent for the right vector is far quicker where as the others aren't. There pretty identical though. But what I'd like to know is do they come back normalised?

Reason I use maths for most things is because I can see what's going on under the hood, plus I can see how things work so when I need to make some specific that you can't find a command for I know what do. Definitely feature specific though, what ever gets the job done faster wins so I use both.

"Get in the Van!" - Van B

Login to post a reply

Server time is: 2026-07-07 00:08:30
Your offset time is: 2026-07-07 00:08:30