Hmmm... Want to make some Irrlicht Goodies, ideas?

[devsh]

Right... I want to make something that can be integrated into the engine, ofc after adhering to irrlicht's coding standards etc. or fix some really nasty bug...

I was looking at the GSoC ideas and OpenCL has caught my eye... I think I could draft a minimal implementation of GPGPU with both OpenCL and CUDA for use with irrlicht.. minimal level like simple examples from the respecitve SDKs would run the overall aim would be OpenGL/CL/CUDA and DX/CUDA (that wouldnt be developed by me because I do not posses windows) interop which could be used to vastly accelerate SH from cubemap generation, enable creation of a RAYTRACING driver etc. or remove the necessity of downloading textures to CPU and performing operations on them in order to feed them to GPU again.

Or maybe finally put shadowmapping into irrlicht? Many different types ofcourse I mean for different levels of hardware.

Or create a deferred/inferred renderer?

Or do order independent transparency?

Or maybe I should include Skybox/Skydome to SH conversion function and a material type + ARB/low level shader to use it for image based lighting (would run on geforce 4 or some other crappy card)

Any more ideas?

[Kalango]

You could follow the TODO list on the wiki. I dont think its being tackled seriously by any developer right now.....
My sugestions:
- Mesh LOD
- Improve Collada or another animated mesh format importer
- Generic Post processin and multi-pass rendering (i know the forum has a bunch of implementations, but some are buggy and none are "official").

Anyways if you want to make something that can be integrated in the next major release it would be cool if you added support to DirectX and Windows as well. Not trying to bitch arround opensource or something, but it would be cool that Irrlicht could work at its best in all plataforms and implementations.
And also, talk to the devs about integrating stuff.... its been a long time since i saw something really really nice being added to the engine officialy and i'm still waiting for stuff like definite CG support and so...
Anyways... good luck.

[devsh]

I was thinking XML irrlicht shader format... and I think I could deliver an implementation which would translate a shader from HLSL to GLSL and the other way round hopefully freeing you from shader worry

Or Generic Post Processing.... what did you mean by generic post processing?

[ACE247]

You mean we could have a IMaterialRender Implementation which simply takes xml files as input? That would be schweet!

[devsh]

okay.... you asked for it... now to the irrlicht devs..

So guys, it's on your TODO list but no one has been assigned to it, can I have a shot at it?

[Kalango]

