#### Archived

This topic is now archived and is closed to further replies.

# Please critique my idea for plotting a point in 3D space on a 2D screen

This topic is 5086 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

## Recommended Posts

Ok ok ok. I don''t have a lot of programming experience but I think this might work. I drew visuals too. Really this is all for my own benefit because until I put my ideas down on "paper" but I figured I''d have others take a look as well because frankly I don''t know if I''m even close to being right. I want to be able to define a point in 3D space with x, y, and z coordinates, and then plot it on a 2D screen. I think I have this figured out. Please let me know if I''ve got this wrong. Ok, first, I understand that the cone of vision for the uman eye is 60 degrees. I don''t suppose it really matters what I use for the 3D "camera" though, but I''ll go with 60 degrees just for the hell of it: Alright. First thing I should mention is that the x, y, and z coordinates will be relative to the camera''s point of view. Later if I program any games with this (I have one in mind but I doubt I will finish it, because I never do), I will probably have all the points'' coordinates relative to the game world, and then convert the [i">visible[/i"> points in each from to be relative to the camera to make calculations easier. But for now, I have the field of view devided into 4 quadrantS: Now suppose I plot a point in that field of view: It''s 7 "units" on the z axis away from the camera, 2 units on the x axis to the right, and 2 units high on the y axis. Here''s another visual so you can see what I mean: Now the basic idea here is that I want to know what angles (x and y) exist from the center of the point of view and then determine what percentage of the total 60-degree cone these angles take up. Here''s what I mean: Now here''s a better picture with the useless stuff removed: Knowing that the point is both 7 units away and 2 units high, I can easily figure out that the angle here is 15.9454 degrees. The other angle is also 15.9454 degrees because it has the same measurements, so no need to do the math again this time. This tells me that the 15.9454-degree angle is 26.5756% of the total 60-degree cone. When I apply that percentage to the vertical and horizontal resolution of the display, I find that it equals about 64 and 85 pixels. I have to round because duh you can light a fraction of a pixel. Anyway, so now I know how many pixels away from the center of the screen the point should be, right? And now the finished point: The one thing I did notice that was wrong while typing this is that the cone should probably be 60 degrees wide and 45 degrees tall, since the screen has a 4:3 aspect ratio. This method will probably make everything look a little smooshed. Other than that though it seems it should work. What do you think?

wow! 0.o

#### Share this post

##### Share on other sites
i h8 u guys

Just kidding I don''t. But damn I looked at the thread listings and thought I had 2 replies.

#### Share this post

##### Share on other sites
I actually like it.(Ignore my 0.o) I''d like to see it teted out.

#### Share this post

##### Share on other sites
Cool I''ll give it a try when I get home. I don''t know why I always insist on getting an "ok" on my plans without first trying them out myself. It''s not like I mind committing the time to program. :-p

Thanks for the feedback.

#### Share this post

##### Share on other sites
It seems to be correct (didn''t check it personally), but I think it''s a waste of time, you are trying to reinvent the wheel. There is already a whole theory of 3d graphics, projection and rendering, far more advanced than what you could achieve by your own. I think it''s wiser to use what is already there and tested, and work from that point, so your effort is productive.

Besides, using trigonometric calculations like tangent is always slower than matrices.

And even if you code a program to project points in 2d screens, there is still a long road to walk, like rendering polygons, backface culling, texturing, z-buffer.. do you want to go through all that pain just to get to the same point you could be just by reading a couple tutorials?

#### Share this post

##### Share on other sites
The concept is sound, as I implemented it in a cheap QBASIC shape renderer awhile back.

#### Share this post

##### Share on other sites
No of course not, but it's just a fun little challenge I set up for myself. I don't intend to build all of my future 3D programming upon this concept. Just a personal enrichment sort of thing.

The concept is sound, as I implemented it in a cheap QBASIC shape renderer awhile back.

Oh cool! Thanks for letting me know!

[edited by - utwo on January 4, 2004 10:03:15 PM]

#### Share this post

##### Share on other sites
quote:

It seems to be correct (didn''t check it personally), but I think it''s a waste of time, you are trying to reinvent the wheel. There is already a whole theory of 3d graphics, projection and rendering, far more advanced than what you could achieve by your own. I think it''s wiser to use what is already there and tested, and work from that point, so your effort is productive.

Besides, using trigonometric calculations like tangent is always slower than matrices.

And even if you code a program to project points in 2d screens, there is still a long road to walk, like rendering polygons, backface culling, texturing, z-buffer.. do you want to go through all that pain just to get to the same point you could be just by reading a couple tutorials?

And i don'' think its very wise to put down a new idea.

#### Share this post

##### Share on other sites
I don''t mean to sound negative, but the title of the post is "Please critique my idea", and that is what I did.

Personally, I talk from experience. Some years ago I did just the same, spent long times making equations to project 3d points in screen, and even coded it and got to render some basic wireframe objects.

But then I realized it would take me ages to get more advanced things in my own way, and started learning graphic programming with "real" APIs. So I can say that from my point of view, it was just lost time.

#### Share this post

##### Share on other sites
I see what you mean Sante. I just don''t think I have a firm grasp of how it is, or can be, done and so I''m hoping to pick up a few things to get a more solid understanding.

But now that I''ve done the work of figuring it out in my head and putting it on paper, maybe you''re right that it should stay on paper. Should I just start with some OpenGL?

#### Share this post

##### Share on other sites
Well, if you buy a book, most of them teach you the 3d basics, how projections are done and such. I would suggest you, if you already know programming, to go ahead with OpenGL or DirectX. I won''t enter in fightings of which one is better, but you can learn with any.

Then, when you are comfortable with it, you can put your efforts in making new things from that point instead, where they will be really useful for games, if that''s what you want to make. You will also get more results this way, which will keep you motivated.

#### Share this post

##### Share on other sites
I wish my teammates produced such nice visuals.

While I agree with Sante, keep in mind that doing these simple tests using things such as what you''ve described will ultimately ensure that you have a firmer grasp on what''s going on under the hood with the popular 3d APIs.

Nicely done.

#### Share this post

##### Share on other sites
Awesome thanks for all the feedback guys. I really appreciate it.

#### Share this post

##### Share on other sites
quote:
Original post by Sante05
It seems to be correct (didn''t check it personally), but I think it''s a waste of time, you are trying to reinvent the wheel. There is already a whole theory of 3d graphics, projection and rendering, far more advanced than what you could achieve by your own. I think it''s wiser to use what is already there and tested, and work from that point, so your effort is productive.

Besides, using trigonometric calculations like tangent is always slower than matrices.

And even if you code a program to project points in 2d screens, there is still a long road to walk, like rendering polygons, backface culling, texturing, z-buffer.. do you want to go through all that pain just to get to the same point you could be just by reading a couple tutorials?

I don''t think it''s a waste of time, say you wrote your own engine, you could take out all the extra crap you don''t need and have what you do.

That''s what I did with DirectDraw, I wrote my own blitter that took out all the extra stuff you could do with Blt that I didn''t need. No performance increase, but a lot easier to work with.

Why do Suicide Bombers think they''re going to a better place?
Don''t they know their going all over the place?

#### Share this post

##### Share on other sites
quote:
Original post by Utwo
I see what you mean Sante. I just don't think I have a firm grasp of how it is, or can be, done and so I'm hoping to pick up a few things to get a more solid understanding.

But now that I've done the work of figuring it out in my head and putting it on paper, maybe you're right that it should stay on paper. Should I just start with some OpenGL?

It could help to read some really old 3D tutorials and faq. I mean from the DOS era. That way you get a firm grip of the fundamentals of 3D. It wil make it easier to understand what OpenGL does.
I also started out like that. Got to the point of drawing wireframe models and rotating them, but only one 1 axis, or it would screw up. I did it all in QBASIC, later in Borland C++. And I didn't have an internet connection.

But I think that if you start with OpenGL you don't want to go back to writing functions to fill polygons and such.

 typo [/edit]

[edited by - Rule on January 5, 2004 9:28:24 AM]

[edited by - Rule on January 5, 2004 9:28:56 AM]

#### Share this post

##### Share on other sites
quote:
Original post by Sante05
There is already a whole theory of 3d graphics, projection and rendering, far more advanced than what you could achieve by your own.
Projection is very simple, much simpler than Utwo''s complex method.

Imagine that you have a "projection plane" in front of you (eg. the screen). The task is to find out the position on that plane that a ray of light intersect the plane between a given point and your eye. This turns out to be very simple. Consider the following formula where world_x, world_y and distance is in metres, and the latter referes to the distance between the eye and the projection plane:
screen_x = world_x / world_z * distance * pixels_per_meter    -6     0 -6  *           \      \       \-2 -----*--------         \0         o scrren_x = -6 / -6 * -2 = -2
Sorry, I should probably explain it in more detail, but alas! I have no time.

#### Share this post

##### Share on other sites
Utwo, nice concept, it should be well worth a try, just for the heck of it =D
If and when you try the idea, do convert it to fixed point maths. I know I''ll get replies now claiming that floating point is faster on modern hardware, and fixed point isn''t worth the time. So I''d like to reply to them in advance by saying, not everyone has an Athlon - Barton, or a P4 - Northwood, so piss off! =)

