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 / 3d to 2d screen points relative to camera

Author
Message
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 8th Jun 2013 23:55 Edited at: 9th Jun 2013 00:36
Hello,

This is a general programming question, not necessarily specific to DB, but I'm sure some guru's here have tackled it before.

I have a series of algorithms that help display 3d vertices as 2d pixels. They are relative to the camera's orientation. However, if the 3d points are behind the camera (effectively off screen), the 2d points are still drawn.

Does anyone know the logic of how NOT to draw the 2d points if the 3d point is behind the camera? How do I determine what is "behind" the camera? The angles of the camera could be at any orientation. How do I determine what is out of the field of view?

I guess I'm looking for the logic of OBJECT IN SCREEN().

Thank you

[EDIT]

I'm starting to think, maybe I have a plane that's say, 1 unit in front of the camera. Any points with a distance to this plane positive would be on one side, and any points with a distance negative would be on the other side.

So, mathematically, how do I get this plane's normal?

Enjoy your day.
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 9th Jun 2013 02:00 Edited at: 9th Jun 2013 02:01
Search for frustum culling

Edit: or wait, do you need to do this for each pixel?
In that case it might be a bit more complicated...


"Why do programmers get Halloween and Christmas mixed up?"
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 9th Jun 2013 02:25
@Rudolpho
Thank you for the suggestion. I read up on Frustum Culling and it seems like it will be what I need in the long run. I do need to cull per pixel, and after rolling it around in the old coconut for a while, I think I have a quick solution to get some test results I need.

Since the camera points down the +z axis when all angles are zero, I can rotate a 1 unit z by all three camera angles. The resulting 3d coordinate should give me the normal to the plane the camera is on. I can use the camera's position as a point on the plane, and use the dot product to find the distance from the 3d vertices to this plane. Positive values are in front of the camera, negative behind.

I can eliminate even calculating the 2d by limiting the 3d points by the plane.
The bounds for the 2d pixels are the screen dimensions so I should be able to draw only those in front of the camera and within screen bounds. Does this seem reasonable? Does it sound like a lot of overhead?

It makes sense as I'm typing, but we'll see how it goes.

After this, I'll try and tackle frustum culling.

Thank you

Enjoy your day.
chafari
Valued Member
20
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 10th Jun 2013 01:35
We could guess what vertex are in front of the camera, just knowing the camera angle y()...getting actual values of x,y,z and then move the camera back just a bit an get new x,new y,new z ...then depending the method we use, we can get the distance of every vertexdata and we can know which of them are in front of the camera.

I'm not a grumpy grandpa
paul5147
20
Years of Service
User Offline
Joined: 11th Jan 2006
Location: Hot & Sunny
Posted: 10th Jun 2013 07:55
Quick method I've used for the camera normal in the past is to position a dummy object at the camera position,set it's orientation to match the camera,move it one unit,then subtract it's new position from that of the camera,it's not perfect but it's worked for what I've needed in the past.
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 10th Jun 2013 08:31
@Chafari
The y angle wouldn't necessarily be enough. If the camera were rotated on the x axis by 95 degrees and 10 on the z axis, the y angle would still read zero - however as you and paul5147 mentioned, the camera can be moved and the normal would be the difference between positions.

Thank you both for the suggestions.

I was considering moving the camera but I was planning on passing all of the camera data to a dll anyway so I was thinking of a way to calculate the normal in the dll. Though it may be be faster just to move the camera and get the normal that way and pass that to the dll. I'll try both and see what works better.

Enjoy your day.
Silverman
19
Years of Service
User Offline
Joined: 18th Jan 2007
Location: France
Posted: 10th Jun 2013 13:23
Hi Latch,

I just finished fixing bugs of the library of functions 3dmaths made by Dmitry K(which is DBC language because calculations matrix4 of the dll are bugged).
I started some tests on matrix4, and I found this link that talks about: camera view
http://www.gamedev.net/page/resources/_/technical/directx-and-xna/direct3d-7-im-framework-programming-2-first-st-r896

I hope it can help you

DirectX 9.0c (February 2010)/ DBClassic v1.20
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 10th Jun 2013 13:37 Edited at: 10th Jun 2013 13:39
@Latch

A very quick&dirty solution:
1) let Vector A equal pixelPosition - cameraPosition
2) let Vector B equal the camera's direction (doesn't have to be normalized)
3) if dot(A,B) < 0, the pixel is behind the camera

