What's new features for Irrlicht 1.6
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
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.
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
Can you guys add in threads like SDL has? so that irrlicht provides cross platform threads for everyone.
CvIrrCamController - 3D head tracking lib to create window effect with webcam
IrrAR - Attach Irrlicht nodes to real life markers
http://www.nighsoft.com/
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.
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.
That would be great, but have you ever heard of pthreads. I'm sure that could help you in the meantime.FreakNigh wrote:Can you guys add in threads like SDL has? so that irrlicht provides cross platform threads for everyone.
TheQuestion = 2B || !2B
-
- Posts: 368
- Joined: Tue Aug 21, 2007 1:43 am
- Location: The Middle of Nowhere
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.
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?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 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.
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.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.
TheQuestion = 2B || !2B
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.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.
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.
-
- Admin
- Posts: 3590
- Joined: Mon Oct 09, 2006 9:36 am
- Location: Scotland - gonnae no slag aff mah Engleesh
- Contact:
You are "you guys".FreakNigh wrote:Can you guys add in threads like SDL has? so that irrlicht provides cross platform threads for everyone.
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
-
- Admin
- Posts: 3590
- Joined: Mon Oct 09, 2006 9:36 am
- Location: Scotland - gonnae no slag aff mah Engleesh
- Contact:
Helllllloooo? Is this thing on? <tap tap> Can anyone hear me?dlangdev wrote:But that's me, my vote doesn't count anyway.
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
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
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.bitplane wrote: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.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.
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.
TheQuestion = 2B || !2B
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?
Hybrid you said FP texture support wouldn't be so cumbersome if it was just enabled for RTTs right?
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.OpenCL
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?First merge ITexture and IImage
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net