Irrlicht Engine

hendu wrote:...but is it open source and available for all common platforms?

PVRTextTool is available for Windows, Linux and OSX (CLI + GUI). IIRC it isn't open source, but it shouldn't be a problem in this case.

You can use PVRTexTool from PowerVR SDK. It's free.

Few revs ago I added support for load cubemaps directly from PVR textures. IMO PVR is the best file format for texture handling in Irrlicht at now (it supports standard and cubemaps textures, both compressed and uncompressed formats and custom mipmaps).

I just checked a shader code once more and I don't see a line like that: gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0; but: gl_TexCoord[0] = gl_MultiTexCoord0; In this way auto-flipping can't work in v1.8 too... You must multiply "gl_TextureMatrix[yourTexUnit]" and texcoord if ...

Flipping ping-pong mentioned by Hendu is another reason why this thing should stay as it is now.

OK, we would add compile-time optimization flag (disabled at default), however please remember that it will not work for OpenGL ES2.0+ and OpenGL 3.x Core Profile+ (second option is still unavailable in Irrlicht). Please also remember that if you use shaders you still need to write driver specific s...

It's really a corner case. Why we want to force all users to worse performance. I understand that it should be flipped in built-in fixed-pipeline materials, because users don't have control of them, but in the shaders it's not a problem anymore.

It's related to OpenGL and textures origin at the lower left corner. During v1.9 development process we disabled some stuff for shader based materials like an auto flip for RT texture matrices in OpenGL, because it caused unnecessary overhead (you can flip UV directly in the shader code).

OSX examples has unnecessary entry and I'll remove it:

/Users/patryk/Programowanie/irrlicht-ogles/

however building works fine (I tested it on different Macs) for OSX example and iOS. Do you use a proper target?

In v1.9 we support VS2010 (mainly for Win XP users...), VS2012, VS2013 and VS2015. I think that in v2.0/v1.10 we should remove VS2010 and VS2012.

I'll fix it tomorrow. Thanks for a report.

It looks like we should switch to C++11 + STL after v1.9. Good, I'll use those standards in the new FVF branch.

I think that we should switch to both STL and C++11 after v1.9 release. AFAIK only old and exotic compilers may have problems with C++11, but C++11 has a lot of nice features, thats why I would like to use this standard during Irrlicht development.

BTW. Thanks CuteAlien for create this thread.

Yes, you can prepare a patch for shader-pipeline. Move stuff from shader-pipeline to fvf branch should be easy.

Hello, In upcoming weeks we'll drop support for shader-pipeline branch. In upcoming days a new branch will be created where a new FVF solution will be available. Of course we'll also move D3D11 from this branch to a new one. Why this change? Current FVF has little too high overhead and not enough bu...