Hi,

I've been reading some threads about what toolkits to use with OpenGL development. In summary, I've noticed that the community would advice to determine the nature of the application, what it has to do, in order to decide on what the best approach is.

Okay, I am developing a Virtual Environment where I can:

1. navigate smoothly with an external hardware control such as an exosceleton. (but keyboard keys will do for now)
2. manipulate and interact with the object rendered (grab it, etc.) in the environment with again hardware interface (but will use a mouse interaction for now)
3. render an arbitrary object (but that's for later research)

Those are the three major considerations in deciding what toolkit to use.:)

So, do I use GLFW which was made for OpenGL, had a new release this 2010, but some do not recommend it for complex applications.

OR FLTK or SFML (I don't know the difference between the two honestly), which are modern alternatives to SDL.

For me, any would do because they are all good choices but I would just like to have some comments for weighing them out. What would be best for what I would want to do... I've been researching for some time and since I'm a newbie, can't really pinpoint strengths and weaknesses. If you could suggest other toolkits I did not mention or don't know, please advise:D

Thank you very much.

Quote:Original post by Scourage

Your three criteria, although interesting, really don't have anything to do with these libraries.

Hi,

Really? I assumed that it had to do with the libraries because I would be getting inputs and rendering them on the screen:) Do you mean that I don't have to use these libraries in my implementation?

Quote:Original post by Scourage

Your criteria all exist at a pretty high level, these libraries are fairly low level in most architectures.

What do you mean high level? Doesn't my criteria operate on the low level OpenGL itself? :)

Quote:Really? I assumed that it had to do with the libraries because I would be getting inputs and rendering them on the screen:) Do you mean that I don't have to use these libraries in my implementation?

Libraries such as GLFW, SDL, and SFML should all do an adequate job of handling user input, so there's nothing of particular interest there. The only consideration would be if you have unusual input requirements. I'm not sure what the hardware interface you refer to is, but you'll probably want to make sure that whatever library you choose will be able to accommodate it.

Regarding graphics, no, the choice of windowing API doesn't really matter. Each of the APIs mentioned can create an OpenGL context, and that's all you need; the rest is up to you.

As for having to use one of these libraries, you certainly don't *have* to, but it will most likely make things easier if you do.

Of course, if you'd like to be able to work with the graphics at a higher level (that is, without having to write a lot of low-level OpenGL code), you could use a higher-level game or graphics engine (e.g. Ogre, C4, Unity, etc.).

Quote:What do you mean high level? Doesn't my criteria operate on the low level OpenGL itself? :)

None of your criteria has anything in particular to do with OpenGL itself. The first two criteria are hardware/programming issues, and the third (rendering an arbitrary object) is a general requirement that can be met by any API that facilitates 3-d rendering (that is, there's nothing about the requirement that requires any special consideration with respect to OpenGL).

Quote:Original post by jyk


As for having to use one of these libraries, you certainly don't *have* to, but it will most likely make things easier if you do.

Of course, if you'd like to be able to work with the graphics at a higher level (that is, without having to write a lot of low-level OpenGL code), you could use a higher-level game or graphics engine (e.g. Ogre, C4, Unity, etc.).

By "you don't have to" you mean I could display the OpenGL scene without these toolkits? I read that OpenGL doesn't have those functionalities natively.

Quote:The first two criteria are hardware/programming issues, and the third (rendering an arbitrary object) is a general requirement that can be met by any API that facilitates 3-d rendering (that is, there's nothing about the requirement that requires any special consideration with respect to OpenGL)

I understand this a bit, that OpenGL concerns itslef with the rendering not, the ones I mentioned, that's why I was wondering, with the criteria I mentioned, would it be better if I use GLUT, SMFL, or FLTK?:)

Quote:By "you don't have to" you mean I could display the OpenGL scene without these toolkits? I read that OpenGL doesn't have those functionalities natively.

Sure, you could display the OpenGL scene without one of these toolkits, by (e.g.):

1. Using a graphics or game/interactive engine such as Ogre, Unity, etc.

2. Writing whatever native code is required to get an OpenGL context up and running.

Going with option 1 might save you some development time in the long run (depending on what you're doing exactly). As for the second option, if you need to target multiple platforms (e.g. Windows and OS X), using a cross-platform toolkit will almost certainly save you a lot of time. If you're only targeting one platform, it'll still save you time, but likely not as much (if you're targeting only Windows, for example, you could just write native WinAPI code, which is well documented and for which there are many tutorials floating around online).

My own recommendation would be to use the highest-level tool you can that will meet your requirements (where 'requirements' could refer to feature set, budget, target platforms, and so on).

Quote:I understand this a bit, that OpenGL concerns itslef with the rendering not, the ones I mentioned, that's why I was wondering, with the criteria I mentioned, would it be better if I use GLUT, SMFL, or FLTK?:)

I would choose SFML over GLUT; FLTK I'm not familiar with.

That said, any decent windowing/events API (e.g. SDL, SFML, GLFW, etc.) will do the trick. The only real 'gotcha' I can think of is the hardware interface you mentioned; if it's something unusual, you'll want to make sure that whatever input API you choose can accommodate it.

Does that clarify things at all?

Hi,

Thank you very much, yes it did clarify things for me. I'll do more readings on ogre and if it has the capability to handle the inputs that my project requires then I'll go with that:)

I made a mistake though, instead of putting GLUT I meant to put GLFW, so do you still choose SFML over GLFW?:)

Quote:I made a mistake though, instead of putting GLUT I meant to put GLFW, so do you still choose SFML over GLFW?:)

I only have limited experience with each, so I really couldn't say.

Really though, I would just pick an engine or library that meets your requirements and move forward. Also, it seems the input issue you mentioned is a pretty clear requirement, so I would start by eliminating APIs that don't meet that requirement. You should then have a shorter list, which should make it easier to choose.

I would recommend GLFW.

It's simple to use and integrate, and you can always easily replace it with something else if desired (it doesn't tie into your code too deeply). Or you can modify its source code if you need to change something.

It also has a very clean API/interface imo.