Irrlicht Engine

Hello,

I have to manipulate 3d models made of real textures (not synthesis textures) which have been recorded in 16 bits image format, for example PNG format in gray levels from 0 to 65535.

With the 3D engine OpenSceneGraph, it is no possible to record the sceenshots of these models on 16 bits but only on 8 bits. So there is a loss of dynamics which is not acceptable according to my needs.

So I would like to know if the Irrlicht engine is able to do this, knowing that I don't work with professional graphic cards (which works with 16 or 32 bits by channel).

Thanks.

When you create a screenshot you use the function createScreenShot, which simply returns an IImage object pointer. You can look at using the methods available in IImage for instance copyTo to copy the captured image to another IImage created with a suitable pixelformat. I also (in a Windows implementation) use GDI+ Bitmaps to convert from one format to another e.g. I create a GDI+ Bitmap, based on the pixel data within the IImage return.

Maybe this will give you some ideas.

Anton

Not really, because it's not 16bit (per colorchannel, not per pixel!).

In fact, when one studies the COpenGLDriver.cpp file, one sees that the ScreenShot function convert images in 1 bytes per channel. So even if I rescale the image after the screen shot in [0; 65535], I will obtain just 255 possible values per channel.

You would have to work in full HDR. I don't think IRRlicht support this (As any other rendering engine that I know of) Other could claim they use HDR but in fact, they fake it with shaders.

What you are asking for is rendering in a 48bit or 64bit frame buffer. (16 bit per channel = R+G+B+A(Alpha). And would require a file format saver that support this. As I know of, IRRlicht can only use at maximum a 32bit (RGBA) frame buffer.

We have FP RTT support now in SVN/trunk, but one cannot request such a format for putting into a CImage so far. Don't know what happens when you lock such an RTT, maybe BlindSide knows this? Probably right now the lock would return 0, because you cannot get a proper color format, but that could be easily changed in the driver. You need to now the internal color representation, though, which might be a very special bit representation.