What's new features for Irrlicht 1.6

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

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...
Halifax
Posts: 1424
Joined: Sun Apr 29, 2007 10:40 pm
Location: $9D95

Post by Halifax »

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.
TheQuestion = 2B || !2B
FreakNigh
Posts: 122
Joined: Thu Oct 19, 2006 7:31 am
Location: Orlando FL, USA
Contact:

Post by FreakNigh »

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

CvIrrCamController - 3D head tracking lib to create window effect with webcam
IrrAR - Attach Irrlicht nodes to real life markers
http://www.nighsoft.com/
dlangdev
Posts: 1324
Joined: Tue Aug 07, 2007 7:28 pm
Location: Beaverton OR
Contact:

Post by dlangdev »

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.
Image
Halifax
Posts: 1424
Joined: Sun Apr 29, 2007 10:40 pm
Location: $9D95

Post by Halifax »

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.
TheQuestion = 2B || !2B
Dark_Kilauea
Posts: 368
Joined: Tue Aug 21, 2007 1:43 am
Location: The Middle of Nowhere

Post by Dark_Kilauea »

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.
rogerborg wrote:Every time someone learns to use a debugger, an angel gets their wings.
ikari734
Posts: 2
Joined: Mon Dec 15, 2008 10:33 pm

Post by ikari734 »

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.
Halifax
Posts: 1424
Joined: Sun Apr 29, 2007 10:40 pm
Location: $9D95

Post by Halifax »

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.
TheQuestion = 2B || !2B
bitplane
Admin
Posts: 3204
Joined: Mon Mar 28, 2005 3:45 am
Location: England
Contact:

Post by bitplane »

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.
Submit bugs/patches to the tracker!
Need help right now? Visit the chat room
rogerborg
Admin
Posts: 3590
Joined: Mon Oct 09, 2006 9:36 am
Location: Scotland - gonnae no slag aff mah Engleesh
Contact:

Post by rogerborg »

FreakNigh wrote:Can you guys add in threads like SDL has? so that irrlicht provides cross platform threads for everyone.
You are "you guys". :P
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Let's wait for boost::threads in c++0x...
dlangdev
Posts: 1324
Joined: Tue Aug 07, 2007 7:28 pm
Location: Beaverton OR
Contact:

Post by dlangdev »

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.
Image
rogerborg
Admin
Posts: 3590
Joined: Mon Oct 09, 2006 9:36 am
Location: Scotland - gonnae no slag aff mah Engleesh
Contact:

Post by rogerborg »

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.
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Halifax
Posts: 1424
Joined: Sun Apr 29, 2007 10:40 pm
Location: $9D95

Post by Halifax »

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.
TheQuestion = 2B || !2B
BlindSide
Admin
Posts: 2821
Joined: Thu Dec 08, 2005 9:09 am
Location: NZ!

Post by BlindSide »

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. :P
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?
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Post Reply