Irrlicht Engine

GPGPU might be good for really complex effects with huge amounts of calculations. However, most of these things are properly exposed for graphics applications, or have a better integration into the render pipeline via shaders. OpenCL comes in where things like terrain generation or physics calculations are put into the GPU. But this is mainly handled by other libraries...

For the support of the DDS formats, what are the breaks that you guys are talking about. Your best bet, I believe, is to implement 3D texture class that inherits from ITexture, and manages depth. Then you could load 3D/Volume/Cube textures all into the ITexture3D (which COpenGLTexture3D and CD3D9Texture3D, etc. inherits from),

I would really like to know the concrete reasons for why that can not be done? In my eyes, it has to be done, because right now I can only think of one hack, and I don't know if it is even possible in Irrlicht.

Can you guys add in threads like SDL has? so that irrlicht provides cross platform threads for everyone.

I'm surprised DX10 support with all the texture related requirements mentioned as well.

I do wish you guys good luck with that: DDS, HDR, vertex texture, tesselation and all that jazz.

A good target is being able to support the features provided by RenderMonkey and/or FXComposer, at least most of it should be the target. Both OpenGL and DirectX work in both products, so image and texture function calls should be on both as well.

It will be much easier if that happens, tho.

FreakNigh wrote:Can you guys add in threads like SDL has? so that irrlicht provides cross platform threads for everyone.

That would be great, but have you ever heard of pthreads. I'm sure that could help you in the meantime.

DDS files can actually be uploaded directly to OpenGL (I'm not so sure about DirectX, however, uploading directly to OpenGL is faster and a compressed texture stays compressed in the GPU). It's the ITexture support that may become tricky.

Also, what's the cost/benefit of moving processing to the GPU as opposed to supporting multithreading in Irrlicht to allow effective use of multiple CPU cores?

I could be wrong, but most games these days use both GPU and multithreading. You have the GPU handle all the graphics related-stuff (transformation and lighting calculations), and use the CPU to process physics, animation, scene management, and user input, using worker threads. And since transformation, lighting, and rasterisation is quite a grunty process in its own right, the GPU has enough on its plate, so if you have a nice multicore processor, why not use that to do various non-graphics-related work?

I would very much like the next version of Irrlicht to include multithreaded support natively, so that the CPU could be processing the second frame, while the GPU is processing the first frame. Most games do it that way anyway. That's what the swapchain is for in DirectX.

Dark_Kilauea wrote:DDS files can actually be uploaded directly to OpenGL (I'm not so sure about DirectX, however, uploading directly to OpenGL is faster and a compressed texture stays compressed in the GPU). It's the ITexture support that may become tricky.

Yes, it's the same for D3D9/10. So what exactly is tricky about it? Why should a 3D texture class not be made? It would be more complicated, but I suppose if they wanted to add it to the already established ITexture, then you could just include depth.

Halifax wrote:Why should a 3D texture class not be made? It would be more complicated, but I suppose if they wanted to add it to the already established ITexture, then you could just include depth.

Because we'd also need a 3d IImage implementation too, then there's things like access to mipmaps which are available in DDS and would have to be available in textures and images.
Rather than add a bunch of new interfaces it would make more sense to simplify the existing ones first... First merge ITexture and IImage, then worry about adding features like extra dimensions and exposing mipmaps. This means changes to all the drivers, possibly even keeping Irrlicht texture data in RAM, hardware accelerating all the software image conversion stuff, moving D3D textures out of the managed pool etc. So this is not as simple as it first seems.

FreakNigh wrote:Can you guys add in threads like SDL has? so that irrlicht provides cross platform threads for everyone.

You are "you guys".

Let's wait for boost::threads in c++0x...

I'd put Image and Texture classes above Threading, tho. Even that, I'd still push Threading down and put Mesh classes instead.

But that's me, my vote doesn't count anyway.

dlangdev wrote:But that's me, my vote doesn't count anyway.

Helllllloooo? Is this thing on? <tap tap> Can anyone hear me?

We. Are. All. Irrlicht. Devs.

Who wants a hug? Come on, group hug time. Just keep your hands above the sporran.

bitplane wrote:

Halifax wrote:Why should a 3D texture class not be made? It would be more complicated, but I suppose if they wanted to add it to the already established ITexture, then you could just include depth.

Because we'd also need a 3d IImage implementation too, then there's things like access to mipmaps which are available in DDS and would have to be available in textures and images.
Rather than add a bunch of new interfaces it would make more sense to simplify the existing ones first... First merge ITexture and IImage, then worry about adding features like extra dimensions and exposing mipmaps. This means changes to all the drivers, possibly even keeping Irrlicht texture data in RAM, hardware accelerating all the software image conversion stuff, moving D3D textures out of the managed pool etc. So this is not as simple as it first seems.

Alright, thank you for the answer. That clears up things now for me. I didn't realize that the plan was to merge IImage and ITexture, but that is a good idea.

Yeah theres alot of groundwork to be done before we start implementing things like fp textures. Mainly things like IImage and SColor have to be revised, unless the team decides to ditch the whole on-system memory backup thing they got going right now and load straight into VRAM.

Hybrid you said FP texture support wouldn't be so cumbersome if it was just enabled for RTTs right?

OpenCL

Slow down guys, that's like next-next-gen stuff, lets stick to current-gen. That's like when everyone drops Direct3D and OpenGL to handwrite their own rasterizers.

First merge ITexture and IImage

Ah I missed that. Yeah that would be a great idea. Essentially in the software drivers, an ITexture is an IImage masquerading as an ITexture. But then we have to wonder where all the easy access utility functions will go, setPixel, etc, and how do we handle images that we want to store in system ram?