with regard to the quaternion::getMatrix* methods:

You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.

Re: with regard to the quaternion::getMatrix* methods:

Postby hendu » Sun Mar 19, 2017 9:29 am

Yeah, one-liners got in "reasonably fast", about two months on average. Do you know what gives the impression nothing gets looked at? That there are no comments ever. It just stays as is for months or years, then the one-liners suddenly send a "closed" mail, while anything bigger, even if self-contained, languishes. There have been some exceptions like the b3d writer that got applied fast, but sadly the rule is "it takes ages, and probably nothing happens".

That really, really discourages contribution. Some months back I told the Webkit project to go fsck themselves, having left my patches, submitted according to their written procedures, languishing for two and a half years without a single comment, then having the nerve to ask me to rebase. My irr experience is not much better. I don't even know why I'm still on this forum, pure inertia I guess.
hendu
 
Posts: 2585
Joined: Sat Dec 18, 2010 12:53 pm

Re: with regard to the quaternion::getMatrix* methods:

Postby CuteAlien » Sun Mar 19, 2017 1:13 pm

devsh wrote:CuteAlien, you do realize that geometry shaders are in irrlicht because I did post a patch at some point?

Actually didn't know about that (I didn't even know Irrlicht has geometry shaders, not seen anything about that in the API so far).

devsh wrote:Also I posted numerous classes for SIMD etc. and nobody reached out, its hard to make something that works in 4 days and spend another 14 organising it nicely so that you can integrate it as if on a platter and end up complaining anyway that its API isnt coded around DirectX 8.1 and doesnt provide 80 different fall-backs...

Posting classes and expect someone else works through it to make patches...yeah - simply isn't going to happen. And yes, we care about breaking API. It can be done, but it has to be explained well. You didn't, you just continue to rant about bad Irrlicht architecture in a nearly weekly basis, but never really try to explain your stuff. You seem to kinda expect everyone know it's automatically better, but - we are all working on very different stuff. For example I need shaders very, very rarely and my only speed troubles right now are in the loaders while I simply don't have speed problems at runtime at the moment in my projects. Or at least none that are fixed by SIMD operatations as my bottlenecks are not in the vector/matrix operations.

devsh wrote:12-9 months ago it would have still been possible to actually extract stuff from our fork and make a patch out of it (when changes were few and far between), but due the causes of which I outline a few below I had to take an axe to Irrlicht and fork so far that making nice patches for vanilla Irrlicht would amount to me doing two loads of development at once and being a backdoor Irrlicht developer hoping that you kindly look at my patches and process them (hopefully within a few years).

As mentioned - I'm fine when you do that and go on with your stuff. But then do _not_ rant on a regularly basis about Irrlicht here in the forum. Because it's not like you are helping in any way. Only thing you do is piss me off constantly until I explode like I do in this thread.

devsh wrote:The API of irrlicht needs a huge change because implementing any new feature in a coherent fashion is impossible in the current legacy workflows which emerge from Irrlicht clinging onto DirectX 9 (i.e. if one was to implement transform feedback we'd have to send triangles off-screen instead of use Rasterizer Discard).

I've examined every driver (except for software), and Irrlicht literally takes the form of a wrapper around DirectX 9 which attempts to fit any other API into the same rendering flows as a hammer an oversized square peg into a round hole.

If you disagree that the current gross outline architecture of Irrlicht (which has stayed the same since 2005-2007) doesnt need changing to better reflect today's hardware (where multithreading is common), I invite you to benchmark test scenes against my fork (I will re-create any vanilla Irrlicht fixed-function functionality like shadows externally through a plugin).

Yes, Irrlicht doesn't move fast because it has baggage of years. And it has projects using that stuff. Projects where people's job depend on Irrlicht continuing to work. I am in contact and sometimes working for those people, which might give me a different perspective on this stuff. All you have to care about is that it works for your project. You don't have to spend 90% of your time on maintenance and figure out if the bug-reports people send you are real bugs or not (mostly they aren't). You don't care if maybe you introduce new broken API's as long as it works for you because you can simply break them again. And this _is_ the way you should develop to get your game forward. But... it's not the way to develop an engine which wants to stay around. We had a bunch of engine-clones before doing that. Like spintz or lightfeather (2 of the most well-knonw, but there had been more). Only problem is - none of them is around anymore and people who did bet on those engines got left in the dust at some point. Irrlicht - yeah - you don't get much new stuff at this point. Mainly because we don't have developers for it (right now it's mainly Nadro and me and both of us don't work that much on it right now, but I hope REDDemon will also help out a little bit in the future). But we do still support it (basically every day). And we even still try to improve it - even if it goes on slower than you like. And people using the engine know what it does and know their code continues to work. After Irrlicht 1.9 we likely will break interfaces.. but there are still lot of open problems to solve until we have that. And some of those problems caused by the last changes. Changes take a _huge_ amount of time until every new problem is fixed, again something you simply don't have to care about for your single project.

