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 / Perspective projection (change existing code not to be dependent on built in camera)

Author
Message
Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 12th Sep 2013 11:54
I've found this code here from 9 years ago, which uses vectors and transformation matrices to bypass the OBJECT SCREEN X/Y() commands.

It's a cute little solution, although i found a tiny problem with it: what if i want to input my own camera properties (including FOV) into it, and not the built in darkbasic camera's coords and angles?

The code:



As a secondary question, on my quest to try figuring out this whole topic i've come across this neat looking formula on Wikipedia:



Here on this page: http://en.wikipedia.org/wiki/3D_projection


Should this work like the vector method? Because for the life of me i can't get anything not abnormal with that. But would prefer something similar so i'm not bound to only DarkBasic with my code.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 12th Sep 2013 14:46
Quote: "what if i want to input my own camera properties "


Just use the following before calling things like projection matrix



That should work but I vaguely recall a bug with one of the commands. Try it first anyway - and don't forget to use set current camera again to restore your main camera.



Powered by Free Banners
Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 12th Sep 2013 15:29
I meant forgetting about the camera and object commands altogether.

I store entities and their props in arrays, and i have the camera info in other variables.

And i want to project the entities' center (and later bounding box) points to the screen using these parameters.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 12th Sep 2013 20:28
Quote: "I meant forgetting about the camera and object commands altogether."


What would be the point of that when DBPro does the calculations for you?



Powered by Free Banners
Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 26th Sep 2013 00:01 Edited at: 26th Sep 2013 00:04
I'm working on my own renderer, which in the end as i hope may replace polygon rendering in most areas of gaming, while funnily making rendering not only much more real like but faster at the same time.

I intend to move on from DBP to gain processing speed (it is unacceptable for something like this to be already under 30fps just because i create an image of a memblock storing screen data) in the future, so i cannot settle with methods that cannot be translated to other languages.

I've managed to do quite a lot since my first entry here, although the 3d part is just coming, but i'm almost fully done with my own poly rendering. Which is still going to be used for particles as soft-particles, so it's needed. And it is a major stepping stone to move on from with my ideas about new ways to render 3d objects.

The picture attached shows my cube with a texture. Done fully with my renderer, no built in stuff or any parts of DirectX. Realtime Z-depth mapping and per-pixel fog is already present.


I'm using the vector code from the topic starter entry, but that's:
1. DB specific
2. Works great, but if you turn the camera 180 away, there's the 3d point projected onto the screen again


So anyone knowing anything about projecting 3d points as 2d coordinates onto the screen with the least effort (i mean calculation time, i'm not lazy or something... hell all is there to work with and i'm thinking of writing my own renderer, what am i?), while not using built DBP commands, are very welcome!

(everywhere i look, everybody keeps talking about transformation matrices but forgets to explain, the hell are those, and how do i utilize them?)
thenerd
17
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 26th Sep 2013 02:56 Edited at: 26th Sep 2013 02:56
I'm curious about your renderer... how does the actual drawing work? Are you using some sort of raycasting system for each pixel, or drawing 2d polygons that have been projected from the 3d scene? I don't quite understand the details!

Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 26th Sep 2013 03:12
Quote: "
2. Works great, but if you turn the camera 180 away, there's the 3d point projected onto the screen again
"


You'll need to clip intersecting polygons to the near (view) and far planes. Any polygons where all vertex Z's are less than the near plane are rejected.

Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 26th Sep 2013 11:33
First every objects exist as bounding boxes, and the points making up these boxes are projected onto a screen sized array, leaving out the points that aren't required to make up an outline of the bounding box.

This outline (consisting of two pixels per each scanline, pixel 1 means pen down, pixel 2 means pen up for the renderer) is then also saved in the array, which is then read by the renderer line by line, pixel by pixel.

When it hits an object bounding box, then it will activate my 3d reading function which for the time being only exists on paper.

As for polygons, or to be more accurate right now boxes made up of 6 polys, it interpolates from the points' properties that made up the box, to get the exact position on the texture, and recover the color info. There is no multisampling going on right now and it still does an adequate job. But it will be there. I'm really happy with it because it just couldn't be bothered by the fact that you are either working with a texture of 2x2 or 20Kx20K, it only depends on the available memory.

I've been inspired to start this project when i heard that today's graphics rendering is done by pasting objects one by one onto the screen rather then rendering all at once pixel by pixel, which i find sounding much more efficient. Surely explains all the stupid problems i ran into with drawing order when i experimented with my particle engine.

If i'm not mistaking too much on paper, there's not gonna be a need for LOD, any clipping operations (to a certain extent), and practically photorealistic objects will be possible without any silly tricks like normal mapping or futile attempts to give polygons depth like parallax mapping. If we count all the stuff that comes with a decent ingame object nowadays, even the storage space requirements won't be higher, or in the case of some really complex stuff, won't be much higher.
Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 26th Sep 2013 11:38
Oh, i almost forgot, 3d entites are going to be like sprites in DB, loaded once, pasted countless times. Which seems to me like a pretty nifty feature since i couldn't really find anything like that in DB in the past 13 years.

Login to post a reply

Server time is: 2026-07-06 10:32:55
Your offset time is: 2026-07-06 10:32:55