Irrlicht Engine

Blindside: I like the sound of that--making a kick-ass Image-Color-Texture-Mesh subsystem. I can already smell it from here.

I just can't stop parroting the mantra of making the object model artist-friendly, almost similar to RenderMonkey's object model. For example, Render Targets line-up easily making it possible to reference it in the shaders by name. Models are loaded easily and are linked to a render pass somewhere down the chain/tree. Vertex formats are automatically detected and then set accordingly in shader semantics. Textures are declared early up in the chain, then propagated down as references to a given render pass.

I'm not saying they all appear in 1.6, it's just that is my dream (I have a dream) of seeing that happen sometime in the near future.

Merging IImage and ITexture won't mean that one will go away. Instead, it's more a process of harmonization. Maybe ITexture will become a specialization of IImage or so. However, right now some very similar things have gone too far away from each other.
BlindSide, yes, there's a chance to get some things not fully exposed, and hence rather local. This could be for FP RTTs, depth textures, and compressed textures. But we'll have to examine the overall impact of those changes. Cube maps and 3D textures are also pretty on top of my todo list (even planned for 1.5 some time ago), but the interface changes and other changes in the alreay existing structures made a change to those plans. Let's see what 1.6 will do.

Also let me just remind everyone to take a breather here. I mean, 1.5 was just released, lets enjoy what we have, atleast for a while.

Ok I agree OpenCL is little out of scope for the time being. However I do think it's worth keeping in mind in the future as an option to take those complex calculations in. I know other libraries are generally used for i.e. terrain generation but should future versions of irrlicht use more sophisticated terrain generation - it could be the better option to do calculations for this on the GPU. Some tests comparing processing this stuff on GPU as opposed to CPU or a dedicated thread will be something I'll look into at some point.

Anyway, calm it, I wasn't pushing for anyone to get down and dirty with OpenCL and Irrlicht, I just wanted to prompt a discussion about it. This discussion.

Just figured I would throw in here that Ogre specifically uses the same method that Irrlicht does regarding software images, and hardware textures(Ogre::Image and Ogre::Texture respectively), but rather it appears that the allow the user to skip loading it into an image, and allow them to upload it directly by going straight to a texture out of the file.

So maybe it's not to bad the way it is. But I don't know, you guys might come up with applicable way to merge the two classes.

hybrid wrote:Let's wait for boost::threads in c++0x...

Wowowow....
We can't have sdl as the basic containers because somehow some people are afraid that one could discover a platform where there isn't any c++ implementation (which is as unlikely as can be) or because it might not be performant enough (even though it's pushed by the entire industry and compared to the simplified Irrlicht versions, they score as fast or faster while being safer), BUT we're gonna add a 0x feature as a core development?

Please tell me replacing the Irr containers with their sdl equivalents comes before on the todo list.

Well, we also have directx as an underlying library, I'm pretty sure it's not available everywhere. Moreover, SDL doesn't really provide containers, that's STL Anyway, I said let's wait for boost::threads, not let's use them in Irrlicht

Fine, fine, also, sorry, meant STL (SDL, wtf?). Anyway, how opposed/in favor are you to a complete refactoring of the irr containers? If I or someone else brings a patch that tears it all out, replacing all instances by their stl equivalents, would that get in?

That's pretty harsh on users of irr::core, isn't it?

You have two ways to get such a patch in: Make the changes to STL optional, i.e. give replacement implementations which are ifdef'ed or somehow derived from the container API, or add speedups from STL back into the Irrlicht containers

The problem is the irr containers do not even follow the stl syntax in all places and it's one that is quite common. Also, when passing things from one library to another, what are the odds it will accept an irr syntax over a stl syntax? Let's face it, irr::containers are as much a thing of the past as dx8 or the 2 software renderers. If nothing else, it should have a backup role, not the center stage. Anyhow, disguising the stl under the irr::core guise would both raise problem where their syntax differs AND add useless overhead in all places a typedef isn't enough. That's a heavy price to pay just to use a basic feature of the language.

Anyhow, I understand you don't want to break compat., but as long as the best we can hope is a half-done conversion to stl, it's pointless and I won't spend time on it.


On another note, for 1.6, there were recent talks of ditching the wide char for something uniform. I'm all for this. I'd say a 2 byte char covering ascii, extended ascii, japaneese chars, chineese (same written chars for both language I think), korean (if diff chars), arabic. If we cover those, it'll be a good start.

This STL discussion is getting a little stale. We are Klingons! I mean developers. Do, or do not do.

Dorth wrote:On another note, for 1.6, there were recent talks of ditching the wide char for something uniform. I'm all for this. I'd say a 2 byte char covering ascii, extended ascii, japaneese chars, chineese (same written chars for both language I think), korean (if diff chars), arabic. If we cover those, it'll be a good start.

I favour an explicit UCS-2BE or UCS-2LE type (which can represent the characters from those languages), but finding the time to do it thoroughly may be an issue.

I'm also in favour of a (very) slightly smarter conversion of characters outside ASCII (or Latin-1) to c8, which is to check the value of larger types and instead of truncating to c7/c8, convert it to (e.g.) ASCII '?' if the value is outside the ASCII or Latin-1 range.

Hey guys, and lets not forget the file system.
I would be happy to see improvements on that side, and yes rogerborg, I know what you're gonna say...
Then lets hug!!

Another thing regarding threading. I believe it could empower the library so very much but would require, I believe, too much work to redesign many places to use efficiently multithreading.
But, I do agree with moving all mathematical calculations to the GPU. Having a processing unit that is by every aspect of it made to solve complicated calculations in light speed, having and not using it for that, is a big waste. I understand it's not something you can add in a day or two and require a lot of work but I believe it would benefit and be worthwhile for the future of Irrlicht.

I would like to see post process shading built in and better shader support/documentation

ps: Woot first post, and i love the engine

Dorth wrote:Fine, fine, also, sorry, meant STL (SDL, wtf?). Anyway, how opposed/in favor are you to a complete refactoring of the irr containers? If I or someone else brings a patch that tears it all out, replacing all instances by their stl equivalents, would that get in?

Didn't we have this conversation before?
As I recall, we never did reach a conclusion, and no one started writing a patch; not saying it can't be done, but people didn't seem too gung-ho about it the first time.