Feature requests for Irrlicht 0.7

[bappy]

it a little bit boring to ear always the same thing...
-adding more format...
-adding a scene format...
- more tutorials...

that s not part of the irrlicht core.

-adding more format:
WHY.......x it s the best format using in every package...

-adding a scene format...
DO IT YOURSELF....it s a text format, export all you need. each project have different scene format because they are not using the same data...
if someone is making an editor, they will be always someone to ask another thing because his project must have this thing...again...DO IT YOURSELF.

-more tutorial.
don t be a geek. actually tutorials are showing all the irrlicht stuff...why do you want more... oh yes, maybe you want a tutorial for making an fps from a to z which is a kickass game and can be sell etc...don t be silly and work instead of asking for someone making the job at your place

tired with this stupid asking stuff...

[Nessie]

it a little bit boring to ear always the same thing...
-adding more format...
-adding a scene format...
- more tutorials...

tired with this stupid asking stuff...

While I don't agree with your tone, I do agree with the content of your post.

Having the engine support every single format under the sun really doesn't add much value to the engine. In fact, there is a saying we have here that perfectly suits this type of development approach..."being a jack-of-all-trades and master of none."

...which roughly means, being able to do a bit of everything, but not really being able to do each of those things really well.

In other words, I think it's worth far more to maintain focus on improving the core infrastructure of the engine and let other people develop 'plug-ins' to support other formats if they really care to.

With that in mind, I really think the timing model of the engine needs an overhaul. The progression of time effects everything in a game, animation, movement, etc. And these things need to be done in a framerate independant manner.

The other big issue as far as I can tell is materials. I couldn't get a texture with an alpha channel to render correctly with the engine 'out of the box' so to speak. This seems like a very glaring short-coming.

So, I'd agree. Don't bog down the development of core features that actually have value to most anyone...especially with requesting fluff features, like formats.

Tutorials have value I think. If a person evaluating IrrLicht can do a quick demo for a project they have in mind by modifying one of the many tutorials. And if they find that they can easily use IrrLicht to do what they need, you'll find more and more people wanting to use it....and from there, you'll get more people able to contribute back to make the engine better for everyone.

Anyway, my $0.02 worth.

[patlecat]

+ I wish Irrlicht would catch up with a support for Cg. Unlike popular opinion, Cg is a platform independant standard now, so you can write for non-nVidia cards as well. Besides it is compatible with DX9's HLSL. So it's a good choice and would boost graphics on this engine.

+ Speed optimizations. When I compare scenes in other opensource engines, I feel Irrlicht can do a lot better here.

+ Full Q3 and RTCW BSP support. Not just the usual 30-40% feature support but at least 90-98%. There were some peeps like Plummi who began work on this but no one got anything more complete and stable out yet. It would make live of developpers so much easier when we could use more features.

[vermeer]

yep, actually, with the x format (after all was designed for games) can do for lots of stuff for character animation and levels...

And I am happy to tell you that i am reading in many gaming comunities it is becoming a widely used format; Even more, Gamestudio and Darkbasic pro (comercial softwares that have a paid team behind) tool much more time to get a working x file import..indeed, last thing I did check they don't import weights!!! How can...if the main advantage for artists about x file is that one...!

And I guess they just did not added it as is more complex. I have been informed by good coders about that (in general c++ and dx)

Is not that I am a MS supported or something.I'm an artist, and way more supporter of free ways, free tools, and most of all making artist life easier...or just making possible the conversions.

I read DBPro either supported weights, but that could be a wrong post of a user. Recently, Blitz3d added weights, a long cried petition from b3d users, and now some are realizing its power.

Besides...maybe *.x format of dx8.x does only support two materials overlayed, but what I read is dx9 version of x format (all the time I don't care about ms dx, but the *.x file format, which seems can be loaded as well in opengl in Irrlitch, deosn't it?) does support many materials overlayed. (multitexturing) I read in Panda exporter last update, support for dx9 multitexturing of more than 2...

Dont expect that happen with all exporters just now, but at least some will do. (Max 6 already) Blender is done by founders and comunity, it probably will get there.

