GUI Creation

I said GUI? I meant UI.
Sorry if this topic is not OpenGL related, but I thought this is the right place to ask about it.

Every complicated editor must have a complicated UI, and when using pure Win32 API, this is a lot of hard job (Even when using editor for the Dialog Boxes). How complicated 3D-editors like 3D Studio Max make thier UI?
Using MFC? Or third party programs like FLTK?

[This message has been edited by Quaternion (edited 02-05-2001).]

this decission is not only important for modelers. it is a general question for all interactive app’s like using the oo paradigm for a 3d-engine or not. every company uses the library they can best work with and that fits best to the target platform of the final software. under win-whatever, MFC is the most taken library. but if you want to be platform independend, you can use the QT (best lib ever, KDE is based on it) or java (slow). to create special widgets or windows not supported by your chosen lib, build your own classes and extend the available functionality. i think no one would start to code an own class library. there are sooo much alternatives.


This question opens up a huge can of worms…

In my experience, Apps like 3ds and Maya use proprietal toolkits and code libraries. I am willing to bet that on some level, there are relics of 3ds DOS in even the latest release of Max. Any software that has survived for a long enough time usually has twice the amount of support code that the app typically requires. When you decide to release a new version of your existing software, it’s usually easier to use the current product as the template then to adopt a new technology completely. So if you have 5 years invested in developing for DOS, aren’t you more likely to just port that code over to win32 rather than recode the entire thing using MFC?

As far as OO systems are concerned, I would recommend that everyone take a look at the Maya Plug-ins API. I’m not trying to sell Maya here, frankly I have very little artistic talent and whichever product my artist choses to use is the one I go with. Recently, however, I wrote a plug for that system and was totally impressed by the C++ archeticture. Just by seeing first-hand how their system worked from that angle improved the overall quality of my code, for any project, not just OGL or graphics related. I’ve got to hand it to them, that is one incredible system…

As far as saying “no one would create their own class library”, I’m not sure I’d agree. At work, I’d have to say this is the case, as the managers and execs just want fast results and met deadlines. But if you’re working on contract or independant work, I’d have to recommend this. While we’re not going to write our own version of GLU, many of the other toolkit/libs out there are too general purpose. I’d much rather have a scratch-built library that I know intimately in my toolbox than a collection of abstracted apis. But then again, I don’t remember the last time someone asked for my opinion, so I’ll shut up now :wink:


[This message has been edited by lpVoid (edited 02-06-2001).]

I think you’re right, lpVoid. Everybody who needs to meet a release time tries to buy all he can afford. Saw that at the guy I worked at to earn some additional money. However, at home I’ve got enough time to do it all myself, even if it takes months. It is most probably not as good as the commercial apis, but I don’t care. It’s my piece of work, and nobody has to ask “Where did you get that from?” “glut”, what is that “gtk”, and this here “font api from internet”. However I would also like to focus on the engine…

i think coding an own library for GUI’s is definitly not recommended. you have to deal with everything like eventhandling, windowdrawing, menus and so on. its completely another thing than making a toollib like GLU. a toollib should be optimized for your own needs, but a GUI class library cant be general enough. the case that you only need one window with one input dialog is very improbably (subject deals with “complicated (G)UI”). the most important point is not speed but stability and expandability.

i dont know exactly what quaternion means with UI. if its the code level between GUI and data retention (in my words - the application level) then it has completly nothing to do with libraries like MFC or QT except using classes like CData or CString. in this case you can and should develop your own code. but if the level is meant where and how the user inputs data (menus, windows, frames, dialogs,…) i dont moving beside my point of view (…and i cant believe that there resides dos code in the GUI level of actual 3ds releases).


Let’s say I want to create an editor. If I use MFC with OpenGL won’t it reduce the performance? I want an excelent performance even in my editor.

With MFC, or every other code library, I don’t have control on the message loop. That control is essential if you want good performance. isn’t it?

I don’t know many in-opengl-window systems that are available, where that is quite a really cool feature. You can have a registry editor in the engine, a text enditor, and won’t have to restart just to see changes at the script.

Also, I think 3dsmax 1 was completely rewritten. Where to use that old dos code? They have however the dos knowledge in it, and that is quite enough.

My company is a windows shop, and we use the MFC almost exclusively, and while on a desktop business app the performance hit is negligable, I would advise to stay away from it when dealing with graphics and other high performance issues. ( Ever tried to run a MFC app using REALTIME_PRIORITY_CLASS?? )

You can have complete control over the message loop in MFC, it’s just a matter of how far you’re willing to go. To be honest, however, I have never wanted to leave the realm of the standard win32 api.

I would agree with you in the fact that control over the message loop is vital for performance. Being able to process look-ahead data can make or break a system, and I have yet to find a general purpose toolkit that handles this exceptionally well.


michael: do you write your own OS or your own compiler? i think no. making own 3d engines and toollibs is ok and necessary for learning. but even here you are using graphical libs like OpenGL or D3D (better not). so you can push your creativity inside the application without taking care for the output of graphical primitives (triangles or windows). and there is no difference between coding a modeller (on top of QT) or coding a 3d engine (on top of OpenGL) at this abstract level.

i’m used to do as much as possible by myself (like you) as long as i’m interested in. i’m glad to be able to use libs keeping me away from coding stuff i don’t like.


There’s a basic difference between GK and an in-engine os-like system. You have multiple opengl windows with really multiple asynchron running apps in GK. You have only one app running in my attempt. There is no realy switching between windows, and you don’t have any problems when running in fullscreen mode. Actually I use glViewports() and OpenGL to draw the windows (if necessary). I can also just define #XYZ_NOWINDOWS, and here you go with a release build.

Yeah jabe, QT is probably the best cross-platform UI available. However, last I checked, they wanted $1200 for a Win32 license AARRGGHHH!!! Free for unix