Project proposal: IrrTech

3DModelerMan · Post by **3DModelerMan** » Tue Jun 14, 2011 10:18 pm

Okay, I'm working on a shader add-on right now. I'll post it in code snippets and the wiki when I'm done. I'm writing an engine around Irrlicht, so I might have some small patches soon also.

mongoose7 · Post by **mongoose7** » Wed Jun 15, 2011 9:05 am

What happened to IrrExt? It seems to be full of stuff that has been implemented. Could it be cleaned out and new stuff put in?

I just think Irrlicht has become ossified. In some cases, new features would not really impact on old code and both could be worked on separately. But I think Irrlicht needs to move forward.

Perhaps there could be a way of proposing and designing changes and for some of the better ones to be accepted as extensions that could be downloaded and that would integrate to some extent. It seems to need guidance and control. In Irrlicht, nobody seems to be in control. Nobody seems to be capable of saying, yes, let's do that.

I really can't see a good reason for not letting someone come up with a good shader model. Really.

But let's see something happen!

hybrid · Post by **hybrid** » Wed Jun 15, 2011 11:39 am

Don't know how deep you really checked. The opengl-es2 driver, for example, has been completely implemented by externals, and integrated into the engine without major revision. The code was fully tested, adhering to the code style, maintainable and comprehensible.
An example, which did not work as good, is the dx10/11 driver. The author did not try to contact any of the core developers. Development state and necessary changes to the existing setup is unknown, but IMHO it was also no goal to keep the API changes of the existing interface low. It's at least not clear to me, how much work I'd have to invest to get this into the current Irrlicht repository.
An even more painful example, because it took me already quite some time even though I'm not even near to integrate it, is irrCg. The concept chosen for adding yet another shader language was completely different to that of the previous shader languages. Even though the first version started from the current API, the last implementations didn't show any resemblance to the official Irrlicht API. Nor did the old interface get an update. This might be a way for implementing stuff for personal needs, but it's in no way a good idea if the goal is to get this implemented in the core engine.
Since Irrlicht currently has just two active developers in the core team, the guidance and control is pretty simple and works. The output is just not as high as one might want, due to other reasons (mainly doing an RL job for the living). Since these facts aren't easily changeable, we can only improve the overall situation if the submissions from the community try to reduce our work. Otherwise you have to trust and rely on our continuous devotion which just little spare time for the hard work.

Oh, and for irrExt we're always looking for additional maintainers and code snippets. The project is basically free for everyone to join and work on the add-ons.

3DModelerMan · Post by **3DModelerMan** » Wed Jun 15, 2011 1:17 pm

I was actually starting to research how to do a D3D10 driver without having to change the API at all. I was playing with my new graphics card and figured I would try it out. It's actually quite feasable to integrate a D3D10 driver without changing existing code.

Radikalizm · Post by **Radikalizm** » Wed Jun 15, 2011 2:02 pm

3DModelerMan wrote:I was actually starting to research how to do a D3D10 driver without having to change the API at all. I was playing with my new graphics card and figured I would try it out. It's actually quite feasable to integrate a D3D10 driver without changing existing code.

I seriously doubt that if you want to take full advantage of the D3D10 features, I'm sure that it could be done with some not too large changes to the API, but no changes at all seems pretty impossible to me

By the way, wouldn't it be a better idea to directly go for DX11? Since the introduction of feature levels there's absolutely no need for an intermediate D3D10 implementation

Kalango · Post by **Kalango** » Wed Jun 15, 2011 4:18 pm

Maybe it could be a good thing to add to the wiki or the forums the guidelines to make a new compatible working patch to irrlicht and a submit button/form/attachment manager so ppl could submit the patches.
The guidelines should be pretty solid and well explained. The patches in approval process could be voted to be released in the next version or something like that. I think that could be the way to go.

Nadro · Post by **Nadro** » Wed Jun 15, 2011 5:55 pm

At first I didn't left Irrlicht (it is part of my game engine and I use it in all my game projects) but last time I work more over core part of my Game Engine than renderer (Irrlicht) and thats why I'm less active on Irrlicht forum but it will change soon

