Bitfields for PolygonOffsetDirection, ZWriteEnable and BlendOperation were chosen too small.
As we have pre c++11 code and therefore didn't use unsigned qualifiers for enums they were generally signed (up to compiler in theory, but I think they all choose signed).
Which means the bitfield also had a sign.
So for example setting PolygonOffsetDirection to EPO_FRONT set it to -1 instead of 1.
Which then would fail with comparison checks (PolygonOffsetDirection == EPO_FRONT would be false).
We kind of got lucky that we usually not checked for the last enum inside Irrlicht, so it worked to due being the "else" case.
Or in the ZWriteEnable case the last one was identical to the default return value so it also worked accidentally.
But obviously still wrong and user code could be messed up.
While at it I also re-ordered SMaterial variable so most bitfield variables are close together again to give compiler at least a chance to use packing. Thought at least in my quick debug compile test it didn't seem to use any packing (but maybe on other compilers).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6440 dfc29bdd-3216-0410-991c-e03cc46cb475
- 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
ISceneNode::setUpdateAbsolutePosBehavior can now control what ISceneNode::updateAbsolutePosition really does.
Having only the position and not the rotation/scale of a child node affected by the parent transformation was previously impossible inside the scene-graph. So people always had to break the scene-graph and code it themselves.
Old behaviour is default.
Extra check for new variable has a small cost, thought new behaviour can actually be faster when it's used.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6432 dfc29bdd-3216-0410-991c-e03cc46cb475
Also documenting some missing feature (decimal places ignored with direct text input)
getValueFor allows to check the value a given text would have
getOldValue can be used to check the previous value in a EGET_SPINBOX_CHANGED event
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6429 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
(I forgot normal update is certainly also needed on rotation)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6420 dfc29bdd-3216-0410-991c-e03cc46cb475
Also only update normals now using inner 3x3 matrix (same result usually as last column is 0,0,0 but faster)
And adding some comments.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6419 dfc29bdd-3216-0410-991c-e03cc46cb475
Making it a bit more comfortable for users to implement the class.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6418 dfc29bdd-3216-0410-991c-e03cc46cb475
Not optimal, but making this real 32-bit is sadly a bit more work.
This way at lest meshes with mixed 16/32 bit buffers can weld the 16-bit ones.
And hopefully a bit of step in the right direction to fully support 32-bit another day.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6417 dfc29bdd-3216-0410-991c-e03cc46cb475
Lazy access function - same as for all other members of S3DVertex (getPosition/getNormal/getTCoords).
Not sure why color was missing, maybe got added later?
Would probably be better to have a getS3DVertex function instead which would cover them all, but it's only some slow (but nice) helper function anyway.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6415 dfc29bdd-3216-0410-991c-e03cc46cb475
Cameras can render even when they are not in the scenemanager or onAnimate didn't get called for example because they are their parent are invisible.
So let's be safe and add another call to updateAbsolutePosition(). Some cost, but usually we don't have that many rendering cameras, so shouldn't matter (if it ever matters I suppose we could override OnAnimate and add a flag if it _was_ animated since last render call. Maybe that's even useful in general for SceneNodes?).
Similar CSceneNodeAnimatorCameraFPS was using getAbsolutePosition which was only updated after animators, so it was one frame behind.
And documented ICameraSceneNode functions a bit. Especially updateMatrices is a bit of a confusing name unfortunately.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6406 dfc29bdd-3216-0410-991c-e03cc46cb475
Sorry, didn't think it through. Seemed to work at first, but works only if sort() ended up creating the same sorting as is used then for search.
While often the case, this is obviously not guaranteed. And can't do sort per type easily (this works with flags which remember if sorting had been done).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6399 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously search functions only worked when called with the same type as the array elements had.
Which forced users sometimes to create dummy objects to be able to search for elements by another type.
linear_search and linear_reverse_search now work with any type for which <T>::operator== is implemented.
Similar binary_search now works when <T>::operator< is implemented in both directions (T < E and E < T).
Note: It might be possible to further improve binary_search so only one operator< is needed (I think STL managed that somehow).
So if someone likes a challenge - have a go at it! :-)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6398 dfc29bdd-3216-0410-991c-e03cc46cb475
Avoids lots of const casts and there shouldn't be a good reason to have those non-const.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6396 dfc29bdd-3216-0410-991c-e03cc46cb475
Just safer in case we add more cases. Also shuts up code analyser.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6390 dfc29bdd-3216-0410-991c-e03cc46cb475
It's to allow image loader to check for sane limits for image sizes.
Idea came from this patch from sfan5 for Minetest: dbd39120e7
Thought solution is a bit different.
Image loader checks not yet added (will come soon).
Also note that limit is to s32. While u32 might work mostly it will run into some troubles with color converter for now (which maybe could be changes). Also 2GB ought to be enough for anybody, right?
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6386 dfc29bdd-3216-0410-991c-e03cc46cb475
Only needs one addItem function when using default parameters for icon.
Add default parameters for setIcon, insertIcon so they can be used easier with pure text.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6384 dfc29bdd-3216-0410-991c-e03cc46cb475
Before the value was checked, but not put into the return variables.
Header update to show that information in kb not bytes (on all systems, was just documented wrong)
Some cleanup of code.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6369 dfc29bdd-3216-0410-991c-e03cc46cb475
- allow ICameraSceneNode to accept any values and correct in buildCameraLookAtMatrixLH with normalize_camera_direction.
if disabled defaults to the current v1.9 normalize
b) add initial Rotation to MayaCamera Constructor default 0,0
c) switchToMayaCamera in Examples. Clones FPSCamera default disabled
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6366 dfc29bdd-3216-0410-991c-e03cc46cb475
It's not 100% identical to what we had as I only copied up to MATERIAL_MAX_TEXTURES_USED before, but I think that was rather premature optimiziation.
(the cost for the extra textures is really in other places, don't think the copy here ever matters).
Was a bit based on Mintest patch, but they messed it up: 4931b34625
(because they didn't notice the difference between MATERIAL_MAX_TEXTURES_USED and MATERIAL_MAX_TEXTURES).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6363 dfc29bdd-3216-0410-991c-e03cc46cb475
I had somewhat rashly removed operator = in [r6280]
But since c++11 implicit defined copy assignment operator is deprecated when a user-declared destructor exists.
Still... alternative would be adding copy assignment operator but neither that nor the virtual destructor seem to be needed.
So rather removind destructor which seems to add an unnecessary virtual function table for it (seems to be just used like a POD throughout the code)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6362 dfc29bdd-3216-0410-991c-e03cc46cb475
See no reason for them. And would have to put back operator= and copy constructor otherwise (realized creating those is now deprecated when having a destructor defined).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6361 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously vertex buffer did some invalid casts to references which could cause it to copy whatever was in memory into the vertex-arrays.
Generally it worked up to S3DVertex - but switch from another type to S3DVertex2TCoords or S3DVertexTangents caused it to be filled with whatever was in memory behind it.
Setter functions in IVertexBuffer have now overloads for all known vertex types.
Also adding const version of IVertexBuffer::getData.
And some warnings in comments about using the array functions (if even we mess it up...)
Also de-deprecate IIndexBuffer::pointer() again. I don't like having 2 functions for same stuff, but in the end it doesn't really hurt keeping it around.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6360 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
CIndexBuffer::setType could end up casting a temporary u16 variable to u32& (reference!).
Probably never noticed as this tended to mostly works (guess next byte on stack often 0?).
To prevent this from happening again I modifed IIndexBuffer::push_back to work with copies instead of references.
While breaking the interface anyway I also deprecated pointer() which is just identical to getData() anyway.
I get the idea of staying similar to core::array interface, but it's just confusing (and not same due to lack of types anyway).
Also added a const version for getData()
On a side-note - same setType bug still in CVertexBuffer, but a bit harder to fix there. So will be an new patch.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6357 dfc29bdd-3216-0410-991c-e03cc46cb475
No point in repeating pure virtual functions
(maybe wasn't meant to be derived from IMeshBuffer at first?)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6356 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @sfan5 for patch for Mintest: 4931b34625
Forum: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819
Note - patch is not applied exaclty yet. SMaterial and matrix4 still missing (might be applied later).
Also patch was based on older Irrlicht and we removed a few already earlier this year (around r6280).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6355 dfc29bdd-3216-0410-991c-e03cc46cb475
Yeah, setValue is not enough and if getLast() works then this should work as well (when users are very careful...)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6345 dfc29bdd-3216-0410-991c-e03cc46cb475
Same as in IIndexBuffer. Needed as replacement for non const operator[] which can't be done for this interface (as type is dynamic).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6344 dfc29bdd-3216-0410-991c-e03cc46cb475
Did some tests and the overhead speed cost on loading and rendering where both not really measurable even in a pretty huge scene.
While some Irrlicht parts might still have a problem with 32-bit meshes (octree for example, also some meshmanipulator functions), it's probably still less of a problem than having broken meshes and just a nicer default. Also the troubling parts in Irrlicht can be improved over time.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6343 dfc29bdd-3216-0410-991c-e03cc46cb475
Giving the loader it's own enum allowed me to add more options.
EITH_OPTIMAL which reduces buffers back to 16-bit if they don't need 32-bit.
Using that in obj loader.
Also 32-bit meshes with EMT_PARALLAX_MAP_SOLID material should now work in obj loader (untested as I got no test-case)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6340 dfc29bdd-3216-0410-991c-e03cc46cb475
CMeshManipulator::createMeshCopy creates new meshes which have copies of the actual meshbuffers instead of copying everything into SMeshBuffers (which didn't support 32 bit or any of the other special features).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6335 dfc29bdd-3216-0410-991c-e03cc46cb475
- IMeshLoader::setPreferredIndexType and getPreferredIndexType allow setting hints for the loaders if users prefer 16 or 32 bit meshbuffers. Loaders are free to ignore those hints (all but .obj will do that for now).
- obj meshloader loads now 32-bit buffers when setPreferredIndexType is set to EIT_32BIT.
NOTE: It's 16 bit meshes use now also an IDynamicMeshbuffer instead of an SMeshBuffer.
That will break the code of people who accessed meshbuffer before by casting to SMeshBuffer*
And might even be somewhat slower (lot's of virtual functions...), but shouldn't really matter and can maybe be a bit improved.
Sorry about that, I considered keeping SMeshBuffer for 16-bit (still considering it), but it would add some overhead in code and I don't think it's worth that. If there are any complains I'll maybe consider it again.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6333 dfc29bdd-3216-0410-991c-e03cc46cb475
Allows to find out which class a meshbuffer has.
I used the same kind of style as ISceneNode::getType. So using four CC codes and virtual functions (instead of type variable).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6330 dfc29bdd-3216-0410-991c-e03cc46cb475
1 Meshbuffer with 24 vertices, so each side has it's own vertices.
Normals perpendicular to the cube-sides.
CubeSceneNode accepts now a ECUBE_MESH_TYPE
CubeSceneNode::clone now also clones rotation and scale (not sure why it didn't do that before - hope there was no reason, but can't think of any).
ISceneManager::addCubeSceneNode accepts now a ECUBE_MESH_TYPE and passes it through.
Example 22.MaterialViewer using new cube type. Also a few more beauty fixes there.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6313 dfc29bdd-3216-0410-991c-e03cc46cb475
