What's new features for Irrlicht 1.6

Nadro · Post by **Nadro** » Sun Dec 14, 2008 10:47 pm

Hi,
What's new features are You planning add in next version of Irrlicht? What are You think about native *.dds support with texture compression, cube maps, multiple render targets, portal and occlusion culling eg. by occlusion query, better hardware vertex buffer system, now 1 mesh buffer = 1 VBO object = 1 texture on mesh and it isn't the best solution. I know that on this forum are patches for some with this features (some made by me), but many users don't use patches, only native core functions, so I think new stuff will be very usefull for all Irrlicht users.

BTW. In Irrlicht are You planning add support for DirectX 10? Maybe now we should look into DirectX 11 and add DirectX 10 support only in "free" time?

rogerborg · Post by **rogerborg** » Sun Dec 14, 2008 11:48 pm

hybrid does that complicated voodoo black magic graphics stuff.

For my part, I'm intending to add my collision and light management patches, possibly a billboard upgrade, plus whatever else is in the tracker that looks like it will bring glory in return for very little work. Nothing gets in without a unit test, as I'm a bear of very little brain.

Regarding DX10/DX11, the November 2008 Steam hardware survey shows a growth in DX10 systems to 21.43%. In other words, every hour spent on DX10 is equivalent to (nearly) five hours spent on DX9.

I've no actual objection to DX10/DX11 support, but I don't even have a Vista development box. It may come up at the next secret meeting of the developer Cabal though.

hybrid · Post by **hybrid** » Sun Dec 14, 2008 11:50 pm

Well, the topics are all on the todo list, but which of them will go into 1.6 is not yet decided. We'll work on the schedule for 1.6 once we have 1.5 out

The thing is that doing a new feature such that it's working for some people somehow is often possible with decen amount of work, but doing it in a way that it fits the Irrlicht style, is usable by all people out there easily, and make it cross-platform is really another thing. And it requires lots of time and hard work. So it's not just adding a handful of patches here and there. But patches may give a starting point.

I'm still not able to do any DX10 or DX11 support, as I'm on XP only (regarding the windows systems). However, the ogl-es2 branch will do lots of the stff that is also necessary for DX10/DX11 (at least getting rid of the fixed function pipeline and immedaite mode calls). So once that driver matures we can get some things from there into possible DX10/DX11 drivers. And as always, if someone provides proper implementations we'll always reconsider our current strategy based on the new input

Halifax · Post by **Halifax** » Mon Dec 15, 2008 4:23 am

In order to get ready for DX10, I believe the best thing to do would be to improve the DX9 renderer with things akin to BlindSide's XEffects. Offering shader-based materials that follow the suit of the already implemented Irrlicht materials.

And on the note of DDS. Yes, DDS support would be great, but you still need the conversion algorithms to convert to other formats. It's always possible that the user won't just want to upload the data to the graphics card. And also a scheme would need to be devised for client-side pixel requests, etc. It's more difficult than just providing an image loader for DDS. But once again, I would love to see this implemented.

MRTs are another thing that would be great to see in Irrlicht.

Occlusion queries should be exposed by Irrlicht, but a good general-purpose occlusion culling algorithm is hard to formulate. Even the one in GPU Gems 2 has its own pitfalls. But there are many uses of occlusion queries other than occlusion culling, so it would be beneficial for them to at least be exposed.

I agree with you on the hardware vertex buffer system as well. A bette one is needed. I'm alright with the current one for now though.

And I'm just wondering, but what about GLSL shaders? Why aren't Irrlicht values mapped to the actual GLSL inputs, but instead the texture coordinates? Why can't that behavior be changed?

Dark_Kilauea · Post by **Dark_Kilauea** » Mon Dec 15, 2008 5:45 am

I would like to see dds support. For the most part its very easy, but would require a break from the normal way irrlicht loads textures.

hybrid · Post by **hybrid** » Mon Dec 15, 2008 8:25 am

