Advertisement

choice a 3d axis

Started by March 28, 2014 03:54 PM
3 comments, last by fir 10 years, 10 months ago

This is banal question but really i still dont know

i got software rasterizer and thus 3d world and whole code to

rasterization 3d to 2d, One of first choices is to choice of

axes for 3d coordinters, and i dont know what to chose

as i understand choice of z schould be taken from some

right hand rulse so it is dependant after choicing a x and y

if so i got two options

1) x shoulld go right, y should go down, z should go into the screen (could call it hardware coordinates)

2) x should go right, y should go up, z should go from screen to viewer (could call it math coordinates

which is better and why? is one some kind of universal?

as far as i remember opengl and dx chose 2, but i seem to opt

for 1 (because in 2d i got natural x goes right y goes down - also z going depth seem a bit better for my imagination)

You can choose any convention you want. You just need to make sure everything follows that convention, which can be a hassle because you'll probably need to interact with other tools, or at least their results (eg. for your assets).

If you choose the second option, your importers might end up having to transform the geometry files it reads. It is also important to take into account third party libraries if you are going to use them. For example, FreeImage works naturally with your first option, but you would need to reverse the images for the second...

If I were you, I'd chose OpenGL's or DirectX's one. Since you want a right-handed system for some reason, just use OpenGL's. The most common your choice, the less incompatibilities you'll have with everything and the less 'glue' code you'll need.

“We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil” - Donald E. Knuth, Structured Programming with go to Statements

"First you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" - Ken Beck, Twitter

Advertisement

Yeah, interop and consistency are really the big points to think about. Personally I think GL's RH system is idiotic and broken and RH systems should be Z-up, but that's just me. So I would probably use the D3D version, LH with Z into screen.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

You can choose any convention you want. You just need to make sure everything follows that convention, which can be a hassle because you'll probably need to interact with other tools, or at least their results (eg. for your assets).

If you choose the second option, your importers might end up having to transform the geometry files it reads. It is also important to take into account third party libraries if you are going to use them. For example, FreeImage works naturally with your first option, but you would need to reverse the images for the second...

If I were you, I'd chose OpenGL's or DirectX's one. Since you want a right-handed system for some reason, just use OpenGL's. The most common your choice, the less incompatibilities you'll have with everything and the less 'glue' code you'll need.

I just get know that ogl uses rgight handed (2 option mentioned, most probably) but dx uses lefthanded (probably also x-> right

y-> up ) - what a shame in a way, left handed seem that should not be used it seems that whole math uses righthanded (though im not sure but that is like i remember it)

Yeah, interop and consistency are really the big points to think about. Personally I think GL's RH system is idiotic and broken and RH systems should be Z-up, but that's just me. So I would probably use the D3D version, LH with Z into screen.

Indeed i forgot it , very good idea, x/y should be in horizontal plane z should go up - this is as to word coordinates -- the rest is just camera position , so probabli it can be treated as it is no such thing as 3d screen coordinates - only word space and some camera position (which by default should be for example at camera.pos = {0,0,1000} (1000 z up) pointing down to xy plane camera.dir = {0,0,-1}, camera up = {0,1,0} -maybe that i will do

this functionally is close to opengl x- righy y - up , centred to 0,0

and moved +1000 on z

This topic is closed to new replies.

Advertisement