3d gaming - with SFML ?

[Bolbi]

Ok, I got a plan for making an 3d game. I coded some 2d games with Codeblocks and SFML, c++. My question is:
How can I make my game 3-dimensional.
Can I do it, just with SFML?

[geniusberry]

I don't think sfml supports creating 3 dimensional games by itself. If you really want to use it, I believe there's a way to use OpenGL from within it, and create 3d things from there, but you'd be better off using something else. Like ogre3d or maybe irrlicht.

http://www.ogre3d.org/
http://irrlicht.sourceforge.net/

good luck!

[Avilius]

SFML has great support for 3D games via OpenGL.

[chrisname]

I would also recommend Ogre or Irrlicht (or something else -- but those are tried-and-true renderers), and not even because 3D graphics is hard (it is, but IMO it's the fun kind of hard), but purely because storing, loading and operating on meshes is a massive PITA and game development is difficult enough without going through all that stuff. Better to complete a few projects using higher-level libraries like Ogre and then learn the low-level stuff like OpenGL and the various mesh file formats and representations later.

[DeXecipher]

simple equation for 2d-to-3d transformation of a 3d point:

dx = x1-x0;
dy = y1-y0;
dz = cpointz-ccameraz;
x' = (dx/dz)*screen_width; = cos(theta)*screen_width;
y' = (dy/dz)*screen_height; = sin(theta)*screen_height;

then you are done. It will be slowish because you are using floating point. But floating point is a quick fix.

it assumes that dx is the x position from the top left, and dy is the y position from the top left. and dz is the distance of the point from the camera/viewpoint.

The only complicated part is filling the polygons and drawing geometrical shapes. You would have to find the vertices and draw lines from thoses vertices in a given order and then shade it.

[DeXecipher]

All 3d graphics is is a conversion of 3d coordinates to their representations in 2d space.

[10X9216C]

simple equation for 2d-to-3d transformation of a 3d point:

dx = x1-x0;
dy = y1-y0;
dz = cpointz-ccameraz;
x' = (dx/dz)*screen_width; = cos(theta)*screen_width;
y' = (dy/dz)*screen_height; = sin(theta)*screen_height;

then you are done. It will be slowish because you are using floating point. But floating point is a quick fix.

Idk what kind of messed up equation that is, but w/e. You also shouldn't be doing that kind of transformation on the CPU.

If you want a 3D perspective, then there's a perspective projection matrix. There are API that create matrix for you with simply parameters, also has some information on how the matrix works (doesn't work in chrome for some reason... http://www.opengl.org/sdk/docs/man2/xhtml/gluPerspective.xml ).

[DeXecipher]

whats wrong with it

x' = x/z;
y' = y/z;

affine transformation...

[TwilightSpectre]

I think this is just a matter of efficiency - you are doing the calculations on the CPU, while you could alternately use hardware accelerated graphics by moving the calculations onto the GPU, which would be much more efficient (and probably more accurate, too).

[DeXecipher]

you gotta walk before you can run.

[Lachlan Easton]

I'd sooner recommend Cinder http://libcinder.org/ or OpenFrameworks over irrlicht or Ogre.

[chrisname]

DeXecipher wrote:

whats wrong with it

Well, efficiency is one thing and accuracy is another, as NT3 pointed out, but also, that projection equation doesn't include perspective so different objects will appear to be the same size regardless of distance from the viewer.

As for "you gotta walk before you can run", I disagree. Learning to do those calculations on the CPU before the GPU doesn't really help you in any way.