What about irrlicht 2.0?

[playerdark]

I was wondering what happened to the plans regarding irrlicht 2.0? I noticed the forum has disappeared. Are there still plans for that? And are there information about what areas would be affected or changed?

The reason I'm asking is that I will most likely have to alter Irrlicht for my project. I need support for shaders in a way which doesn't seem to be offered in Irrlicht, so I will have to branch my own version off 1.2 but of course that leaves me kinda stuck with 1.2 in case a significant enhancement will be released.

Any information on this topic would be appreciated to help me make up my mind

[sio2]

I need support for shaders in a way which doesn't seem to be offered in Irrlicht

Interesting. Could you expand on this?

Also, by "shaders" I assume you mean hardware vertex/fragment/pixel shaders (and not something else, like Quake3 shaders).

I've done a heap of hardware shader work with Irrlicht this month. There are demos on my website: http://sio2.g0dsoft.com

[Halan]

there are plans for 2.0

well i think hybrid is workig on 1.3 atm... if he reads this it would be nice to say what hes working on

greets,
halan

[playerdark]

Thanks sio2, I check out your link. I need special vertices as I explained in my post in Advanced Help, I also think I found the reason for my problems. stupid beginner's problem but that's probably because it is really hard to find any cohesive explanation of HSL, but rather its bits and pieces here and there.
Your examples were very helpful to me. If you want to see my demo, and what I need more shader support for, please message me privately and I send you the link

[hybrid]

We had a discussion about new features for the next Irrlicht releases some time ago. I have collected all items from that list, but there's not much time left currently to make major changes. I guess Luke's new animation system could bring some major changes, and bitplane is working an major updates for the GUI. But besides that I don't know of important things.

[Halan]

well i would like to see some of sio2's shaders hard coded into the irrlicht dll

for example the reflecting water shader is very nice

greets,
halan

[BlindSide]

well i would like to see some of sio2's shaders hard coded into the irrlicht dll

for example the reflecting water shader is very nice

greets,
halan

I would like it squeezed into PS 1.4 first (HLSL). Ogre manages freznel and water reflection on my cheap 9250 just fine. It cant be that hard to do... Otherwise you will have a feature in irrlicht that isnt supported by very many people. Shaders are easy to add to a project though, I don't see what big advantages there are with integrating it. I think having maybe a seperate forum for shaders and people can pick from that when they need one, that would be nice ...

[playerdark]

That is a good idea. I am adding shaders myself now and it is not all that easy. Not necesserily to add them but all the problems that come with them. For example one of my graphiccards does not seem to render fixed function pipeline after it renders a shader, another one does, so I think that a location where irrlich specific shader questions could be discussed is a good idea.

[hybrid]

Talking of Irrlicht 2.0 here we should have a material system which allows for materials with lots of different implementations depending on the gfx card caps. That should be possible similar to what shaders already do with the fallback material.

[sio2]

well i would like to see some of sio2's shaders hard coded into the irrlicht dll

for example the reflecting water shader is very nice

greets,
halan

I would like it squeezed into PS 1.4 first (HLSL). Ogre manages freznel and water reflection on my cheap 9250 just fine. It cant be that hard to do... Otherwise you will have a feature in irrlicht that isnt supported by very many people. Shaders are easy to add to a project though, I don't see what big advantages there are with integrating it. I think having maybe a seperate forum for shaders and people can pick from that when they need one, that would be nice ...

Yeah, I need to go back and look at that. Under PS1.x there's a homogenous divide that the HLSL compiler can't map to PS1.x asm. Just one of a myriad restrictions in SM1. I need to either rewrite it in shader asm or find an equivalent way in HLSL.

[playerdark]

One of the most important things to change, although just a small thing to do, is to change all those 32 bit parameters that are passed to callback functions and the like to 64 bit or rather a pointer.
For example when using shaders, the callbackfunction that allows the application to set their own shader variables, receives a 32 bit parameter. In my case, I would like to pass a pointer to the class that uses the sahder in my application so that the function can obtain values from it. However, since I work in 64 bit mode, this is not possible.
So I think this is an important detail to change

[sio2]

One of the most important things to change, although just a small thing to do, is to change all those 32 bit parameters that are passed to callback functions and the like to 64 bit or rather a pointer.
For example when using shaders, the callbackfunction that allows the application to set their own shader variables, receives a 32 bit parameter. In my case, I would like to pass a pointer to the class that uses the sahder in my application so that the function can obtain values from it. However, since I work in 64 bit mode, this is not possible.
So I think this is an important detail to change

This has been discussed at length and the upshot was that it was not going to happen. A "void*" was suggested (may even have been me - can't recall) and...er...there was quite a heated discussion, shall we say. I've accepted the decision and am "just getting on with it".

Anyway, there are ways around not explicitly having a "void*". For example, if you have an array of shaders you could set userData (the s32 in the shader callback) to the index of the shader in the array. Or have an array of "void*" and use userData to index into it to get your pointer. You could also use bitmasks on the s32 to index into multiple tables.

[Halan]

well i think a real implenation would be reallly nice to handle for example a water scene node so you just do

Code: Select all

smgr->addReflectingWaterSceneNode(...)

and handle it like a hill plane mesh and then you can add e.g. the water surface animator

greets,
halan

[Athlon_Jedi]

umm guys, how about hard coding Spintz's 32 bit indicies changes , the change doesnt really make a noticible hit to engine performance and would allow for higher poly counts and detailed models

[sdi2000]

pssst not so loud with the qustion for 32bit indicies...
rather than a system that ask the graphics adapter "can i use 32 bit or 16bit indicies " or multiple 16bit buffers or better hardware buffer dx = streams opengl = fbo =) 16or32 bit..
i work on a solution...

use a patch till then....