- Only the getRotationDegrees without parameter is allowed to try fixing scale.
My fault when I added a new function which takes scale parameter, that one is
not allowed to be changed.
On the up-side - we know have for the first time an option which works in cases only
scale and rotation had been used and the user still has the correct scale.
Before any solution for that was broken
- getRotationDegrees fixes 2 places which caused wrong results due to floating point inaccuracies
New test for that got added
- Document the current restrains and problems of getRotationDegrees and getScale some more.
- Improve docs for other matrix4 functions.
- Add some comments about further improvements (I'll try if I find time)
Note: Irrlicht still assumes in at least 2 places (getting bone animations and Collada loader) that matrix
decomposing works. Which it doesn't yet for matrices which switch handedness (or have further transformations like skewing axes)
The bone animation is mostly fine for now with recent workaround (but that might cause other problems as it may be used too often), haven't checked Collada yet in detail.
TL/DR: This improves things with getRotationDegrees, but does not yet fix all troubles.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6439 dfc29bdd-3216-0410-991c-e03cc46cb475
First problem was that IGUIElement::getNextElement wasn't passing includeInvisible and includeDisabled flags recursively, so anything deeper than one level could fail if an element was disabled/invisible in between while it was created.
Second problem was that setTabOrder(-1) did ignore disabled elements. So when any parent was disabled when elements were created they never got a tab order.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6428 dfc29bdd-3216-0410-991c-e03cc46cb475
color intitialization has some cost, but we initialized all other values already (vectors are always set to 0).
Don't think it's a good idea to have one value around which is random.
S3DVertex2TCoords(S3DVertex& o) to S3DVertex2TCoords(const S3DVertex& o) simply because it makes more sense
S3DVertexTangents(const S3DVertex& o) added because I'll need it later (and no idea why only S3DVertex2TCoords got one of those before).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6359 dfc29bdd-3216-0410-991c-e03cc46cb475
Other functions like getMaterialRendererName got switched to u32 in the past. I can see no reason why this one was left out, so changing it to be same as the rest.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6300 dfc29bdd-3216-0410-991c-e03cc46cb475
The commit also establishes a precedent of leaving off the `virtual`
keyword in overrides. Although not strictly necessary, I believe this is
good for readability because it makes it clear it is an override and not
a pure virtual function, and it helps keep line lengths shorter. We
should move towards eliminating the macro altogether, but the definition
has been left in with a note on deprecation so that in-progress work
will not suffer merge conflicts.
So uv-coordinates can now be modified directly (previously only possible via texture matrix).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6299 dfc29bdd-3216-0410-991c-e03cc46cb475
That was a bad case of premature optimization.
Multiplication is indeed faster, but when working with floats this can introduce some rather unexpected inaccuracies.
Like x/x suddenly no longer being 1.0 (something guaranteed by division).
If someone really needs this back, then please add some new function which makes it clear we don't just have a typical division here.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6298 dfc29bdd-3216-0410-991c-e03cc46cb475
Just safer. Could probably do in a lot more places... another time.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6293 dfc29bdd-3216-0410-991c-e03cc46cb475
Lets just keep this one around. Easy to use, downward compatible and generally works as expected.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6259 dfc29bdd-3216-0410-991c-e03cc46cb475