Dark_Kilauea wrote:For the most part its very easy, but would require a break from the normal way irrlicht loads textures.

That's the thing I was talking about. That won't happen unless there is absolutely no other way around. We're still exploring the other ones.

sudi · Post by **sudi** » Mon Dec 15, 2008 11:30 am

whats all this stuff about dx10 changes????
You know I#m programming most of the time on a linux platform and only have ogl support there. I would like to see some ogl improvements and not only upgrading for all the vista users.

rogerborg · Post by **rogerborg** » Mon Dec 15, 2008 12:41 pm

"All this stuff" is the active devs saying that we don't intend to prioritise DX10/DX11 support, and in fact couldn't work on it even if we wanted to. I'm not sure what thread you're reading.

fmx · Post by **fmx** » Mon Dec 15, 2008 12:57 pm

DX is continuously being updated (for the better it would seem), while OGL hasn't changed much at all. There would be more work todo to get the newer versions of DX working "efficiently" rather than improving OGL support alone.

Although I'm partial to OGL myself and would also like to see it improved

DDS support would be nice, as would be a shader-based material system

sudi · Post by **sudi** » Mon Dec 15, 2008 1:38 pm

rogerborg wrote:"All this stuff" is the active devs saying that we don't intend to prioritise DX10/DX11 support, and in fact couldn't work on it even if we wanted to. I'm not sure what thread you're reading.

Hehe i misread hybrids post^^

@fmx
I'm actually working on a shader-based material system for irrlicht. The PostProcess snippet i posted in the CodeSnippets Section is the first part of it. I will allow to define materials using xml files just like my PostProcess class and pretty much like ogre3d did before me.
But to make this work i had to write a new SceneNode which encapsulates a normal scenenode and that way allows multiple renderpasses on a single scenenode. Maybe my changes can be added to irrlicht itself maybe even my PostProcess class. its not that havey like XEffects but its only intended to make postprocessing.

SwitchCase · Post by **SwitchCase** » Mon Dec 15, 2008 2:04 pm

I know I'm jumping the gun a bit here but are have you Irrlicht devs had any thoughts on OpenCL?

Bit of a cheeky question i know

hybrid · Post by **hybrid** » Mon Dec 15, 2008 2:26 pm

What would be the purpose of GPGPU for Irrlicht? So OpenCL seems a little out of scope for a 3d rendering engine

SwitchCase · Post by **SwitchCase** » Mon Dec 15, 2008 3:59 pm

hybrid wrote:What would be the purpose of GPGPU for Irrlicht? So OpenCL seems a little out of scope for a 3d rendering engine

I meant with strict regard to graphics processing. At the moment there's a choice between fixed-function pipeline and the shader approach. Either way many calculations are done on the CPU and then the results squeezed through to the GPU for rendering, would it not be an advantage to do these calculations on the GPU? Things like collision calculations for example.

I understand that OpenCL is for GPGPU so that things other than graphics can be processed on the GPU but have I misunderstood how OpenCL works?

fmx · Post by **fmx** » Mon Dec 15, 2008 4:01 pm

Sudi: sounds cool, looking forward to it

hybrid:
wouldn't GPGPU have some part to play for a 3D rendering engine? I admit its far too early to even talk about OpenCL becoming a part of Irrlicht, but surely it would be a consideration sometime in the (distant) future?

rogerborg · Post by **rogerborg** » Mon Dec 15, 2008 4:11 pm

SwitchCase wrote:would it not be an advantage to do these calculations on the GPU? Things like collision calculations for example.

Are you proposing moving all collision geometry, i.e. all mesh data, to VRAM?

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?

A reminder: everyone here is an Irrlicht developer. We all have the same source code. All that's different is whether we have SVN access or not. The best way to get SVN access is to write and submit code.

So, if you want to see OpenCL (or anything else) in Irrlicht, then saddle up and show us. The start of a new version cycle is the ideal time. Let's roll!