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.
Mel
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

with regard to the quaternion::getMatrix* methods:

Post by Mel »

Shouldn't they make sure the quaternion is normalized first?
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

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

Post by CuteAlien »

I guess it could be mentioned in documentation (does it fail when it's not normalized? I actually don't know...). Doing extra operations just to be save for the case which I suppose is typical is probably too expensive.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Mel
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

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

Post by Mel »

Not normalizing would add aditional unwanted scalings into the matrices, i.e. the rotations may remain correct, while the scales become deformed. Maybe it was done like that because quaternions always remained normalized, but i can't tell. And i remember doing some dual quaternion skinning tests that resulted in really messed up results that i couldn't figure out why at the moment i did them, but maybe they were because of the quaternions not being normalized, so it is not an skippable step, the good thing is that it only takes 3 adds and 4 multiplications to check if a quaternion is normalized because a normalized quaternion is 1 in length, and thus the square root is also 1, if it has to be normalized, you can do it before the matrix calculation. Maybe it would be a good idea to stress tests them?
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
REDDemon
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

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

Post by REDDemon »

They don't remain normalized, even if you chain normalized quaternions on the long run they become un-normalized due to floating point mechanics.
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

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

Post by CuteAlien »

REDDemon: OK, please change it then. Chance for a check-in :-)
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
REDDemon
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

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

Post by REDDemon »

It should be normalized indeed we could add the chance to not normalizing it (in example the user already know it is already normalized), but in the general case it should be normalized.

.. EDIT:

Any particular reason why irrlicht use C math functions instead of C++ maths? C++ provide chance for faster functions in some cases.

(in example std::sqrt I believe is faster than sqrt because is natively float and not double allowing to choose another overload).
Last edited by REDDemon on Fri Mar 17, 2017 2:44 pm, edited 2 times in total.
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

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

Post by CuteAlien »

Yeah - reason is that Irrlicht does not use STL. We will very likely change that after Irrlicht 1.9 (had some poll about that recently). Thought I wouldn't expect a float function to be faster really (it's really, really, really hard to tell anything about speed without profiling. But at least at some point with some computers in the past or maybe even present all float calculations tended to use doubles internally on the processor most of the times which made them add 2 conversions and thereby they often were slower than their double counterparts).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
REDDemon
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

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

Post by REDDemon »

ok 1 problem with normalizing the quaternion before matrix conversion is that quaternion value changes, which could be unexpected. Should I add a local copy inside "getMatrix" methods (which is slightly slower, but avoid potential code breaking) ?

Yeah the float version may not be faster, but using the most specific possible method/function usually helps the compiler with optimizations etc. though if we are not allowed to use

Code: Select all

#include <cmath>
in current trunk then I'll keep math funcitons as they are
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

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

Post by devsh »

loving the argument over C vs C++ math functions while being dismissive of SSE3/NEON
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

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

Post by CuteAlien »

@devsh: Seriously, is snarky comments about Irrlicht or advertising for your own engine all you have to add to posts by now? We're not dismissive of SSE, but last time it came up it turned out that it needed changes to irrArray or switching to STL. The latter is planned for Irrlicht and no one (including you) wrote patches for the former.

You can do other stuff in your engine because you don't have to care about breaking code of people using your lib - because it's new. It is always easier to write new stuff than maintaining a library long term. Irrlicht is simply not the same situation (and I would not use an engine for a serious project where the developers don't care about stuff like library interface compatibility).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

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

Post by devsh »

I can give you a patch for irrArray, and templates on new* delete* operators including declarations of aligment, will work with legacy irrlicht 100%.

99% of the time I say IrrlichtBAW has it, is because it has it and you can pretty much copy it verbatim, not because I want people using my engine.

I would obviously have a whole big argument on why you will eventually need to break the API.... but lets not get into that
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

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

Post by CuteAlien »

I won't complain if you actually started posting patches. But this constant - you just have to figure it out yourself by reading through our engine code in your spare-time... is _very_ annoying. No one is going to do that. And I'm not sure I've seen any real patch from you so far.

edit: Btw, I'm also fine if you don't post patches and just spend your time on developing your engine. Post your progress in your thread like you do anyway. That's great and I'm glad you get your project forward. It's just the mixture of never sending any patches ever & still acting all the time like Irrlicht should take all this from IrrlichtBAW which I can't stand. Either help or don't. But not helping and then making fun of Irrlicht constantly despite starting your own engine with Irrlicht's sources - that just sucks.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
hendu
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

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

Post by hendu »

FWIW, I'd say 98% of my patches have not even been looked at.
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

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

Post by CuteAlien »

@hendu: Most have been looked at, just not all accepted. You know I would prefer if you just joined the team anyway ...

But took a quick look at patch-tracker, it's really not that bad I think.

Open:
- Static IQE, don't know anything about that format, so hard to comment.
- Instancing would be cool, but yeah, I got no experience in that area and no tests. Other 2 people commented on it and never applied, don't know why.
- Seems Nadro looked at your texture-array patch, but I don't know status
- The different sort-order patch got discussed a few times already and I did some more tests recently (while debugging something else). I didn't get your results really, I get faster results with sorting by texture as different materials types are usually already in different render-stages. Texture-differences just play a bigger role mostly as having few material-types and many textures is pretty common. Real solution here is likely allowing custom sorting which would also fix some other troubles. It's on my todo (but not on top).
- Don't know about GL RTT stencil patch, that texture stuff got rewritten by Nadro recently, no sure if that made it easier or harder to apply
- I don't know if the override material patch is a good idea or not, but there's been some discussion so at least people looked at it.
- BSP texture search patch had the problem that it was fixing one place, but texture loading had a general problem in ~15 places (every loader). I unified the texture loading code for most loaders by now. But BSP had been one of the troublesome ones because unlike in most loaders bsp-nodes do the texture-loading instead of the mesh-loader doing it. I don't know why, but the better solution here would be to use the new common texture loader. But that's still some work (as I didn't write all that code and never used BSP myself so rewriting it is pretty hard). But OK, I never commented on it ... but this was the only one from you I found right now without any comments. Maybe missed another, but definitely not 98% :-)

All those got applied:
- Static B3D writing support
- Support for RG texture formats
- Bounding box intersection support go applied
- C++ override macro
- utf-8 patch
- Brush entities (yeah, couldn't bring myself to add also the new example for it as I still think it should probably be added to an existing example, so it's partly open).
- geoplane
- heightmap mesh optimization (I think - only says closed?)
- degenertated tris in weld fix
- obj writer fixes
- sphere frustum culling support
- radius of a bounding sphere
- Solaris autoconfig support (ok, we no longer support that now as we don't have anyone left who has a solaris system)
- Track gl matrixmode
- OpenGL uniform cache
- config option to disable XML
- Separating MemoryRead and MemoryWriteFiles
- Allow cameras to update matrices without uploading to driver
- Many bugfixes (you do a lot and we tend to apply them, if we missed one there please complain!)
... ok, stopping now, I think the list goes on (and I'm glad it does...).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

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

Post by devsh »

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

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...

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).

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).

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)#

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.

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...


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


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?
Post Reply