I meant a easier way to add post processing (like Ogre's way). Like an prebuilt class or something. XEffects is a good start but its a bit slow imho.
About the XML stuff, Nadro has something similar to it in his IrrCG project.
The problem i see with the xml is the limitations. But it could help a lot with simplier stuff.

[devsh]

Well first off the shader XML

proposal

Code: Select all

<irrlichtShader>
   <shaderCode Type="GLSL/HLSL/ARB/DXASM" psFile="path_to_file" vsFile="" /> <!-- Second File is ignored when HLSL -->
   <passParameters> <!-- We specify which built in params we want passed. If any of the parameter node not present, it is not passed... >
      <!-- Depending on using high level shaders or not the register or name is ignored accordingly, glsl shaders can pass to any shader type regardless of pixel, vertex or geom -->
      <worldTrans shader="vertex/pixel" register="usigned integer" name="char string">
      <viewTrans shader="vertex/pixel" register="usigned integer" name="char string">
      <projTrans shader="vertex/pixel" register="usigned integer" name="char string">
      <viewProjTrans shader="vertex/pixel" register="usigned integer" name="char string">
      <worldViewProjTrans shader="vertex/pixel" register="usigned integer" name="char string">
      <worldTransInv shader="vertex/pixel" register="usigned integer" name="char string">
      <viewTransInv shader="vertex/pixel" register="usigned integer" name="char string">
      <projTransInv  shader="vertex/pixel" register="usigned integer" name="char string">
      <viewProjTransInv shader="vertex/pixel" register="usigned integer" name="char string">
      <worldViewProjTransInv  shader="vertex/pixel" register="usigned integer" name="char string">
      <!-- textures... only needed in glsl, i think. If blank, not passed -->
      <tex0 name="shadername">
      <tex1 name="shadername">
      <tex2 name="shadername">
      <tex3 name="shadername">
      <tex4 name="shadername">
      <tex5 name="shadername">
      <tex6 name="shadername">
      <tex7 name="shadername">
   </passParameters>
</irrlichtShader>

Onto the technical side of things, function

u32 materialType = driver->loadXMLShader(file,myCallBack);

The callback is not the actual that is going to be used, there will be a new callback made by me which passes all general purpose constants and textures if specified by the XML, on the end of its execution it will allow YOUR OWN callback to pass extra/custom constants to the shader... and everyone is happy

What other constants should the built in shader callback be able to pass?

[randomMesh]

http://www.irrlicht3d.org/wiki/index.php?n=Dev.TODOList

[devsh]

Ofcourse I would enable for the loader to detect that its running ona openGL driver and the shader is HLSL or vice-versa running a DX driver and loading GLSL shader... for this case (and high level shaders only) I would provide language translation.. i.e. pretty epic feature

[xDan]

oho there is this too:
http://www.irrlicht3d.org/wiki/index.ph ... n.Wishlist
(substantially authored by me )

[there's a fair few basic, "last gen", type things Irrlicht lacks... But I suppose they're not quite as exciting for you to work on... ]

[devsh]

I could do General Postprocessing afterwards if that helps

++I have a plan to do hardware particles in the future...

[devsh]

Right here is the final format I think

Code: Select all

<irrlichtShader>
   <shaderCode Type="GLSL/HLSL" psFile="path_to_file" vsFile="" /> <!-- Second File is ignored when HLSL -->
   <shaderCodeFallBack Type="ARB/DXASM" vsFile="./opengl.vsh" vsFile="./opengl.psh" /> <!-- FallBack shaders for older HW if possible, if node not present then not considered -->
   <passParameters> <!-- We specify which built in params we want passed. If any of the parameter node not present, it is not passed... >
      <!-- Depending on using high level shaders or not the register or name is ignored accordingly, glsl shaders can pass to any shader type regardless of pixel, vertex or geom -->
      <worldTrans shader="vertex/pixel" register="usigned integer" name="char string">
      <viewTrans shader="vertex/pixel" register="usigned integer" name="char string">
      <projTrans shader="vertex/pixel" register="usigned integer" name="char string">
      <viewProjTrans shader="vertex/pixel" register="usigned integer" name="char string">
      <worldViewProjTrans shader="vertex/pixel" register="usigned integer" name="char string">
      <worldTransInv shader="vertex/pixel" register="usigned integer" name="char string">
      <viewTransInv shader="vertex/pixel" register="usigned integer" name="char string">
      <projTransInv  shader="vertex/pixel" register="usigned integer" name="char string">
      <viewProjTransInv shader="vertex/pixel" register="usigned integer" name="char string">
      <worldViewProjTransInv  shader="vertex/pixel" register="usigned integer" name="char string">
      <worldTransposed shader="vertex/pixel" register="usigned integer" name="char string">
      <viewTransposed shader="vertex/pixel" register="usigned integer" name="char string">
      <projTransposed shader="vertex/pixel" register="usigned integer" name="char string">
      <viewProjTransposed shader="vertex/pixel" register="usigned integer" name="char string">
      <worldViewProjTransposed shader="vertex/pixel" register="usigned integer" name="char string">
      <worldTransposedInv shader="vertex/pixel" register="usigned integer" name="char string">
      <viewTransposedInv shader="vertex/pixel" register="usigned integer" name="char string">
      <projTransposedInv  shader="vertex/pixel" register="usigned integer" name="char string">
      <viewProjTransposedInv shader="vertex/pixel" register="usigned integer" name="char string">
      <worldViewProjTransposedInv  shader="vertex/pixel" register="usigned integer" name="char string">
      <!-- textures... only needed in glsl, i think. If blank, not passed -->
      <tex0 name="shadername">
      <tex1 name="shadername">
      <tex2 name="shadername">
      <tex3 name="shadername">
      <tex4 name="shadername">
      <tex5 name="shadername">
      <tex6 name="shadername">
      <tex7 name="shadername">
   </passParameters>
</irrlichtShader> 

[devsh]

XML shader loader and default argument passing is done... what next?

I can build on this and create an XML material loader and/or hardware particles

[bitplane]

As briefly discussed in the chat room on Saturday, here's some input on the material format:

1) Rather than them being considered a special sort of "shader material", I think we should assume that all materials exist in the filesystem as files. We'd need a material cache in the video driver base class and some fake file names to go with it. I'm thinking we may want to export materials, maybe not but it's at least worth thinking about.

2) Rather than have a shaderCodeFallback, we should use something like materialFallback and give a file name to fall back to. For example the default could be SOLID which represents the built-in EMT_SOLID renderer.

3) The ASM shaders have a minimum shader model, we'd need to somehow incorporate this. You've also got shader types and their fallback. I'm thinking fallbacks would have to chain files together like this:

Code: Select all

    DisplacementMapping.irrMat (Referenced by .irr file, contains GLSL)
                |
                |   goes this way if it fails for whatever reason
                |
    DisplacementMappingHLSL.irrMat (Falls back to this, if D3D or old GL)
                | 
    ParallaxMapOpenGL.irrMat (Falls back to this, if no high level)
                | 
    ParallaxMapD3D.irrMat (Falls back to this, if not OpenGL)
                | 
    EMT_PARALLAX_MAP_SOLID (Finally falls back to this!)
                |
    EMT_SOLID (software driver ends up here)

