Slashdot Mirror
Irrlicht - Fast Realtime 3D Engine
Surye writes "Though a few days late on the release, Irrlicht has released version 0.7 of its engine. The site describes it as 'an open source high performance realtime 3D engine written in C++. It is completely cross-platform, using D3D, OpenGL and its own software renderer, and has all of the state-of-the-art features which can be found in commercial 3d engines.' Bindings for java, perl, ruby, and python, and it is platform independent (only implemented currently on Windows and Linux, but when it moves to other platforms, the code will be completely portable). The feature list is simply amazing, and since it's still being quite actively developed, I can see this becoming a major player soon."
Can anybody who's used both OSG and Irrlicht talk about a few of the more important differences they've noticed?
You are exactly right. There is an incredible difference between making a 3D engine and making a 3D game. There are already tons of free 3D engines out there, and how many of them can boast being used in a successful commercial game? Granted, open source 3D engines are fantastic for hobbyists and for learning from, but I think rarely are they robust enough, documented enough, and supported enough for serious commercial use.
Imagine if the parrot or mono guys wrote really slick bindings for this and made them availible on all supported platforms. Personally, I would rather have a game that is just "pretty" fast but isn't bound to a particular operating system to one that is really fast, but that I cannot take to any platform I want.
If PERL 6 and Parrot are able to get really mature in the next 6 months to a year, they owe it to their users to try to provide solid support for a library like this as part of the parrot distribution. A language like PERL 6 which is supposed to be really slick thanks to ruby's influence on its design would be great for opening up game development to the masses.
The way I see it, unless a game written in C/C++ is going to completely max out your CPU and GPU then it's probably worth being written in C# or PERL 6 eventually. Something like this would be Microsoft's worst nightmare for home users who play games a lot.
Click here or a puppy gets stomped!
We've been looking at Crystal Space, as well as Irrlicht and others such as the Nebula Device. In the end, we ended up buying licenses for Torque from GarageGames, because it has been used to do several games and it has lots of integrated tools built right into the engine. You can move and reshape just about everything inside the running game. Now, it is a bit dated, but there will be a newer version out hopefully soon with all those shaders the kids like. For now, it is definitely good enough for most people. Most people couldn't produce content to match the newest engines anyways... ;-)
;-)
Really, Crystal Space or the Nebula Device may be better in themselves, but if we were to use them, we'd have to recreate all these tools ourselves. Hint: if you are gonna do a game of any serious magnitude, you will need tools, and lots of them. If Crystal Space wants to start seeing games built, they should include starter kits (as in something simple to start modding instead of starting from scratch) and more importantly tools. Tools for manipulating terrain, creating particle effects, placing objects and so on. Being able to import stuff from Quark or Maya is not enough. DO you as a level designer want to place everything in your game by entering numbers in a text file? I thought not... =)
As for Irrlicht, I really like it a lot. It is cool, it is really, really easy to get something up quickly in, it has good performance and plenty of good examples to get one started. However, it is nowhere finished enough (but I can wait) and it is not a game engine - it is a 3D rendering engine that could very well be used to power an awesome game engine. I think some people over there are working on such beasts, though I don't know the status... if any of them also read this, remember the tools boys!
Spine World
The only other reasonable option is the Torque3D engine.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
Parrot already has SDL bindings, and it should be relatively easy to add in anything that has a C API, thanks to NCI.
:)
As for maturing, well, I'd consider parrot to be of at least beta quality; it isn't stabilized yet, and many things are still subject to change, but on the other hand, it promises to be at least on par with (and in some cases substantially faster than) php, perl, ruby, and python as far as VM performance goes.
However, Perl 6 I'd consider to be alpha quality; more of its design is in flux, and although there is a proof-of-concept compiler for most of it, the real one has yet to be written. Although you may or may not see Parrot get mature in the next year, I doubt you'll see Perl 6 by that time as well--although I wouldn't mind being proven wrong here.
Modern games will always try to max out your CPU/GPU. That doesn't mean scripting languages don't have a place in games, but critical portions of them, or their libraries (like a 3D rendering engine, heh) will probably stay written in C/C++. However, there are already games written in scripting languages, and some of them are quite fun.
pb Reply or e-mail; don't vaguely moderate.
For my game project we're considering using tv3d (http://truevision3d.com) which is actually cheaper than torque (it's $150 for a single project -- torque is about that price, but the price goes a lot higher if you start making serious money).
Does anyone have any thoughts about tv3d? Check out the features of the next version (new version), they look pretty nice for what I'm trying to do.
It's probably good to note that Irrlicht is entirely the work of one person. Considering that, it's pretty damned good, though not neccesarily at that "professional" level. I've done some little projects with it though, and its a pretty capable graphics engine.
People have to stop abusing this term. There's nothing in that API that even qualifies it as soft-real-time. Real-time APIs have runtime estimation, deadline scheduling, and other things that have to do with managing time.
Not that I'd expect it to be real-time given it doesn't require any real-time OS features, and not that I know anything about whether game developers can use real-time features, just a pet peeve.
Someone had to do it.
I've always wondered why there seem to be so few (any?) licencees of Croteam's Serious Engine. Are they just pricing themselves out of the market, or something? I mean, Serious Sam has proved that it's more than capable of getting the job done, and Serious Editor looks to provide all the tools you could want. So why aren't people using it? What made you choose Torque? What advantages did it have over the competition?
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Unfortunatly, it sounds as if this is incompatible with the GPL. I know it is a small sounding issue but the requirement that this notice cannot be removed or altered is an 'additional requirement' and disallowed by the GPL. It is just this sort of minor issue that is causing the problems between GPL and the...apache liscense (I think this is the right one).
If someone on the project is reading this may I suggest that the lisecensce be changed to add an additional clause. This additional clause would allow any liscensee the power to re-lisecence the source code under the GPL instead of this liscensce.
Sure, while it is *possible* this would cause a loss of attribution it is unlikely. A commercial project might have reasons to hide the origin of their code but a GPLed project has no motivation to lie and say their code didn't come from the community. Furthermore, it would be a big help to people trying to make GPLed games.
If you liked this thought maybe you would find my blog nice too:
A lot of it boils down to who you are and why you are getting an engine, and yes, price matters. If you are an indie, an hobbyist or an upstart, $20,000 (Serious Engine minimum) is still a lot of money, even if the engine itself is worth every buck. I wouldn't know if it is, I just skimmed the site briefly.
;-)
;-) But this Serious Engine? Dunno. Is it that good?
If you are someone who has investors backing you, or have a company with money in the bank... or at least someone with a contract with a publisher, you maybe can afford to shell out that kind of money, but is it worth it?
On the surface, it seems you are getting about the same deal as you get with Torque, which is $100 per programmer - so it would then be a matter of ease of use and results: Are the tools that much better and does the result look that much nicer that it will be worth it - and even more importantly, will it pay off in money returned?
But don't get me wrong, $20,000 is a drop in the ocean if we are talking about modern AAA games budgets, that is like what? What it costs to have a programmer for a couple of months maybe? So it may well be worth it to get that extra bang. However, if you have the money, why not step up a bit more and get an engine from Epic or ID or something? Sure, it costs quite a lot more, but you get to put "Powered by Really Known Engine" on the box.
I'k kinda guessing that they might fall between the chairs a bit: low budget productions and upstarts can't afford it, and it isn't cool enough for the big boys.
Also add to the fact that because Torque is so cheap, students and hobbysist can afford it, which gives a big and friendly userbase and community that helps each other out... and these guys can afford to do a demo level that can be used to sell the real game, which will use... Torque, probably, because that is what they know. They aren't gonna switch engine unless they land a deal that lets them buy one of the really big guns.
Or so I speculate. It isn't easy to be sure of anything, but those are my best guesses.
And am I happy we chose Torque? Yeah, mostly. What you get per dollar is simply unbeatable, even by the free alternatives, and the company has a sound take on open source, cross platform and indies. The engine sure has a lot of quirks, which hopefully will be sorted out with TSE, the next generation, but compared to doing all the tools ourselves or doing editing without them, it is a no-brainer.
Would I use the Unreal Engine instead if I could? Probably in a heart-beat, as long as I personally didn't pay for it.
Spine World
The point is that stuff such as file handling should be unified within the game, but everyone will have their own system. We use PhysFS to abstract everything within one big file tree. If you use PhysFS, you have to change, or, if you want to be able to upgrade to a higher version later without any trouble later, rewrite all the Irrlicht code that uses files, rather than writing some kind of plugin/implementing a generic interface.
XML parsing was possibly a bad example, but we've basically got two XML parsers compiled into the game right now. Irrlicht's XML parser would be a pain to get running with PhysFS, and it only works once the graphics engine is set up, at which point we'll actually have done a considerable amount of XML file loading already.
The problem with all this added functionality is that it's fairly laborious to work around if you don't want it, and it's quite likely that that is the case, because the way it's integrated into the engine isn't especially flexible.
Input handling is another one of these problems. We support keyboard and joystick input in our game. Because keyboard input is heavily tied in with the windowing abstraction, and thus the graphics engine, it seems sensible to put it into the graphics engine. It isn't that clever though, because you'd now have two seperate systems doing almost the same thing - the graphics engine doing keyboard input, and the input system doing joystick input. It's barmy!
I also shy away from anything but graphics being dependent on the graphics engine. If there was an Irrlicht file handling module, an Irrlicht Input module, and an Irrlicht graphics module, that would be great. If I decided to drop Irrlicht graphics I could still use Irrlicht file handling without having this behemoth sleeping in my source tree. As it is, I wouldn't even want to rely on loading sound files with the Irrlicht file system, because sound and graphics are, and should be separate.
It can certainly be worked around, it would just be a lot friendlier to make it inherently more extensible, for example by creating a very simple file handling interface, providing a standard implementation that uses fstream objects or whatever, but leaving you the ability to create another implementation to that interface which happens to use your file handling system of choice. Lots of C-based libraries use callbacks for this kind of stuff, and in C++, with polymorphism in the language, it should be even cleaner!
~phil