What about irrCg? I agree with Hybrid about integration irrCg with Irrlicht. When I started works over irrCg, official status of Irrlicht was: "no external libraries in engine", so I choose different interface for it than existing interface in Irrlicht (both are easy to use in my opinion and as long as it isn't part of Irrlicht core is different, but also easy interface is ok). But if is a chance to integrate irrCg with Irrlicht I can rewrite irrCg with Irrlicht style interface. Personally I use GLSL instead of Cg in my projects, but if Irrlicht users still use Cg shaders I will try a help

hybrid · Post by **hybrid** » Wed Jun 15, 2011 10:40 pm

We won't put the whole Cg library into the distributed SDK, but having an easy integration with Cg (at least some things, a basic adaption) would be nice. It would be disabled by default, but would be possible to compile in with just one config change.
So it would be nice to have the basic initialization and the variable handling only. Other things can be added later on, but of course then for all shaders languages at once.
Edit: Just wanted to mention that, besides irrCg, Nadro also delivered many extensions for Irrlicht successfully. IIRC, both MRTs and Occlusion queries are based on his initial implementations!

3DModelerMan · Post by **3DModelerMan** » Thu Jun 16, 2011 1:17 pm

Wow, Nadro is good

. Something that would be pretty nice is to make the drivers a little more plug and play. A driver factory that creates the driver from the driver type passed to the device, and an option of "EDT_NO_DRIVER". Could let you create the device without a video driver, and a driver factory could be supplied that would create your custom driver and set it as the one used by the device. It would not affect current code using Irrlicht because if you supplied the driver type, the built in driver factories could just create a driver right away, but if you had a custom driver you could create it without recompiling Irrlicht every time you needed to change your custom driver.

devsh · Post by **devsh** » Thu Jun 16, 2011 6:36 pm

@hybrid: The Flexible Vertex Format Better Be on Your Priority List.... we need it for shitloads of things especially if you managed to separate S3DVertex into a container rather than an object. This is because

separated arrays of attributes perform better: streamed or stored as VBO as opposed to interweaved
You could technically add on infinite and flexible arrays with attributes for many things and the old S3DVertex would still be compatibile. For example:

S3DVertex or S3DVertexArrays would be a container class (no data of its own), just pointers or handles to VBOs (or whatever they are called in DX). This way you would not have to have CMeshBuffer, CMeshBufferTangents etc. etc. a meshbuffer for every single vertex class/type ever made because the vertices would not be interweaved and their size/interval between them would not matter

See????

P.S. Please don't ditch PROPER OpenGL for GL-es

and for 3dModelerMan

I do have a list of improvement features that we could start on. Faster vector/matrix math would be one. SIMD and 16 byte aligned vectors/matrices/quaternions. I also had some material improvements I think could be made quite easily. There's alot of new feature ideas that I have, but I could probably improve the GUI environment too. We also could make sure to talk to the devs and propose the features to them before starting on anything also.

I actually did the dirty work here my friend, if you use the Search facility you will see I did an entire post not only about SIMD (which is OOOOOLLLLDDD) but SSE2 and 3, guess what?? The compiler version of -03 and -ffast-math is faster(or the same in matrices) than SSE3 on matrices and vectors. My guess would be the compiler SIMDs your code by itself to some extent. The SSE would be only useful for you if you were adding big arrays of numbers. I have to admit I didn't test quaternions....

And Lastly.. I have code for all my projects, from geometry shader tesselation, fin extrusion aided Parallax Occlusion Mapping, Atmosphere Scattering Shader to replace a skydome, most probably the best SSAO/GI irrlicht has ever gotten (no offence, and it's not really mine either), I did PSSM with VSM in Ninja Star, I also implemented Volumetric Light Shafts/God Rays and pretty darn good water... The thing is that like everyone I dont have time to rewrite it all irrlicht style and hand it easy to use with a user manual to you guys... no matter how much I love you. I know the code is scarce in comments (at least my comments aren't in hungarian like atmoSphere, don't get me wrong... amazing piece of coding with the exact sun path and all) and evil coding style of a 14 year old who only knew C++ for 3 months... but stuff is there on googlecode, feel free to use and mention me or not in your implementation. If you think the code is poop... leave it.

3DModelerMan · Post by **3DModelerMan** » Thu Jun 16, 2011 10:45 pm

The only reason I don't implement everything in OpenGL is that it's not as widely supported on regular Windows boxes as OpenGL, I actually like the GLSL language better than HLSL. Although technically if you argue the Macs and Linuxes out there it's more widely supported... That's why I want to get the DirectX10/11 driver sometime soon.

mongoose7 · Post by **mongoose7** » Fri Jun 17, 2011 1:29 pm

S3Vertex: If you are going to change basic data structures or architecture, it is better to do it sooner than later.

devsh · Post by **devsh** » Fri Jun 17, 2011 4:06 pm

3DModelerMan... dude, I know dx is very popular, but you are in for more of a trouble. You talk about support... if you plan to support nvidia 7xxx and most Intels with SM 3.0 then you are in for a headache because supporting a dx 9 and dx10 game in irrlicht is as much of a nightmare as supporting dx9 and opengl at the same time, you will have to write separate shaders. That's not even a pain considering the next fact, YOU'LL have to build two irrlicht DLLs like you do for dx8 and 9 now. I'm not trying to preach, but the extension system of OpenGL is a work of art... ever wondered why we have a single OpenGL driver? One irrlicht interface handles OpenGL 1.2,2.1,3.3 and 4.0, cards with geometry shaders and fixed function only are all handled by the SAME DRIVER CLASS.

See my point?

Radikalizm · Post by **Radikalizm** » Fri Jun 17, 2011 4:36 pm

devsh wrote:3DModelerMan... dude, I know dx is very popular, but you are in for more of a trouble. You talk about support... if you plan to support nvidia 7xxx and most Intels with SM 3.0 then you are in for a headache because supporting a dx 9 and dx10 game in irrlicht is as much of a nightmare as supporting dx9 and opengl at the same time, you will have to write separate shaders. That's not even a pain considering the next fact, YOU'LL have to build two irrlicht DLLs like you do for dx8 and 9 now. I'm not trying to preach, but the extension system of OpenGL is a work of art... ever wondered why we have a single OpenGL driver? One irrlicht interface handles OpenGL 1.2,2.1,3.3 and 4.0, cards with geometry shaders and fixed function only are all handled by the SAME DRIVER CLASS.

See my point?

Since the introduction of feature levels in D3D11 you can use a single driver for DX 9.1,9.2,9.3,10,10.1 and 11, so that argument isn't exactly valid (also, people who still have hardware with only DX8-support should get over themselves and upgrade)
Writing different shaders for different supported shader models would always be an issue independent of whether you have 1 uber-driver or a couple of separate drivers, and this problem gets a lot less complicated if you do some decent shader management

I support all feature levels available in D3D11 through a single interface in my own engine, and in the end I don't find it a pain to manage

3DModelerMan · Post by **3DModelerMan** » Fri Jun 17, 2011 10:41 pm

Yeah, with DX11's feature levels we could just have all the drivers higher than D3D 9.0 in a single class.

Irrlicht Engine

Project proposal: IrrTech

Does this sound like a good idea to you?