Abstract
For solo-developer projects all of these graphics libraries are bad. The drawbacks are many, but varied between libraries.
The ideal solo development framework is a Linux or Mac development environment using all of the powerful Unix tools and open-source compilers and programmes. Development speed is much much faster in this arrangement; ideally you would develop on Linux and then recompile to more popular target Operating Systems.
After evaluation of all of these options, the one thing that becomes clear is that it is exceedingly difficult to develop reliable, up-to-date 3D programmes for Mac and Linux platforms, and cross-platform development hugely compounds the problems. The big guns; Ogre3D and Delta3D are ideal for my type of project in terms of packing a lot of graphics punch, but set-up and maintenance of these libraries on Linux/Mac is clearly an afterthought and has already wasted a vast amount of time that could have been used in more productive areas.
After several years experience with cross-platform Ogre3D and native Direct3D development one feature becomes desirable over all others - ease and small footprint of set-up (i.e. a library with very few dependencies). In this respect two options stand out - Irrlicht and jMonkey. Irrlicht is small, lightweight, super-fast and C++. jMonkey is chunkier (in terms of code verbosity and set-up), slower, and Java. Irrlicht is not quite up to spec with modern technology on all the machines that I've tried it on, but it's significantly faster and leaner than the nicer-looking jMonkey.
OGRE3D - http://www.ogre3d.org/
big, most powerful, ugly
the good:
- most modern feature set
- fast
- huge user community
- multiple platform support
- has a brilliant user-built terrain plug-in (ETM)
- a phenomenal amount of mostly unnecessary dependencies
- Linux is maintained, but not with enough support (lots of development time wasted on upgrades that break)
- horrendous overuse of pointers, STL, and C++ inheritance (the worst bits of C++) - this infects your own code
- native GUI support is abysmal, and user-built plug-in GUIs are worse
- mouse-picking (for selecting 3D objects with the mouse) worse than native DirectX
- is strictly graphics-only - a lot of time wasted with external plug-ins to perform extra tasks that are usually handled by DirectX
- code gets very bloated, and much time is spent on unnecessary engine-level programming
- scene node manipulation is too time consuming and over-complicated
- incredibly hard to maintain programmes for multiple platform deployment
- no useful linux packages (debs etc) available
- takes a fair amount of violence before it conforms to your architecture (tries to make you use its over-developed and extremely messy frame listener architecture)
- code a bit sloppy - doesn't conform to gcc-4.3 standard
military simulation framework
the good:- targets simulation development
- multiple platform support
- entire framework - sound, network (via HawkNL), physics, etc etc all integrated
- has some great design tools (mostly Windows based-though)
- lots of pre-built content ready to go (explosions, special effects, and other time-consuming bits and pieces)
- very refreshing attitude from developers (good documentation and support)
- outrageous number of useful plug-in components available (weather, animation, physics)
- brilliant terrain engines (including infinate procedural terrain)
- has a particle editor AND a very involved game editor tool
- has an extensive free library of military models and content, scenery, foliage etc
- incredibly involved to set up and compile (I'm 2 hours in and still going)
- uses the worst GUI system of all time (from my experiences with Ogre) - CEGUI
small, ridiculously fast, well written - perfect for small, quick projects
the good:
- even runs fast in OpenGl on the Asus EEE - this is the fastest 3D graphics library ever
- require no dependencies - just compiles in one go, on anything - total compiler support
- the best 3D GUI that I've ever used is integrated
- natively (without exporters or converters) loads just about every model format imaginable
- has a nice sound library plug-in
- very very good multi-platform support
- has some nice software renderers as alternatives
- a bit behind the lead in terms of the latest technology
- lots of extra plug-ins but they are mostly Windows-only
- lacklustre terrain support (relative to Ogre and Delta)
- also uses horrible frame listener architecture
like Irrlicht but newer and uglier
the good:
- easy to compile (although much bigger than Irrlicht), no dependencies
- has probably the best terrain engine and terrain design tools available
- has a capable GUI integrated (not having a good one is a huge development time waster...Ogre)
- huge selection of design tools (also a huge time-saver)
- messy
- very small community
Java
the good:- Java - just runs, on anything with Java. No dependencies. Works.
- Uses the Java Swing, SWT, and a 3D GUI (finally a decent GUI set)
- Incredible water and cloth effects built-in (see screen captures)
- Just runs - very easy to use and to distribute
- Easy to set up - just include the jar, good IDE selection available
- Wraps 2 Java OpenGl implementations
- There is an incredible terrain editor may be released for public use eventually
- Can make use of Java sound, music, networking, physics etc libraries
- Very good 3D picking, collisions and other high-level features not avail. in other libs
- Can be turned into Java Webstart applications
- Isn't Panda3D
- Is fast! Surprisingly
- Smaller community, poor documentation
- Code to do simple things like loading textures is overly verbose - far too many lines of code used for very simple processes (i.e. a wrapper would have to be custom-made, which defeats the purpose of JME itself being a wrapper)
- CPU-intensive code may be very slow if programmed in Java
0 comments:
Post a Comment