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.

AppGameKit Classic Chat / [SOLVED] Issue with Get3DVectorXFromScreen and Orthographic view

Author
Message
TomToad
6
Years of Service
User Offline
Joined: 6th Jan 2018
Location:
Posted: 9th Apr 2018 00:02
Code below shows a bunch of spheres laid out in a grid on the xz plane. below the mouse cursor is a larger sphere on that plane. Change angles using arrow keys and pan left/right/up/down with WASD. as you can see, no matter how you move, the sphere remains under the mouse cursor, just as I want it to be. Now uncomment lines 22 and 23 to enable orthographic view. Now the cursor is way off from where it should be. I used a modification of the code from here https://forum.thegamecreators.com/thread/55835#msg587148. the code has been simplified as the plane's normal is 0 on the x and z and 1 on the y, so dot product of vector A with normal is just the y component of A and as the plane origin is at 0,0,0, then d will always be 0 making calculations simple.

I don't believe that my code is in error as it works fine in normal 3D mode, only breaks in orthographic mode.

The author of this post has marked a post as an answer.

Go to answer

PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 9th Apr 2018 18:14
There was a thread about this HERE, a solution was posted at the end of the thread you can probably get what you need from that.
Bengismo
6
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 9th Apr 2018 19:19
Get3DVectorXFromScreen() and its sister functions work fine in perspective or orthographic mode..... but you need to understand what the numbers returned actually represent....

In orthographic mode all vectors are parrallel moving away from the camera but in perspective mode they are not parrallel and diverge instead so the method for finding the start and end of the raycast vectors are different.




TomToad
6
Years of Service
User Offline
Joined: 6th Jan 2018
Location:
Posted: 10th Apr 2018 10:17
@PartTimeCoder: Thanks, the code in that thread worked great.

@bengismo: The documentation isn't very good at explaining what exactly Get3DVectorXFromScreen() is returning. It just says it is a unit vector pointing into the 3D world. That could mean just about anything. My guess is that if the vector was extended to infinity, then it would go through all the points in the world visible in that pixel. Basically an extension of the vector from the viewer to the point on the screen. Might need to work up some tests to see if what I get is what I'd expect when I get the chance.
Bengismo
6
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 10th Apr 2018 13:53 Edited at: 10th Apr 2018 14:02
This post has been marked by the post author as the answer.
The documentation for this function isnt ideal - but it is completely correct in perspective mode and I got what it meant by the description. Maybe it could do with a little more info.

AGK Documentation wrote: "Converts a 2D point on the screen into a vector pointing into the 3D world. The vector is normalised to 1 unit long, to extend it into the world simply multiply it by your desired distance."


So the camera position is the start of the ray and the numbers given by this function are the normalised direction of the ray that would hit the pixel coordinates that you put into the function. So this is correct and described well enough I think.


The problem is in orthographic mode where the direction vector is always the same (along the camera z axis) so it doesnt vary no matter what pixel coords you put in. The numbers returned by the function in this case gives you the starting point of the ray...NOT the direction.




Perspective: Ray starts at camera and moves in the direction of the vector given by Get3DVectorX/Y/ZFromScreen()

Orthographic: Ray starts at coordinates given by Get3DVectorX/Y/ZFromScreen() and travels in the direction of the camera z axis


The thread linked to above by part time coder has working code which shows the difference. To correctly define a ray in space you need a start point and an end point but we only have one set of functions...so it has been used to do two different jobs for two different scenarios.

Hope that helps
PSY
Developer
7
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 10th Apr 2018 18:17 Edited at: 10th Apr 2018 18:18
Nice explanation!

Thank you!


PSY LABS Games
Coders don't die, they just gosub without return
TomToad
6
Years of Service
User Offline
Joined: 6th Jan 2018
Location:
Posted: 11th Apr 2018 09:14
Thanks Bengismo. That explanation is a big help.

I do think the documentation is incomplete. There is no mention of the camera, so it is reasonable to assume some will think the ray is being cast from the screen (the frame buffer plane in your illustration). The example code doesn't help either with this comment // calculate the start of the ray cast, which is the unit vector + the camera position, as that implies the ray isn't being cast from the camera, which confused me as I couldn't understand how you could get the ray's origin by simply adding a vector normal to the camera position position since you could click on a spot that was more than one unit away depending on the scale you are using.. Based on your explanation, and reading the code you posted in the other thread, I think the example is trying to accomplish is to move the start of the ray from the camera to the near clipping plane. So the comment should actually read //Move the ray cast start from the camera position to the near clipping plane.

This is a good example of why we should allow comments on the doc pages and not just code examples. I think your explanation would go a long way in helping people.
Bengismo
6
Years of Service
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 11th Apr 2018 10:58 Edited at: 11th Apr 2018 11:16
TomToad wrote: "The example code doesn't help either with this comment // calculate the start of the ray cast, which is the unit vector + the camera position, as that implies the ray isn't being cast from the camera, which confused me "


The arbitrary adding of 1 unit into the scene kind of makes sense if your near clipping value is at the default" 1". All though the near clipping plane is only 1 unit away in the centre of the screen and its actually further away from the camera towards the edges of the screen. Personally ive never had a problem leaving it at the camera as long as your camera isn't inside objects.

The start of the ray cast can be at any point you like along the ray from the camera into the scene. In perspective mode all rays converge/start at the camera position and go into the scene. You might want to only detect objects between 5 and 10 units away and so add 5 unit vectors for the start (camera position) and 10 unit vectors for the end. Its up to the programmer to decide where they want their ray to start and end. In the example I posted, I made it start at the camera and made it 1000 long but that might be way too short or too long depending on someone else's requirements.

I would agree that the documentation could be a little better but id rather the developers spend time adding features then needlessly making every single function overly documented. lol....I understood it and i'm definately not the sharpest tool in the box.

The examples can be submitted by users and you dont know what they were trying to achieve or if they really are using the functions as expected. I don't tend to use them for that reason - maybe just for an idea. I prefer to find out what the function does and so I understand it rather then copy code without knowing what it does...that tends to lead to problems.

Login to post a reply

Server time is: 2024-03-29 11:41:10
Your offset time is: 2024-03-29 11:41:10