In pseudo code, it would look somewhat like this.



However, using frustum culling is much cleaner.

TheComet


Yesterday is History, Tomorrow is a Mystery, but Today is a Gift. That is why it is called "present".
MadBit
VIP Member
Gold Codemaster
17
Years of Service
User Offline
Joined: 25th Jun 2009
Location: Germany
Posted: 10th Jun 2013 18:03
maybe this will help you?
http://forum.thegamecreators.com/?m=forum_view&t=201642&b=7&msg=2411129#m2411129

Share your knowledge. It's a way to achieve immortality. (Tenzin Gyatso)
Pixie-Particle-Engine
Phaelax
DBPro Master
23
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 10th Jun 2013 22:27
Comet beat me to it. I'll just make a correct however. You want the camera's normal of the direction it's facing, not the vector between the camera and the point itself. (which I see now that's what his code does, the explanation sounded misleading at first)


I'm not sure how you're calculating your 3d to 2d points, but this might help:
http://dbcodecorner.com/showcode.php?snippet=39

TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 10th Jun 2013 22:43
Quote: "You want the camera's normal of the direction it's facing, not the vector between the camera and the point itself. (which I see now that's what his code does, the explanation sounded misleading at first)"


Don't you need the direction it's facing and the vector between camera and the point itself to calculate the dot product? (That's what the code is supposed to be doing)

TheComet


Yesterday is History, Tomorrow is a Mystery, but Today is a Gift. That is why it is called "present".
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 10th Jun 2013 23:56
You could just use the camera's view matrix to calculate the desired coordinate.
Phaelax
DBPro Master
23
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 11th Jun 2013 03:03
Quote: "Don't you need the direction it's facing and the vector between camera and the point itself to calculate the dot product? (That's what the code is supposed to be doing)"


Maybe. It's been a few years since I did anything like that with vectors. Actually, now that I think about it that would make sense, so you're probably right.

chafari
Valued Member
20
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 11th Jun 2013 16:34
Here's an example of my theory....at first I did this calculation to see if the enemies could see me when being behind. The calculation works if we make some test with a timer or whatever...at runtime is to slow




I'm not a grumpy grandpa
SoftMotion3D
AGK Developer
20
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 12th Jun 2013 04:02 Edited at: 12th Jun 2013 04:04
how about replace those intersect object commands...they are too slow!! (I know from experience calling on those commands too many times per sync is a frame rate killer!!)

my replacement command is much quicker... (at least that's what im telling myself...lol!)



for fun I will download your code and change it with my function...i'll report my results

SoftMotion3D
AGK Developer
20
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 12th Jun 2013 04:17


interesting.....
I was right about that command being slow. but I don't get the same results you get with the intersect object.

frame rate...impressive change!!

on my pc your code was 8fps and my code is 47fps

however the strange part is the way it calculates looks different when you move the mini camera around....have a look with this code to see for yourself

Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 12th Jun 2013 04:33
Quote: "Does anyone know the logic of how NOT to draw the 2d points if the 3d point is behind the camera?"


Post rotation any vertex that's Z is lower than the clipping plane is behind the camera, so don't draw it.

Old Example

chafari
Valued Member
20
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 12th Jun 2013 14:05 Edited at: 12th Jun 2013 14:23
@SMD_3D Interactive ...Nice to see you are still around here

You are right, about INTERSECT OBJECT command, I've used just to show somehow how to determine it vertex where infront or behind the camera, that could be ok for ten enemies in a game. There are a lot of ways to check distance, and yours works better. We can adjust the ...let say "camera fov" just playing with

if dis#<dis2#+1...- 1.1 or - 1.2 or - 5 etc.



@Kevin Picone
I will have a look at this, thanks.

I'm not a grumpy grandpa
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Jun 2013 17:55
Thank you everyone for your suggestions and examples.

For now, what I'm going to do is pass the camera coordinates and angles to a DLL as well as the vertices. All of the calculations will be done in the DLL. Because the camera's 0 degree orientation is facing down the +z axis, the normal to the plane the camera is on should be (0,0,1) rotated according to the cameras angles.

From there I use the camera's position as a point on the plane, and then use the dot product to find which side of the plane a 3d coordinate is. I convert the points in front of the camera to 2d, and only draw the points that are within the screen.

Enjoy your day.

Login to post a reply

Server time is: 2026-07-08 00:25:55
Your offset time is: 2026-07-08 00:25:55