devsh wrote:One thing I'd really like to point out that Irrlicht 1.8.4 has a performance breaking bug in its software Skinning which cannot be alleviated in any way without a major API change, it essentially prevents spawning more than 100 mobs playing different animation sequences without eating all of your CPU core time.
I think fixing things like that takes precedence over not breaking API, since if the library is stuck a decade behind and has sub-par performance and features why would one use it for a serious project?
Could the fact that Irrlicht is stuck in 2007 be one of the factors driving the decrease of activity on this forum in the last decade? (of course it isnt the main factor, that would be Unity and UE4/CryEngine being free)#

Yes, skinning is a problem. But what do you expect me to do? The coder is no longer active and I never had a problem with it in my projects. I never got a patch (or even a patch with explanation and examples) about it. If I ever run into it myself I might try to figure out a way to get some weeks spare-time financed to work on this. But in my current situation I'm glad if I can squeeze out enought time to handle bug-reports (do _you_ get constant bug-reports for your engine already? How to you plan to handle them once people start mailing you regularly?).

devsh wrote:I could understand if the focus of the engine is shifting to mobile/embedded devices then "freezing" the graphical capabilities would have been acceptable, but even GL ES 2.0 requires an API change unless of course you're making a pseudo DirectX9 API to GL ES 2.0 translation layer.

I actually use EGL ES 2.0 already in a project (h-craft on Android, the sources are on bitbucket if you don't believe it). Didn't breaks the API so far. But yes - switching to shader architecture will break the API. Which is what we will do for Irrlicht 2.0, but trying to do that in a way that doesn't suck. And old legacy Irrlicht will still be around probably for bugfixing.

devsh wrote:Finally there is a culture of GPU is a plugin/extension/icing in Irrlicht design, which in my experience boils down to a view of "anything can be done in software or some other way, GPU feature X is just 'a nice to have' and provides a small boost" . This is how we ended up with a convoluted Occlusion Query API, blend-states compiled into shaders or even into Render Targets, MRTs which reattach their textures to binding points every time they are set, depth buffers latched to the first texture of an RTT or MRT which is opaque to the user, vertex buffers which upload just before drawing command using them (massive frame stalls) etc.
Also there are simply certain things which you cannot do without DX10 or DX11 functionality; particle systems over 10k particles, any decently performing deferred rendering...

Yes, it's a problem you have with an old engine. Changing it is hard. Irrlicht 2.0 might change it, but plainly - it's nothing I care about too much. Because it's simply not problems I run into. You have a very specific project which is dependent on that stuff. But how many indy-developers are there with projects as large as yours? I think most Irrlicht users want a simply to use engine. And mixing complete flexibity of shaders with nice to use support functions is not that easy. The most common approach is that everyone writes again one layer above shaders (like a standard way to pass on camera and variables). Which then again kills the flexibility a little, while keeping it a little alive, but that's again a new API you have to design first. Unless you don't care and write shaders again just from scratch to fit your own project in which case that all doesn't matter. And everone else using the engine has to do the same. Great. **** all the beginners who want a simple engine to use.

devsh wrote:I understand that once upon a time these design choices made sense, and that irrlicht was developed with the utmost love and dedication, but sometimes not moving forward/standing still equates to moving backward

Yeah, but we can't move forward without having developers for it. How to move forward if you don't have the time and no-one helps out with patches which came with explanations and examples so it's actually possible to add them? Instead we got you saying - we got that stuff in our engine - figure it out yourself. I can't - I don't have the time for it. I barely have the time to make living currently. The time I spend on Irrlicht forum every day is already hard to handle sometimes.

devsh wrote:An open -ended question I'd like to ask you, is why do you develop and release new versions of Irrlicht, what is your aim and end-goal?
Bugfixing/EoLS?
New Features?
Performance Improvements?
Quasi-DirectX9 API for all platforms?

Basically - supporting the projects who work with Irrlicht. Bugfixing is the most important to me, because bugs affect people the hardest. Features - generally when I run into something I need I do code it. Or if it's a patch that can be applied easy (big bonus if it's explained what it does and comes with examples) I generally also do that. Perfomance is always nice, but when it comes with api-breaks it means usually more time to invest than I have. So hard to do for me (I did add the code-profiling in Irrlicht 1.9 to help finding some bottlenecks). And right now - I have open bugs to work at (last one I worked at turned out not to be a bug again...) generally that's what I spend most time on. Right now open bugs in filename-handling (one fix broke another thing), in the new texture lock feature (conflicts with ttf-fonts), in the light-api (that was the non-bug, but still have to figure out parts of it so I don't mess up new documentation as old one is wrong), toolbar placement (trivial), string::split (trivial, but working on it for the 3rd time, hard to motivate), billboard drawing (bboxes wrong), render-sorting (one of the biggest bugs to me as it messed up transparency because it sorts by distance to cam instead of distance to near-plane), maybe particle emitter (borderline between bug and bad feature as something got deliberately changed in the past which is now confusing). And... a few more I have not even looked at yet because lack of time.

