Project proposal: IrrTech

3DModelerMan · Post by **3DModelerMan** » Mon Jun 13, 2011 1:17 pm

I was thinking about the amount of feature requests the developers are getting (like DX10/11 drivers, more flexible material system, etc). It seems like an awful lot for them to do on their own. I was thinking that maybe a bunch of users should form a project to submit patches to Irrlicht that implement some of the features on the Google Summer of Code feature wishlist, and other ones that have been requested, or even just performance enhancements. The only thing we would need is enough users willing to participate, and the devs to be accepting of a project like this.

Radikalizm · Post by **Radikalizm** » Mon Jun 13, 2011 1:22 pm

Sounds like a nice idea to me, and I'd be very interested to help
The only issue might be that it'd be possible that I won't have too much time to work on it, so my contributions would be rather small

3DModelerMan · Post by **3DModelerMan** » Mon Jun 13, 2011 1:45 pm

Yeah, sometimes it would be that way for me too. That's why I was thinking a bunch of us could help out. I still need to hear input from the devs though.

devsh · Post by **devsh** » Mon Jun 13, 2011 1:47 pm

I still have the XML shaders patch laying around, If that gets accepted then I can make an XML material patch

CuteAlien · Post by **CuteAlien** » Mon Jun 13, 2011 2:01 pm

I prefer if people who want to code on Irrlicht start out by improving existing code. I know it's always more fun writing new features, but it's hard to integrate complete new stuff from people from which we don't know already that they can write good patches. The unfortunate truth is that many patches don't work at first, don't come with any tests or just don't solve a problem generally enough.

If you wonder how to find simpler problems - well, I must admit I run into them all the time without even looking. Giving feedback on open problems on the trackers is one way. Doing any kind of tests is one way (figure out which features work in model-loaders for example). Or just debugging any problems into which you run down to the bug itself instead of just reporting it as soon as it looks like it might not work (man, would that save a lot of time *dreams*).

serengeor · Post by **serengeor** » Mon Jun 13, 2011 2:04 pm

I would like to see more people improving existing code too before adding new features. The existing code has still many bugs and performance issues to fix.

Radikalizm · Post by **Radikalizm** » Mon Jun 13, 2011 5:01 pm

Bug tracing and fixing should be something I should be able to work on too, and I'd gladly help, but I still can't guarantee that I'll be able to spend too much time on it

devsh · Post by **devsh** » Mon Jun 13, 2011 7:15 pm

I would like to see more people improving existing code too before adding new features. The existing code has still many bugs and performance issues to fix.

However what some seem to be unable to understand is that in order to do these, you need to rewrite/add new feature. For example the flexible vertex format should have been in ages ago, you were all discussing the best layout for a vertex where it would be best to allow the user to "create" an appropriate S3DVertex class off which a SMesh could be made with appropriate templates.

For example... the biggest downer of all: skinning and morphing. They could be done on HW and they would be 10x faster, but the patch would not get approved because some dev would not like the changes to the internal workings. And we are back to square 1.

serengeor · Post by **serengeor** » Mon Jun 13, 2011 7:24 pm

devsh wrote:...

I didn't meant these kind of changes aren't needed. But for example directX 10/11 driver should wait for a bit longer, since there are still problems with other older drivers that are more supported on more machines at the moment.

CuteAlien · Post by **CuteAlien** » Mon Jun 13, 2011 7:47 pm

devsh: You can write a new feature for yourself often in an evening. But when you have to maintain it for years afterward that means that each problem that's not solved correctly at first will keep on costing evenings and weekends over and over again. Don't think we don't want those features, but doing them wrong will in the long run be worse. And it's also not easy just letting someone else rewrite such core-features of the engine - we can't simply put the patches in until we understand all the consequences they will have or we get pretty soon into an unmaintainable mess (and we already spend a lot of time cleaning up dusty corners...). I'm sorry if stuff sometimes takes long (especially in the cases you mentioned...) - and having more people would probably be nice. But patching the core of the engine is still nothing anyone should do who doesn't already know the engine well and for example did a few patches in other areas first to get a feeling for it.

3DModelerMan · Post by **3DModelerMan** » Mon Jun 13, 2011 10:47 pm

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.

Kalango · Post by **Kalango** » Mon Jun 13, 2011 11:44 pm

The problem with this idea is that not everybody codes like Irrlict is coded. Some OOP articularities and language convensions are not followed and devs may have to adapt it to be good to read or whatever. Also compatbility and that stuff gets in the way sometimes. And also there is the bloating talk...
I personally wanted to see the CG shader language support made by Nadro default, is been there for a while and now it seems Nadro left it (and Irrlicht) and moved on because of these kind of limitations and "secutiry" the engine has.
Its way more complicated than just write code and get it working on your PC.

LizardGamer · Post by **LizardGamer** » Mon Jun 13, 2011 11:50 pm

I would love to help, if only I knew C++ which I will mostly likely learn in the near future once I've done Java

3DModelerMan · Post by **3DModelerMan** » Tue Jun 14, 2011 2:46 am

I think I will not go on with the idea of a full blown project on Sourceforge for this. I think instead, I will implement the bugfixes and small improvements that Cutealien suggested. I will make sure to PM anyone who is interested whenever I start on a large patch though. Compressed textures, cubemaps, and volume textures are something I would probably need help doing for example. For now I will just do the small improvements, and release most of the other ones as add-ons for Irrlicht. I have a great shader system that I've been planning for a while that would be perfect as an external add-on. One thing that I think would be nice though; is to have a categorized add-ons page on the wiki that's linked to on the download section of the main page. It's kinda useless developing an add-on that no one knows exists. One thing I noticed could be improved is that the GUI environment doesn't allow multiple font sizes, or different kinds of fonts on the same kind of GUI element. So anyone that wants to know when I'm about to start on something large; just PM me and I'll make sure to tell you before I start in case you want to help.

hybrid · Post by **hybrid** » Tue Jun 14, 2011 6:02 pm

If you don't like the idea of just submitting those things to the patch tracker, you can also become a member of the irrext project. We won't feature a full branch of Irrlicht there, but you can host patches and add-ons more user-friendly than with just bare patches. You can provide test cases, usage examples, etc. Just come up with soem ideas and apply for membership there.
The problem with the Cg add-on was a complete change of the current shader interface. I was working on a unification for some time, but postponed it due to other more important things to do. If someone will boil down irrCg to the current shader interface, or just a slight extension, it'd be more likely to get it integrated soon.
The flexible vertex format might become more important once we have the shader based drivers in the engine. As it seems opengl-es 2.x will make the lead. And as this driver proves, there's also a way to integrate current Irrlicht with fixed-pipeline-free drivers. But to be honest, I didn't have the need for the flexible vertex format so far, and so it's not as high on my own priority list. But having example implementations, and maybe even a maintained add-on patch in irrext, would also help for a faster integration.

Irrlicht Engine

Project proposal: IrrTech

Does this sound like a good idea to you?

Project proposal: IrrTech