vermeer wrote:conclussion: very few artists in this comunity. very few wanting to work for free in the whole world. And yep, the nice pics could be PERFECTLY done with an irrlicht of a bunch of versions older than the current, even. There's no hard limit to be unable to do kick ass games, graphically, with irrlicht. So , don't let the ...euh...pics... be your guide.
interesting, as i just figured that out a day ago.
i thought irrlicht suffers from it because of something else, and it turns out artwork from the creative people play a very important part in creating a realistic gameworld.
thanks for elaborating that, because i'm at that stage of development where i have to create so many textures for a gameworld i'm developing.
i've just created the gameworld contained in one blend file, and i'll be dividing them into sections, each section will be textured meticulously paying attention to the smallest detail.
What a lot of people miss, is that artists are usually all working for someone else, and by the time they get off work, some are just too tired to do anything. Some might be persuaded to work on a project on the side, but it normally turns out to be one of their own.
Just an observation I've had.
rogerborg wrote:Every time someone learns to use a debugger, an angel gets their wings.
Good luck with your product!
Hope we will see some W.I.P. Pics soon.
In my opinion the community advices whould help a lot.
@Saturn
I do know that Irrlicht is only a graphic engine.
But you can get a "complete" engine by adding free tools for sound, physics, network, modeling, animation, scenemanagement and so on.
My question refered directly to "Abilities of Irrlicht Engine regardind state of the art 3D", not Irrlicht as a whole gamedevelopment solution.
Nevertheless, thank you for your answer.
I do now understand, how the lack of "illusion" pictures influenced my mind.
Irrlicht is really powerfull and can by extended. That's the difference.
Like e.g. rogerborg already said Irrlicht is not perfect.
And I just wanted you to tell me some points you are not pleased with, regarding Irrlicht's graphical features.
Moreover, Irrlicht 1.5 will feature hardware vertex/index buffers, and hopefully also a fixed animated mesh handling. So two points will hopefully be remedied soon.
There hasn't been much discussion about ways to implement FVF style meshbuffers. So there's no clear picture, yet, about how and when this could be done. And there many are other things in the pipeline already which are, for now, higher prioritized.
Hybrid, now that you are here, and we are talking to graphics/art related features... Is collada or *.md5 planned to have full support? I was thinking on a format that can bring animated character meshes with normal maps...
Also, for lightmaps...We have b3d, a really good thing as irrlicht supports its lightmaps for levels and its character animation, but unluckily seems high end packages don't have support of b3d as much as some time ago... Max and Maya is used more than I thought by ppl around irrlicht...While probably a big percentage is using more and more blender, there will be allways a big numer using those other two, maybe xsi/LW in an smaller chunk. All those seem to share only a pair of things in formats, together with Blender... Collada(and FBX, tho fbx is not open sourced format. Blender also already exports it fully since recently, I understood ). is collada in irrlicht already supporting character animation? with normal maps ?
Are only questions...too much that we have the engine for free... But dunno, was thinking about it, that's it...
Raziel_n2gc: here's a sample pic of the dimensions of the gameworld. i still have up to march 15, 2008 to finish this for the conference i'm planning to attend.
i'm currently on demo #9 for this gameworld, though. and i still have a long way to go.
i'm targetting two 3d engines, just in case one of them doesn't deliver the other one will be dropped for this gameworld. irrlicht is the first and the second is secret.
I'm currently working on Collada 1.4 support. First thing will be better support for materials, next thing will be animations and stuff. However, the format has really become a complex matter since Collada 1.4, so many parametrized elements. But I'll try my very best to get it to work.
hybrid: I was about to start doing my own changes to the collada loader as I need to support the format as the Maya FBX Collada export writes it out. Immediately this means adding support for the "library_*" sections, then adding support for animations, and probably more as I try and support as much of the Maya export as my artist is using. Should I be trying to collaborate with your changes? Note; I'm working from the branches/releases/1.4 code base, as it seems to have the most recent collada support.
Raziel_n2gc wrote:Thanks JP, I was suprised of the lack of projects like this.
But Irrlicht offers all you need to create such things, doesn't it?
If you use Irrklang, a physics engine and so on.
Or is Irrlicht restricted in features, speed or something else?
By viewing the main page I thought something like "Wow, this one could be an AAA commercial Engine" If you use seperate modelingtools and so on.
Give me a SpeedTree license and an artist or two and I could do something like that. If I had the time.
The driving demos on my website took about three months, building a game engine from a blank project (3d engine, physics, sound, redefinable controls, menu system, etc).
Irrlicht has a non-restrictive license, comes with source code and is quite easily extendible. When I wanted MD5 support or a 100 animated+blended characters on screen, or any other stuff, I just added it.
grafikrobot wrote:hybrid: I was about to start doing my own changes to the collada loader as I need to support the format as the Maya FBX Collada export writes it out. Immediately this means adding support for the "library_*" sections, then adding support for animations, and probably more as I try and support as much of the Maya export as my artist is using. Should I be trying to collaborate with your changes? Note; I'm working from the branches/releases/1.4 code base, as it seems to have the most recent collada support.
The changes from branches are merged into trunk on a regular basis. So the support should be the same already. I'll add the collada 1.4 support to trunk only, because the changes are pretty huge and I don't want to break support of the collada writer meshes from irrEdit 1.4. But this is only important for the final check-in.
I have already a loader which supports several library_x sections. I'm currently trying to solve the partial scene instantiations. The problem is that I'd have to create several partial scene graphs for the visual_scene section, in order to instantiate from those. This is major overkill, so my next try will be to skip to the end of the file, read the visual_scene node in order to know the top scene to instantiate and avoid a large part of unnecessary instantiations. Still, full Collada support would mean to allow this, so we might need a better solution. I'll try to clean up the current version of the loader this weekend and add it to SVN soon, such that you can start from this code.
for so me reason every body is wanting collada support, everywhere... Dunno, I was a bit not fan of it at beguining, but is probably the best 1:1 from art content to engines. Still not sure in character animation case, I find md5 so optimal..
Give me a SpeedTree license and an artist or two and I could do something like that. If I had the time.
Give me just time as to have a second parallel life, and I would join fully any project. But am one-dimensional (old) guy yet
hybrid wrote:
Still, full Collada support would mean to allow this, so we might need a better solution.
Hm, I need to do scene node instancing (not directly collada related) and would need to add a special scene node to accomplish it (AFAICT Irrlicht doesn't already have instancing for whole scene nodes). So the collada scene instances could represented directly with that.
hybrid wrote:I'll try to clean up the current version of the loader this weekend and add it to SVN soon, such that you can start from this code.
Thanks. I'll check the trunk for when those changes appear
