Irrlicht with cubemap support

[elvman]

Added more realistic reflections to the demo and created a screenshot of the demo.

[ACE247]

Tested on Geforce 7300GS(+-330fps) and Geforce gts250(VERY HIGH) and works. However by me the reflection on the sphere is upside down.

[elvman]

Tested on Geforce 7300GS(+-330fps) and Geforce gts250(VERY HIGH) and works. However by me the reflection on the sphere is upside down.

Can you share some screenshots?

[ACE247]

Here's what I mean.

[elvman]

What driver are you using (Direct3D9 or OpenGL)? Try with both and check if results are the same.

[elvman]

Added an interface for 2D textures (ITexture2D) which extends ITexture, so all 2D textures now implements it. getTexture now returns ITexture2D.
Created patch and source for the latest SVN version of Irrlicht.

PS. What should I do to get this integrated in core?

[RdR]

PS. What should I do to get this integrated in core?

I was wondering the same, really like to see this added to the irrlicht trunk.

Elvman are you updating your water scene node with cubemap?

[elvman]

Elvman are you updating your water scene node with cubemap?

I will do it when Cubemaps get integrated in Irrlicht core, because I cant create a water node, that does not work with original version of Irrlicht.

[ACE247]

Any update on this? As for earlier, about the inverted reflection, it does it with both drivers.

[CuteAlien]

Ok, not so much my area yet, but I just spend a few minutes browsing quickly over the patch. Looks interesting in general and it's something we could also need here.

But I also noticed a few things:

First - are the all the interface changes for textures really needed? It seems only ITexture::getTextureType get's added while the new interfaces ITexture2D and ITextureCube don't have a single additional member. Why not just set that type in the texture-implementations? I realized this might be a cleaner looking solution - but it's changing rather a lot which is generally not a good idea unless you have to (as it messes up wrappers, user-code etc) and it seems we could avoid all that for now (could still be done if it's really needed for something later on).

Next that code:

Code: Select all

 
#ifndef _IRR_COMPILE_WITH_DIRECT3D_8_
// The D3DXFilterTexture function seems to get linked wrong when
// compiling with both D3D8 and 9, causing it not to work in the D3D9 device.
// So mipmapgeneration is replaced with my own bad generation in d3d 8 when
// compiling with both D3D 8 and 9.
// #define _IRR_USE_D3DXFilterTexture_
#endif // _IRR_COMPILE_WITH_DIRECT3D_8_
 
#ifdef _IRR_USE_D3DXFilterTexture_
#pragma comment(lib, "d3dx9.lib")
#endif
 

Really needed? I'm a little confused especially as I don't see a custom d3d8 mipmapgeneration.

Another mipmap thing in COpenGLTextureCube::uploadTexture() - there is outcommented code ( the if( hasMipMaps ) )in the patch. Why is it commented out?

Can't tell yet about implementation, I will need more time for that. But that it comes with Demo already is definitely a good sign :-)

[ACE247]

Great to hear that someones still watching this.
I was quite aware of the many odd code bits present in the patch, I think they're still left from Elvman trying to add new Texture formats, 1D,3D...
Best to probably remove those and add them in a completely separate patch later, plus a separate patch for then extending the Cubemap after the new texture formats,IF the texture form'ts ever are added.
Probably better wait for elvman to comment on that.

[REDDemon]

it uses normals as UVT coords?

[elvman]

Is there any progress on integrating my cubemaps into engine?

[Mel]

I'd say you should wait for Irrlicht 1.9 at least....

[d3jake]

Could someone clue me in as to why this is so useful? I looked up "cubemap" on the tome of wikipedia, and it has something to do with reflections, but what would the application be for a game?