I fully agree here...that part is covered more than in any other engine...(obj, ms3d, x, tga...wow..BSP keeps meaning issues (well, a bsp for hl is being done by a user, and that'd be interesting, but Niko do not have to care about it.. )) , and seems better to keep adding needed stuff to a game engine... (ai, etc... I suppose.I don't code)

But all this post of mine is a bit redundant, sorry.


Just to point you that the decission of choosing x format was very correct; I am reading everywhere engines are picking it...
hey, why not grab interesting things here and there... (like x format)

[Guest]

seems directx gets better treatment in irrlicht, for a free project such as this I'd say opengl should be a first choice renderer, because:

works on all platforms (not just windows), works with all compilers.

and also because (personal things):

has no bad micro$oft taste, seems to be more stable.

at the moment some stuff only works in directx and opengl always lags behind a bit in features, opengl is just as 'powerfull' as directx.

my request for future version:

BETTER OPENGL SUPPORT



(in fact, trash directx, yes thats right trash it, burn it...aarghahahahahaaaa (<- maniac laughter))

[atcdevil]

Just like how in STL, string has stringstream, it'd be neat if irr::core::string had an irr::core::stringstream ...

or at least if irr::core::string had some conversions like ToInt() ToDouble() ToFloat()

[Cleves]

What I really want is a simple add to the collition detection system.
Once, and object has collided with something I can find that object it collided with or I can activate an event on it.
If it's already possiable I can't find how to do and I would really appriciate if someone will show me.

[Unarekin]

What about separating rendering from animation in the SceneManager?

For instance, the scene manager's drawAll() function draws everything to the screen, and it animates the animators. Perhaps if these two functionalities were separate (In, say, an smgr->updateAll() and smgr->drawAll() ), it would allow for things to be 'rendered' in a console environment (By calling the updateAll() and never actually calling drawAll() ), as well as drawing the scene in a 'still frame' (Calling drawAll() without updateAll() ).

This is, at the least, something I want to add to my version of Irr. I lack the DXSDK, and I don't particularly want to just drop DX support.

That reminds me, I need to smack my friend about to see if he ever got around to downloading and burning that for me.

[stampsm]

yea i just downloaded the dxsdk and it was ~220mb. even on a cable modem it took me forever.

[faissal]

another Request

1D texturing

[AssiDragon]

I know it has been said alread, but I think some code optimalization would be nice.

Also, volumetric fog would be nice to add I think. And perhaps manipulating joints.

[disanti]

What Irrlicht needs? Faster functionality in OpenGL under Linux!!!

Linux sounds very promising for Irrlicht but when it runs at 4 fps, it is quite useless.
________
JUSTIN BIEBER FANS

[rogerdv]

Working XML support
Complete support for file formats. Maybe add md3/md5
Ability to get submeshes
Material scripts

[Tyn]

To the guy above: I have definatly got XML working for Integers, not too sure about strings.

One thing I would really like to see: A new material setup. At the moment, you set the meshes texture ( which is of type ITexture ). This is OK when you are only setting one thing but when it comes to doing things like bump maps, lightmaps ( I know it's already implemented ) and possibly even shaders ( I don't know how they work, I think some of them can work on a node to node basis ), it could become pretty confusing. What I would prefer would be having a material work like a scene node. You define the material first, like texture, lightmap, bumpmap, transparency etc, then assign this material to whatever mesh. Like this:

Code: Select all

scene::IMaterialNode* mat;
mat->setTexture(EM_TEXTURE, 0,  "texture1.jpg");
mat->setTexture(EM_BUMPMAP, 0, "bumpmap1.jpg");
mat->setAmbient(SColor(255,255,255,255));
..
node->setMaterial(mat);

I already have a simular system to this in 2080, whereby I do:

Code: Select all

scene::ISceneNode* node;
node->setPosition...

setSubMaterial( grass, node );

So that the sub-material system changes the texture and anything else I decide to add ( like bump maps and light maps ) is easily defined by a type, like grass. Having something simular built into the engine would save me a step and probably make the whole system a little easier on the eye for everyone using the engine. Just my thoughts as I avoid fixing a bug I found in my code

[DarkWhoppy]

yea i just downloaded the dxsdk and it was ~220mb. even on a cable modem it took me forever.

The DXSDK is a bundle.. but I bought this C++ book that came with a CD which had the DX8.1 SDK on it... saved me the time (just a few cents I wanted to throw out... its alittle more than 2 cents so. )