Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Using SFML in our 3d graphics engine  (Read 11233 times)

0 Members and 1 Guest are viewing this topic.

Syntactic Fructose

  • Jr. Member
  • **
  • Posts: 80
  • Overflowing stacks and eating snacks
    • View Profile
Using SFML in our 3d graphics engine
« on: February 27, 2013, 07:33:42 pm »
Me and 6-7 others are designing and writing a 3d graphics engine, and we plan on using SFML for handling the window and input. While reading about the 2.0 release i read this:
Quote
Will/does SFML support 3D?

No, and Laurent (SFML's developer) has decided to keep the library as a way to handle 2D graphics with ease and hardware acceleration, so in short there won't be support for 3D in the future either. However you can use Irrlicht with SFML as a window creator. You could also use raw OpenGL to implement 3D and have it alongside your 2D rendering in SFML without problems.

This worries me a bit, what does this mean by no 3d handling support? Is this for SFML's internal graphics, as in it shouldn't be a problem since we are writing completely in OpenGL 3.3. Or is this directly related to SFML's ability to render 3d objects to the screen? Thanks for any help!
« Last Edit: February 27, 2013, 07:35:54 pm by need4sleep »

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Using SFML in our 3d graphics engine
« Reply #1 on: February 27, 2013, 07:38:52 pm »
This means that SFML will not provide any 3D features in its own API. You can still use OpenGL in combination with SFML to render 3D graphics.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Haikarainen

  • Guest
Re: Using SFML in our 3d graphics engine
« Reply #2 on: March 08, 2013, 12:34:36 pm »
If you only use SFML for window and input, it will work well (this is what I have done after a lot of trial and error mixing SFML with OpenGL).

Some examples: The sf::Texture class does not expose a bind method, nor a method to get the GLuint of the associated internal texture. sf::Shader does not take all of the parameters (matrices included), which makes highend shaders impossible (if you don't edit SFML internally, but then you'd have problems distributing your project on Linux without distributing your edited SFML as well).

I basically only use SFML for Window, input, underlying eventhandling and audio. Network as well currently although I plan on writing my own as I've came across a few problems with it.  Also some basic stuff like drawing text is SFML-powered. The rest is my own written classes for Textures, Vertex/Fragmentshaders, FBO/VBO's,  etc :) As long as you remember to push and pop sfml's glstates between calls you should be OK

 

anything