@hendu: Yes, simple bug-patchess are applied easier. I can't apply patches about stuff I know nothing about. Like - I know what a texture is and what an array is, but I never needed or worked with texture-arrays. So seeing a patch about that without explanation or example, what should I do? I can start reading up on google what people use that for. Then I can start figuring out your patch and start writing an example to figure out if it works. But why should I bother with that in my spare-time? I have always more than enough open bugs to handle to spend all the time I have on. And if you - who wrote the patch - can't even be bothered enough to spend time on it to explain that stuff and write examples, uhm, yeah. Don't get me wrong - I am very glad you post those! Because _if_ I ever get into it (for example once I need it in my projects), then I have something to start with. And same is true for anyone else.

You know I would give you svn write access if you want your patches really in Irrlicht, but you refuse that... I don't know what else I _can_ do. I don't have enough time. I don't have a way to fix my health so I can work more (struggling hard enough to get hours in my real job to pay my rent). If you have any other idea I'm open to it. But I'm _not_ going to blindly apply patches about stuff I'm not familiar with. Otherwise I'm far too scared it will break even more things.

I was in the same situation as you. I didn't code Irrlicht, but I'm also just a guy who did hang around the forum and wondered why my patches were not applied. Until someone in the team was annoyed and gave me svn access and told me to do it myself. I still am mainly a user really - I work with Irrlicht every day. And as long as it works I'm happy with it (Irrlicht actually works well for me most of the time). And sometimes I try to give stuff back and spend my spare-time on it as well. But only as much as I can. You kinda expect me to spend my time on stuff you want in the engine because you don't want to spend time to add it. Which again - I understand! I'm already glad that you spend time to write the patches man! But I'm not getting payed for this or so, I'm simply another guy on the Internet who spends some spare-time on something and sometimes I don't because I want to do other things. So as long as I don't really need those features (and don't even know what they are used for), it's pretty hard for me to motivate myself to work on those patches. Also I already got a list of stuff I really want/need to have fixed. Sorry I can't add more of your patches, you got some right to complain there, but I think you understand the reasons it doesn't happen. And you don't bitch and rant about Irrlicht (or at least not that I'm aware of.. ) and demotivate the core-team. And _that_ is the part that made me explode here. Someone not doing patches or trying to help much, but ranting more and more recently and posting in all kind of unrelated threads about how his engine is better and Irrlicht is horrible etc... makes me wonder how many feature-wishes from others which he didn't himself need in his engine devsh has applied so far?
IRC: #irrlicht on irc.freenode.net
Code snippets, patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Free racer created with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
User avatar
CuteAlien
Admin
 
Posts: 8300
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

Re: with regard to the quaternion::getMatrix* methods:

Postby hendu » Sun Mar 19, 2017 6:40 pm

My texture array patch did include a sample, posted in the forum thread, with screenshots. The one with the ones on the left and twos on the right. That thread also explained what the feature is and what it's useful for. IIRC I linked to it in the patch ticket, and IIRC you also posted in that thread.

I also know you're busy, and about the health issues. I'm not blaming you for those. I'm just saying the pace is one of the reasons for the dwindling contributions, and part of why I don't bother anymore. Seeing the "so just submit patches" when they'd most likely not be used triggered me to write all this, even though devsh's rants annoy me too.
hendu
 
Posts: 2585
Joined: Sat Dec 18, 2010 12:53 pm

Re: with regard to the quaternion::getMatrix* methods:

Postby CuteAlien » Sun Mar 19, 2017 6:54 pm

OK, sorry, texture array patch was another problem for me. That one was for the shader branch in which I am unfortunately not involved at all so far (and probably on-one else as Nadro writes another implementation for shaders, so I suspect that branch is dead unless one of the programmers who created that branch comes back... I don't even know who did create that one, Hybrid maybe?).

And sure - there are troubles (like a branch with 0 maintainers left). Just... rants against Irrlicht (or constant nagging) won't help. Just wastes even more time 'n energy. And having patches is always better than not having them. I know it hurts Irrlicht that we don't have more people with time to work on it (and also I'm aware of many short-comings, I just tend to not use Irrlicht for such stuff). And Irrlicht still works rather well for me most of the time, so also not exactly my main problem.
IRC: #irrlicht on irc.freenode.net
Code snippets, patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Free racer created with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
User avatar
CuteAlien
Admin
 
Posts: 8300
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

Re: with regard to the quaternion::getMatrix* methods:

Postby CuteAlien » Wed May 10, 2017 12:00 pm

OK, ignoring the rant sections in this thread and going back to the original topic

It got changed already, but I found now one good reason not to normalize first. Which is - you might call getMatrix several times for a quaternion and you don't want to normalize each time.

Also looking at the functions - we do definitely create non-normalized quaternions, not just because of floating point operations. But also functions like lerp and slerp to not normalize again. Also operator+ certainly creates a non-normalized result. But... I wonder if we shouldn't care more about keeping it normalized. I don't think a non-normalized quaternion even does work correctly with rotations - so currently not quite sure if we don't create problems with our lerp and slerp functions. Unfortunately my understanding of quaternions is not that good - so I'm not exactly sure if/how non-normalized quaternions can be used exactly.
IRC: #irrlicht on irc.freenode.net
Code snippets, patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Free racer created with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
User avatar
CuteAlien
Admin
 
Posts: 8300
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

Previous

Return to Bug reports

Who is online

Users browsing this forum: No registered users and 1 guest

cron