Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Graphics Software Programming Technology

Irrlicht - Fast Realtime 3D Engine 221

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."
This discussion has been archived. No new comments can be posted.

Irrlicht - Fast Realtime 3D Engine

Comments Filter:
  • game applications (Score:5, Insightful)

    by Anonymous Coward on Saturday September 18, 2004 @03:05PM (#10286018)
    This is neat and all, but they need to make a complete game with it. Without the game, the engine developers don't really know what game developers need, thus insuring that it's never used in commercial games.
    • by pmjordan ( 745016 ) on Saturday September 18, 2004 @04:28PM (#10286535)
      That's somewhat true. I've selected Irrlicht for graphics in our project, and although it's better than most other engines out there, it's still a pain to integrate into a game and still make it be replacable.

      The problem with all game-oriented graphics engines I've seen is that they do more than it says on the box. They handle input, XML parsing, file handling, etc. and you end up re-implementing a lot of stuff to tie it in with your code unless you let yourself depend completely on the engine in question.

      ~phil
      • I'm a little confused. How does this force you to do more work than if they hadn't done file handling, XML parsing? Why can't you just rip out the parts that you don't need or have implemented yourself. Also I don't see why you can't just let the engine handle it's files and use your code to handle your own files.

        Furthermore, if the engine is done correctly why not just rely on it for things like file access. Either it, or the library it relies on, will provide a simply method to access the direct cont
        • Re:game applications (Score:5, Interesting)

          by pmjordan ( 745016 ) on Sunday September 19, 2004 @05:23AM (#10289745)
          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
  • by Anonymous Coward on Saturday September 18, 2004 @03:08PM (#10286043)
    There's another OS 3d engine called crystal space 3d [sourceforge.net]. It's been in development FOREVER now, and I'm still waiting for a completed cross-platform game, but it looks like a cool proejct. Anyone feel like porting this [planeshift.it] to mac?
    • Have you ever tried to work with crystal space or looked at the source code? Last time I did (several years back) it was one of the biggest messes of code that I've ever seen. I gave up on it too soon to understand it very well, but from what I could see, it was not designed very well and was consistantly a few steps behind commercial engines. On the other hand, it seems that Irrlicht is well designed and should scale well over time. It also appears to have developers that are making progress much faste
      • by Jorrit ( 19549 ) on Sunday September 19, 2004 @12:51AM (#10289093) Homepage
        If you think CS is not well designed and bloated then you don't really understand the structure. CS is very modular so while indeed we have a big source base, all of those modules are more or less independent. They result in plugins that can be loaded dynamically in the game. It is VERY easy to make a trimmed down version of Crystal Space where you simply remove the plugins that you don't want.

        As to design. CS is complicated to use (I agree with that) but the design of CS is geared towards flexibility (both for the game writer and also with regards to supporting new advanced features of modern 3D cards).

        Of course, I'm the original creator of Crystal Space. So take my opinion with a mountain of salt :-)

        Greetings,
    • by Kristoffer Lunden ( 800757 ) on Saturday September 18, 2004 @03:51PM (#10286300) Homepage
      We've been looking at Crystal Space, as well as Irrlicht and others such as the Nebula Device [sourceforge.net]. In the end, we ended up buying licenses for Torque from GarageGames [garagegames.com], 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! ;-)
      • by Tet ( 2721 ) * <slashdot@astrad[ ].co.uk ['yne' in gap]> on Saturday September 18, 2004 @07:14PM (#10287470) Homepage Journal
        In the end, we ended up buying licenses for Torque from GarageGames

        I've always wondered why there seem to be so few (any?) licencees of Croteam's Serious Engine [seriousengine.com]. 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?

        • That's cause SeriousEngine and Torque are completely different leagues. One Torque license is only $100 (with no royalty!), when the most limited SeriousEngine license is $20,000, and which includes high royalty rate, NO updates, and NO technical support. They are completely alienating hobby/indie developers who have less money to spend on a car let alone an engine. They are alienating professional developers too who have a $10 million dollar budget and who would pay the extra $100k for a better engine. Hen
        • 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.

          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, b
    • Crystal Space is well designed, it just takes some getting used to. It's extremely OO. It's bloated somewhat. You need to have it handle all your variables for you etc.

      However it's extremely powerful, and kicks the ass out of this engine from my impression. The existing renderer isn't too good, probably about the standards of this one, but their new renderer is capable of cel shading and bump mapping [sourceforge.net] to make Doom 3 envious. And as the poster pointed out it's behind a relatively big-name [planeshift.it] OSS game. Although
  • by dsanfte ( 443781 ) * on Saturday September 18, 2004 @03:08PM (#10286044) Journal
    Most open-source 3D engines are undocumented messes thrown together in the spare time of otherwise gainfully-employed graphics programmers.

    Ever tried coding with Genesis 3D? The documentation is shit. Take for example the explanation for the "GoEngine" function:

    GENESISAPI geBoolean geEngine_Activate(geEngine* Engine, geBoolean bActive);


    This seems to have something to do with whether the application is the current Active application.


    Yeah, hey guys, it seems to have something to do with something! Let's code with it! For fuck's sakes.

    Show me a 3D engine with reasonably documented code and I'll jump at it. Until then, you may have all the features in the world Mr. Engine Programmer, but if I can't pick it up and start doing something meaningful within an hour, you've failed miserably at your primary task: making sure the engine is actually usable.
    • by int2str ( 619733 ) on Saturday September 18, 2004 @03:14PM (#10286089)

      I guess Irrlicht is pretty good then...

      Irrlicht Documentation [sourceforge.net]

    • by thrill12 ( 711899 ) * on Saturday September 18, 2004 @03:18PM (#10286113) Journal
      ...and download Irrlicht 0.7. In it, you will find "Irrlicht.chm", which starts with (I quote):
      Welcome to the Irrlicht Engine API documentation. Here you'll find any information you'll need to develop applications with the Irrlicht Engine. If you look for a tutorial on how to start, take a look at the homepage of the Irrlicht Engine at irrlicht.sourceforge.net or into the SDK in the directory \examples.

      The Irrlicht Engine is intended to be an easy-to-use 3d engine, so this documentation is an important part of it. If you have any questions or suggestions, just send a email to the author of the engine, Nikolaus Gebhardt (niko (at) code3d.com).


      In the documentation are the classes explained in a quite clear and concise manner, in JAVADOC-style.

      I'm sorry, but some 3D-engines do think that documentation is important, so I guess your 3D engine with reasonably documented code is already here....
    • Some other people have replied to the documentation issue. Irrlicht seems to be quite good in that department.

      However, the question in the subject is a valid one.

      What makes Irrlicht different or even better than other libraries? Anyone here with some practical experience who can shed some light on that?
    • Looks like you were so eager to get your "insightful" comment posted that you didn't even have time to read any of the links or look around. For fuck's sakes.

      You may be smart and angry, Mr. Slashdot Commenter, but if you can't read any of the articles before ranting about something, you've failed miserably at your primary task: contributing to a meaningful discussion.
  • by Anonymous Coward on Saturday September 18, 2004 @03:08PM (#10286047)
    3D Realms issued a press release saying that they had standardized on it for the final engine to be used in Duke Nukem Forever

    When asked whether the move to Irrlicht would interfere with the work already done since their announcement last week that DNF had standardized on the Mario Party 6 engine, 3D Realms declined to answer, instead apparently becoming distracted by and taking chase after a rabbit running through the grass nearby
  • by g-to-the-o-to-the-g ( 705721 ) on Saturday September 18, 2004 @03:09PM (#10286056) Homepage Journal
    Its about time. The OSS community definitely needs something like this, which hopefully could eventually lead to some high-quality GPL'd games and such. The current profolio of gaming on Linux isn't very impressive in comparison to Windows or even Mac OS. Hopefully this will also encourage companies to ports their games to more platforms (like Linux). I know fellow gentoo'ers would appreciate this. As much as I love Linux, it lacks seriously in the gaming department.
    • Karma whore? (Score:2, Informative)

      by p3d0 ( 42270 )
      Not really. There are already several open-source 3D engines like OGRE [ogre3d.org] and Crystal Space 3D [sourceforge.net].
    • Re:OSS needs this. (Score:2, Insightful)

      by Mskpath3 ( 764785 )
      Don't count on it. The 'engine' bit of 3d games these days is frankly only the tip of a very very large iceberg when it comes to an actual game. Yes, it's high profile and it attacts the fanboys - but it's a triviality compared to the actual work involved in designing and finishing a fun game. Games are starting to regularly cost $15 million to make with teams of 50-100 people or more. It doesn't matter if you've got the latest and greatest (until 3 months from now) tech - if you don't have the army of arti
  • Will It Last? (Score:4, Insightful)

    by chesp3 ( 749548 ) on Saturday September 18, 2004 @03:10PM (#10286060)
    I came across this engine once while looking for a good 3D engine for one of my games. It was great but people are afraid of the "iron fist" developer.

    Apparently the engine has only one developer who can supposedly drop the project at anytime. Probably not likely though. Maybe there are more developers now, this was weeks ago.
    • Re:Will It Last? (Score:3, Informative)

      by yeremein ( 678037 )
      Apparently the engine has only one developer who can supposedly drop the project at anytime.

      Even if that happens, you have the source code, so you can maintain it yourself.

      Granted, if the project went under you wouldn't get any new bug fixes or patches, but for what you paid for it ($0), what can you expect? :)
    • Re:Will It Last? (Score:5, Informative)

      by Mike deVice ( 769602 ) on Saturday September 18, 2004 @03:36PM (#10286219)

      My understanding is that the developer simply didn't wish to put his code into CVS or the like until after a version 1.0 release. Some other people at Irrlicht NX [mmdevel.de] decided to take the source, stick it in CVS, and apply patches and fixes and the like. The author had zero problems with this, and even lauded the effort.

    • Nikolaus Gebhardt, the developer in question, wants to make all the architectural decisions and do all of the development until the engine hits 1.0. That's fine. That is a very viable method to secure the vision of an open-source project.

      Fear that the project will be abandoned is mostly unfounded. It is released under a libPNG style license and may be branched at any time.

  • by noselasd ( 594905 ) on Saturday September 18, 2004 @03:19PM (#10286116)
    Just wanted people to realize the diffrence here. irrlicht is is
    a 3d engine, which is about putting things on screen.
    For making a full game, much much more is needed. Player control/input
    handling, level loading when needed, loading saving of progress. Physics. AI. And , well, a _whole_ lot of other code. Plus some amazing
    artists and a good way of dealing with content made in 3d party applications(modellers)..
    • by mcc ( 14761 )
      Why would anyone use Irrlicht instead of SDL? Or would it make sense to use both?
      • SDL is quite a different library then irrlicht. SDL let's you setup a window, etc. But you still have to do drawing yourself. With irrlicht you load a level, and let irrlicht draw it. So, it makes sense to uyse both: irrlicht could use SDL to setup a full-screen window. SDL is also *very* portable, so then irrlicht could esily be ported to osX, BSD, amiga, playstation, etc.
      • Why would anyone use Irrlicht instead of SDL? Or would it make sense to use both?

        SDL only gives platform independent access to sound, mouse, keyboard, joysticks, and 3D graphics through OpenGL. You have to develop your own 3D-engine using OpenGL when using SDL. Irrlicht saves you from that hassle. So combinig SDL and Irrlicht makes sanse, since they cover different areas of a game.
    • RTFA (Score:2, Informative)

      by alexborges ( 313924 )
      Check the screenshot section to see what this thing is doing NOW (actually, some of this features are there for almost a year now):

      - Here are some shots of new features of the development version of upcoming Irrlicht 0.5: The .x file loader, new GUI features, the improved .bsp file renderer, new material types, fog.

      - These shots show the development of version, 0.4.2: Ultra realistic terrain rendering, indoor rendering using the new high quality texture loader, some new features of the user interface syst
    • The most important feature of a commecial game engine is the maturity of its game development tools, eg an editor, scripting system, and object management system.

      If you don't have a solid development framework there's no way you can begin to make a successful game with it, because your artists can't begin to make real game content with it.

      This code has to be mature because you don't it breaking whenever an artist or designer tries to create something awesome. Typically one of the major benefits you get w
    • For making a full game, much much more is needed. Player control/input
      handling, level loading when needed, loading saving of progress. Physics. AI. And , well, a _whole_ lot of other code.


      Indeed, and sound, which I can't find any mention of on their website. Sound is often overlooked - consider how effective in creating atmosphere the advanced sound engine in Doom3 was, it made a significant difference to the feel of the game.

      If you're looking to make a game I'd usggest you consider tenebrae2 [tenebrae2.com] which is a
  • Can anybody who's used both OSG and Irrlicht talk about a few of the more important differences they've noticed?
  • I've been dabbling a bit so far. I haven't quite updated to 0.7 yet, however from what I've cooked up it is fairly intuitive. The API documentation is derived from the C header files nearest I can tell. With just about 30 minutes to an hour I had a terrain with some public domain tree models textured and such. I had dabbled with Ogre and CrystalSpace with limited success. Irrlicht has a very nice feature set and a pretty decent software renderer.
  • Engine lacks... (Score:5, Informative)

    by SynKKnyS ( 534257 ) on Saturday September 18, 2004 @03:31PM (#10286184)
    Doesn't seem to have normal mapping (bump mapping and its cousins) or portal rendering (and all of its cousins). This doesn't make the engine very modern. It also seems to be lacking in the shaders department.

    However, it is open source so stay tuned in the future!
    • Re:Engine lacks... (Score:4, Informative)

      by Anonymous Coward on Saturday September 18, 2004 @05:19PM (#10286806)
      Doesn't seem to have normal mapping (bump mapping and its cousins)...

      Bump mapping and it's cousins are generally implemented using vertex and pixel shaders, which the Irrlicht Engine supports.
  • Check out the tech demo for irrlicht. Look at the shadows on the running model as she passes by the light source. Irrlicht is still incapable of loading smoothing groups from 3ds models (so all models are unsmoothed). .x format is purported to be the best for irrlicht, yet irrlicht can't load most types of .x format. Why would anyone want to use this ugly engine?
  • ...wake me up when we've got some hardware raytracers

    Regards
    elFarto
    • Re:Bah... (Score:3, Funny)

      by Maljin Jolt ( 746064 )
      Wake up! You have two of them just at the front side of your head.
    • ..but how does raytraced Quake 3 [uni-sb.de] grab you?
    • I saw a few papers presented at EG2004 this year where people had implemented ray tracers on GPUs (the nVidia SDK even includes a simple one). While the performance isn't quite there yet, it's certainly promising. The down side is that both nVidia and ATi stated that they weren't interested in moving to a ray tracing approach, since they felt it would always be slower and harder (although this could be good news for any start-up that wants to make ray tracing hardware...)
  • by ShatteredDream ( 636520 ) on Saturday September 18, 2004 @03:32PM (#10286194) Homepage
    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.
    • rotfl (Score:3, Funny)

      by jbellis ( 142590 )
      "If PERL 6 and Parrot are able to get really mature in the next 6 months to a year"

      perl6 won't even be beta within a year.

      *cough* vapor *cough*
    • Parrot already has SDL bindings, and it should be relatively easy to add in anything that has a C API, thanks to NCI [parrotcode.org].

      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, a
      • Modern games will always try to max out your CPU/GPU.

        Not true, especially on the PC where you can't assume people have the latest and greatest CPU and graphics card. I think this would be better phrased as "games whose authors decide that maxing out your CPU/GPU is a priority will do so." That really only covers a handful of games. Even DOOM 3 doesn't max out a 3GHz Pentium 4 with a Radeom 9800. (Yes, it has crazy settings that look 2% better and saturate the system bus, but turn them off and you're f
    • Python has several game library bindings available -- PyOpenGL is good as well as a low-level package.

      SDL is available, etc.

      I'd prefer to write games in Python with platform-specific libraries available as modules for CPU-intensive sections. Of course, if a library for the current platform wasn't available, you'd just run in native Python mode instead.
    • This is sort of what I'm working on with my JiggleScript [jigglescript.com] project. If you're interested, check it out. It is very early in development, of course, but I've been spending a ton of time on it lately rewriting it with a new modular design.

  • by Anonymous Coward
    http://www.code3d.com/blog/

    And say an amen to his entry regarding linux and windows.
  • by KrackHouse ( 628313 ) on Saturday September 18, 2004 @03:51PM (#10286299) Homepage
    Irrlicht is good because it's easy to use. If you want a high performance engine for use in a serious project have a look at OGRE. [ogre3d.org] Sure it's harder to use but it has an active community and the performance in complex, real world scenarios is great. I looked at both when researching what to use for Motorsport and right now, OGRE is a better choice for big serious apps. We're using OGRE for our open source driving simulator and it compiles in Linux and Windows with no changes to the code. OGRE is good because it sticks to what it is good at, 3D. There are a lot of Game engines out there that try to be all things to all people but aren't good at any of them. OGRE is good at 3D.

    That said, if you're new to 3D Irrlicht is a good place to start.
    • by Mawen ( 317927 ) on Saturday September 18, 2004 @05:14PM (#10286786) Journal
      I second the advice to take a look at Ogre. Ogre has an very clean, well designed, and stable API. (Especially compared to some other engines. I for one found it many times easier to understand and more organized than Crystal Space when I stopped following it a couple years ago.)

      While Irrlicht may be designed to provide a very nice and quick API for beginners to 3D programming, Ogre has seemed more professional to me. As a graphics engine, Ogre seems top-notch in terms of performant implementation of bleeding edge features that won't run on anything less than the latest generation video cards. (I have not really taken a close look at Irrlicht since about version 0.5 though.)

      There have been at least a couple commercial games released (an arcade machine and some game appearing on Finnish television) done with Ogre.

      I think that because it is new, and maybe because it is a graphics engine and not a game engine, Ogre has been getting less press than it may deserve. Anyway, be sure to check it out.

      Also, don't judge an engine by their demo screenshots. Open source authors often don't have the resources to make beautiful artwork to dazzle people with (nor do they have the financial incentive to do so).
  • Here is a screenshot of the engine at work:
    wip9.jpg [theshower.nl]

    can you release a binary or any compiled source, even if "alpha" or worse, under the GPL without the source? That's what he claims to have done (you cannot obtain the source for the current development, nor could you in the past)
  • Crystal Space 3D (Score:5, Informative)

    by myspys ( 204685 ) on Saturday September 18, 2004 @03:53PM (#10286320) Homepage
    Another engine that is open source (LGPL) and possibly a bit more mature than Irrlicht is Crystal Space 3D.

    From the about us-blurb "Crystal Space is a free (LGPL) and portable 3D Game Development Kit written in C++. It supports: true six degrees of freedom, colored lighting, lightmapped and stencil based lighting, shader support (CG, vertex programs, fragment programs, ...), mipmapping, portals, mirrors, alpha transparency, reflective surfaces, 3D sprites (frame based or with skeletal animation using cal3d animation library), procedural textures, particle systems, halos, volumetric fog, scripting (using Python, Perl, Java, or potentially other languages), 16-bit and 32-bit display support, OpenGL, and software renderer, font support (also with freetype), hierarchical transformations, physics plugin based on ODE, ... See the extensive list of features [sourceforge.net] for more details."

    Read more at http://crystal.sourceforge.net/ [sourceforge.net]
  • Easy To Use... (Score:4, Informative)

    by md81544 ( 619625 ) on Saturday September 18, 2004 @03:59PM (#10286358) Homepage
    I'm impressed. Downloaded the 0.7 zip file from the site (it was the only download available). I thought... well, this must be the windows version (I'm on Linux FC2), but I'll have a look at the code anyway. Unzipped it, realised it was for Win and Lin, looked for a "configure" script, couldn't find one, so just ran "make". All compiled without a single problem. Then went to the examples and compiled all those, again just with a make, everything ran OK. It seems pretty solid. I think this is going to be great.
  • a gamers POV (Score:2, Insightful)

    by j.a.mcguire ( 551738 )
    I'm a gamer and that looks like ass. you'd have thought if the demo was capable of it, they'd have come up with something amazing to demonstrate the engine. It's impressive in what it is, an open source cross-platform engine. But it's certainly not competitive with proprietory engines.
  • 3D games require a significant about of art assets. Don't waste your time starting out on making a game with this or any other 3D tech unless you have a solution to this problem.
  • Picture Quality... (Score:4, Insightful)

    by i-Chaos ( 179440 ) on Saturday September 18, 2004 @05:12PM (#10286778)
    I have been following the releases of Irrlicht because I've been looking for a good 3D Engine that's easy to use. The only problem that I've found with the Irrlicht Engine is that things just don't look so good, and have a gritty look to them. I don't know what is the problem, but I haven't seen any "nice" renders of anything using Irrlicht yet. Nothing production quality, anyway.

    • by wazlaf ( 681158 )
      I don't understand all the excitement about Irrlicht - wile it is surely an OK 3D Engine, it lags just so much behind in terms of what's possible with current 3D Hardware. If you are looking for something more advanced, have a look at OGRE [ogre3d.org]. It does decent stencil shadows, is also independent of the underlying rendering API and it is used in many commercial and open source games.
      • "If you are looking for something more advanced, have a look at OGRE."

        Irrlicht as at least one advantage: what it does just works. The same can't be said for OGRE.

        This isn't a commentary on the relative power of the two engines. For the sake of argument, I will stipulate that OGRE is light years more advanced than Irrlicht.

        I downloaded Irrlicht and ran the technology demo. It just worked and gave me a good benchmark of what it could do. It's library was precompiled for Linux, so I didn't have to both
  • by Anonymous Coward
    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.
  • Freshmeat is that you?

    I hope they improved the renderer, as it used to have poor performance and poor visual quality.
  • OGRE3D (Score:4, Informative)

    by ggambett ( 611421 ) on Saturday September 18, 2004 @06:00PM (#10287053) Homepage
    Our current project uses OGRE (http://www.ogre3d.org). We evaluated Irrlicht, CrystalSpace and others, which are good, but you defintely want to take a look at OGRE.

    OGRE doesn't try to be a game engine - just an Object-oriented Graphics Rendering Engine. It can be easily integrated with other libraries to create a complete game framework - ODE for physics is a quite popular choice.

    OGRE itself focuses on a clean and well designed API, while other engines are just hacks over hacks. It also has a very knowledgeable community and a very involved project leader.

  • "Powerful, customizeable and easy to use 2D GUI System with Buttons, Lists, Edit boxes, ..
    2D drawing functions like alpha blending, color key based blitting, font drawing and mixing 3D with 2D graphics."


    Irrlicht offers a GUI toolkit [sourceforge.net]. How about a window manager, so we can finally have realtime 2D objects like documents, lists, pictures and component GUIs, in a 3D space (not just Z-buffered)? I'd love to be able to stack tabbed windows in bundles, and turn them on their side (rotating around the Y axis),
  • by skids ( 119237 ) on Saturday September 18, 2004 @06:37PM (#10287281) Homepage
    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.

    • Realtime in the context of 3d rendering engines means that it's intended to be able to render a scene at a number of frames per second - thus allowing changes to the scene in Real Time - ie. immediately.
      In other words, it's a 3d Engine suitable for use in a game, or other interective software.
      The alternative is a batch renderer, where you would start it going, and then walk away.

      The phrase "Real Time" is absolutely not limited to the applications you seem to think it is, and has a wider meaning that extend
  • Another one?? (Score:5, Informative)

    by Saville ( 734690 ) on Saturday September 18, 2004 @09:09PM (#10288060)

    There are quite [devmaster.net] a [849pm.com] few [tu-berlin.de] 3d engines out there. The biggest I guess are Crystal Space 3D [sourceforge.net], Genesis3D [sourceforge.net], OGRE [ogre3d.org], Toque [garagegames.com] (Tribes2), Quake and Quake II [idsoftware.com]. Of course there are others to fill certin niches like Yeti [theteahouse.com.au] or ExoEngine [exocortex.org] and libraries like DevLib [devlib-central.org] and G3D [sourceforge.net] for those who want to write their own engine, but don't feel like they need to implement yet another file loader. I'm not sure why 0.7 of Irrlicht was worth mentioning on /. as it is isn't clear what its roll is compared to those other engines.

    I was at Siggraph 2004 and attended a round table on "how will you (game developers) feed next generation games". The problem is going from a Playstation1 to Playstation2 many developers found games now took roughly 2 to 3x the man years to create. But profits didn't really go up that much to compensate. This has happened every console generation and will happen again with the up coming generation. PC games don't have clear generations, but the same concept applies.

    The main ideas were to reuse content. For example if you're making a Matrix game, get the 3d models from the movie instead of making your own and start from there. Or if you're making a port try to reuse as much as possible. Future games will have a lot of computer generated stuff which is artist guided instead of artist created so that one artist creates a forest instead of creating a bunch of leafs on a single tree.

    A big surprise to me was open source wasn't mentioned until somebody asked. A company like id will implement something cool like unified lighting for all objects first, but a year later everybody has their own implementation of it. Every year has something like this that gets the anual lens flare award; colour lighting, ground clutter, normal mapping, rag doll physics, etc. Yawn. Every company spends all this time re-implementing the exact same technology. All developers can read the same papers from Siggraph, Eurographics, or GDC and then discuss them on the same mailing lists so there is plenty of open sharing happening already. So I was surprised to hear none of the guys at the round table thought open source would really be useful to help save them money in the future other than for rather basic things like zlib, lua, etc.

    It sure would be nice to see some engines reach commercial quality to used in some good games instead of getting more and more re-implementations of the foundation, which /. apparently is finds interesting. Once it happens there will be a huge snow ball effect where it picks up a LOT of developer attention. Maybe in five years one of the existing engines will reach a level of maturity that it can start to be really used and then in another ten we'll see it catching on like GNU/Linux is now?

  • I think they need to change the name. A product which sounds like "ear-licked" doesn't sound like it will become too popular.
  • The name is nice for a 3D project, translated to English it means will-o'-the-wisp, but it's all explained in the FAQ [sourceforge.net], including a wave file to explain the pronounciation (although featuring an Austrian accent).
  • I tried the demonstation program. It runs at 75fps until the female runner and jumper are displayed, then it drops down to around 35. Curiously, the character meshes seem to be antialiased and run at 10fps, when the world is not antialiased and runs at about 30-40 FPS when the characters are displayed.

    There are stencil buffer bugs when the shadows of the character meshes are hidden behind a partical effect such as the flames.

    I would not call this engine "fast" from the demo. Sure, the flyby ran at 75f

Real Users are afraid they'll break the machine -- but they're never afraid to break your face.

Working...