When you get it working, post some screenies, would be great to see =)

The more I think, the more confused I get.
The best 2D game developer site out there!

#### Share this post

##### Share on other sites
quote:
Original post by Bad Maniac
Utwo, nice concept, it should be well worth a try
...
I know I''ll get replies now claiming that floating point is faster [than fixed point maths] on modern hardware
Doing error-prone ugly speed hacks should really not be a concern when trying a concept.

#### Share this post

##### Share on other sites
So much detail on the eye for a diagram =P

#### Share this post

##### Share on other sites
quote:
Original post by CWizard
Doing error-prone ugly speed hacks

Also posting without having a clue as to what you are talking about is not advicable. Fixed point is as accurate as you make it, and I wouldn''t consider it an ugly speed hack, more like absolutely essential, unless you WANT to write bad code that won''t run on anything below 2 Ghz.
Without Fixed point maths, we would not have had Wolfenstein 3D, Doom, Quake1 or 2, and I''m fairly sure Unreal and Quake 3 has a fair bit of fixed point in them too.
Fair enough fixed point might not be necessary for testing an algorithm, I admit to that, but if it works, why not speed it up tenfold or so but converting to fixed point?

#### Share this post

##### Share on other sites
quote:
Original post by Bad Maniac
Also posting without having a clue as to what you are talking about is not advicable.
Very true. However, I do know a fair amount about fixed as well as floating point math.
quote:
Fixed point is as accurate as you make it
Yes, and often necessary if you want accuracy.
quote:
I wouldn''t consider it an ugly speed hack,
In this context, it is indeed a speed hack. I doubt anyone will claim that fixed point is cleaner or more elegant than native floating point operations. To me, "ugly code" is the opposite to clean and elegant.
quote:
more like absolutely essential, unless you WANT to write bad code that won''t run on anything below 2 Ghz.
I did always use fixed point when coding on the Amiga 500, but from my Amiga 1200 with FPU (around 1990), floating point have generally been about as fast.
quote:
Fair enough fixed point might not be necessary for testing an algorithm, I admit to that, but if it works, why not speed it up tenfold or so but converting to fixed point?
Exactly my point; it is yet a concept (that sadly probably won''t work out that well). When doing something real of it, I would speed it up twentyfold by letting OpenGL take care of it.