This way the best possible renderer is chosen depending on the driver and hardware.

4) How do you set render states? Needs to have this inside the material format, or set a base material from the fixed function ones.

5) The passed parameter list should probably be something which works with IAttributes, and allow flexibility. This would avoid the need to hard-code each new variable manually (worldTrans, viewProjTrans and so on). For efficiency we may need to change IAttributes so we're not searching for attributes by name every frame, say have a ChangeId which increments each time an IAttributes is written to.

6) I don't like the slashes in the strings, there's no slashes in strings anywhere else in the engine.

That's all I can think of for the moment, hopefully others will chip in too. I personally don't write a lot of shaders, nor do I write exporters for modelling software. We'd need input from these people to build proper requirements,

[devsh]

One note, I am currently NOT DESIGNING MATERIAL XML FORMAT. I am doing an XML SHADER FORMAT, two very different things which have to be kept separate ANYWAY because it would become impossible otherwise.

Rather than them being considered a special sort of "shader material", I think we should assume that all materials exist in the filesystem as files. We'd need a material cache in the video driver base class and some fake file names to go with it. I'm thinking we may want to export materials, maybe not but it's at least worth thinking about.

I'm on it right now, we however do not need to represent normal material types as xmlShaderFiles, because the cache needs fileName and baseMaterial to compare shaders to find the identical ones (I also have an option which conduct a more rigorous check against the callback on top/custom one). Instead of faking it like that, we can use the names from "sBuiltInMaterialTypeNames[]" in the XML and that will be a special case for the findXMLFunction, if the XML shader is called that then we can feed that material type back instead of a shader one... problem solved

Rather than have a shaderCodeFallback, we should use something like materialFallback and give a file name to fall back to. For example the default could be SOLID which represents the built-in EMT_SOLID renderer.

I'll add that as another attribute in <shaderCode> and <shaderCodeFallBack>. Basically if <shaderCode> defines it, and it is not defined in shaderCodeFallBack or the node itself is missing, we fallback on that. If the <shaderCodeFallBack> node defines a fallback material it overrides the one specified by <shaderCode> if that one exists. The fixedFunctionFallBack="name" will be one from the "sBuiltInMaterialTypeNames[]"

Point number 3 is irrelevant to XML shaders, it will be dealt with in the material XML. There are reasons for this... first off the shader uniform names AND registers may be different in HLSL and GLSL versions, xml shader represents a Material Type! so the Material should handle which Type to choose. However I see that I must write an XML material implementation too in some time... So This is the general plan which will involve me adding sBuiltInMaterialFlagNames and ShaderCallBack cache id (like sceneNode id=-1 by default meaning no extra callback, so legacy code will be supported) You can have a vote on whether I use f32 or u32 for colors (0.f - 1.f range is a standard for people who do graphics, shader artists most gfx API programmers... you can have 0-255 if you like though)

I will add XML material layers if it's a must

Code: Select all

<irrlichtMaterial>
   <materialType>
      <openGLType shaderFile="" callBackId="signed int" />
      <d3d9Type shaderFile="" callBackId="signed int" />
      <d3d8Type shaderFile="" callBackId="signed int" />
      <otherType shaderFile="" /> <!-- shaderFile can only be one of sBuiltInMaterialTypeNames -->
   </materialType>
   <textures>
      <texture idx="0-3 or 0-7 or 0-15 - u32" name="file_path" />
      <texMatrix idx="same as tex" f00="f32" f01="f32" ... ... f15="f32" />
      <!-- You can add as many "texture" and matrices nodes as you wish or not define any :)-->
   </textures>
   <attributes>
      <colorMaterial value="E_COLOR_MATERIAL names"/>
      <ambientCol r="f32" g="f32" b="f32" a="f32" />
      <diffuseCol r="f32" g="f32" b="f32" a="f32" />
      <emissiveCol r="f32" g="f32" b="f32" a="f32" />
      <specularCol r="f32" g="f32" b="f32" a="f32" />
      <shininess value="f32" />
      <materialTypeParams param1="f32" param2="f32" />
      <thickness value="f32" />
   </attributes>
   <flags>
      <wireframe value="true/false" />
      <anti_aliasing value="the_flag_u32" />
      <!-- and so on -->
   </flags>
</irrlichtMaterial>

Unfortunately I have no idea what you are on about with points 4 and 6... sorry man.. I'm slow... exaplain again.

5) I dont see how the arguments could work with IAttributes.... However I will make the implementation independent of argument order in the enum