#### Share this post

##### Share on other sites
Utwo: Don''t listen to anyone who says that what you did is a waste of time. I think you did an excellet job of explaining your idea. I honestly think it should be part of the articles and resources section here on GameDev.

If I were you I would continue playing about with your own 3D algorithms. OpenGL is all fine and good, but it doesn''t exist everywhere (like on my cellphone), and knowing how to do these things from scratch will allow you to go to any platform.

I wrote a lot of different 3D effects from scratch (voxels, raycasters, polygons, lighting models, reflections, textures, springs, etc..) and I''m really glad that I did. The knowledge you will gain is priceless. Besides, if you know how to do it from scratch, how hard can an API be after that?

Good job!
Will

#### Share this post

##### Share on other sites
You would also miss out the fun of doing it yourself, wich it seems most people thses days have no idea what it means. And saying that floating point has been faster than fixed point since the amiga 1200 of 1990 is a lie, fixed point is still faster and more accurate on P4 and modern Athlons usually. The only reason it''s not used as widely is because 3D api''s use floats internally, so people never need to concern themselves with it.
Us poor bastards who actually want to come up with something on or own and get it working only keep hearing -Do it in 3D HW and stop "reinventing the wheel".- Well some of us might just want to figure out something for ourselves rather than letting an Api do it for us.

Why make a movie, or write a book, it has already been done?
Why infact write a game using a 3D API, it has already been done. using ogl, talk about reinventing the wheel... (ok, not quite, but I wanted to be sarcastic)

• ### Forum Statistics

• Total Topics
628722
• Total Posts
2984396

• 25
• 11
• 10
• 16
• 14