Remove comment that it's not working on OpenGL. Not sure when it got fixed, but it's implemented and seems to work as described.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6594 dfc29bdd-3216-0410-991c-e03cc46cb475
Also the case of start/end points being identical now avoids invalid numbers from division by 0 and just returns the start point
Basically it's now the same again as line2d::getClosestPoint (which also got a comment fix)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6593 dfc29bdd-3216-0410-991c-e03cc46cb475
Returns centers of the side faces.
Just another tool function to fatten up Irrlicht
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6591 dfc29bdd-3216-0410-991c-e03cc46cb475
Wish I could rename those functions, but that breaks a bit too much. So at least document that getEdges is about getting corners and not about getting edges.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6590 dfc29bdd-3216-0410-991c-e03cc46cb475
I tried to find out about this format, but last info seems to be from 2005 (https://irrlicht.sourceforge.io/forum/viewtopic.php?p=37385)
Website for it no longer exists and I also couldn't find My3DTools on any other place on the web.
We don't even have an example for it in Irrlicht.
Also CMY3DHelper.h introduces quite a bunch of functions and global variables in the irr::core namespace and I'm not really interested in spending time in cleaning this up.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6588 dfc29bdd-3216-0410-991c-e03cc46cb475
Instead of using same matrix calculations 3 times, getMatrixCenter and getMatrix now both call getMatrixFast.
Additional function call might be slight cost in debug, in release compilers hopefully inline it away.
Also getMatrix_transposed now split into getMatrix_transposed and getMatrixFast_transposed to make it similar to getMatrix.
This also avoids a bunch of level 4 warnings in VS about function variables hiding class variables, which was why I started on this. Thought I also prefer having less code here.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6587 dfc29bdd-3216-0410-991c-e03cc46cb475
I don't see the point of giving access to Indices and Vertices if they are of a class type which is private.
Now it's at least possible (with a few casts) to access the freaking array having the data which is often all we want.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6585 dfc29bdd-3216-0410-991c-e03cc46cb475
Mostly const fixes in headers to make it easier for users to have more warnings enabled in static code analysis
Also updating our own rules a bit (kicking some out we won't need yet).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6583 dfc29bdd-3216-0410-991c-e03cc46cb475
Double tessellation numbers for these 3 functions in your code to get same results as in Irrlicht 1.8
I noticed in last commit those all tessellated semi-circles instead of circles. I just documented it there, but it's annoying as that bug doesn't allow odd numbered tessellation. So for example one couldn't create a triangle pyramid.
I considered adding another parameter to describe what this number means, but... just too ugly. And it was always documented otherwise, so this could be considered a bug. Sorry if this changes the look of existing apps.
Also cleaned up code in CGeometryCreator::createCylinderMesh. No idea what the idea behind old code was. Aside from creating twice the tessellation numbers.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6581 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @randomMesh for reporting that they were missing: https://irrlicht.sourceforge.io/forum/viewtopic.php?p=307308
Also simplified that code a bit (same could probably also be done for createCylinderMesh, but too lazy right now)
Changed also UV's for top/bottom center vertex in CGeometryCreator::createCylinderMesh to use center for X (slight improvement, but would have to copy vertices to make it better)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6580 dfc29bdd-3216-0410-991c-e03cc46cb475
CTriangleSelector constructor with IAnimatedMeshSceneNode parameter didn't initialize MeshBuffer.
Not used internally, so no big problem, but it got passed back to users in some cases
Replaced SCollisionTriangleRange, by CTriangleSelector::SBufferTriangleRange. Was a bad idea to use a struct which is for something else just because some member were the same (my fault, sorry).
Also started unifying the case of using ranges vs not using them.
Can maybe even get rid of the non-ranges case in future. Or unify the duplicated code for getting triangles at least.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6579 dfc29bdd-3216-0410-991c-e03cc46cb475
If we already know we start with an identity matrix (which is usually the case) then copy will do.
Also unifying code to create matrix of different CTriangleSelector::getTriangles functions
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6578 dfc29bdd-3216-0410-991c-e03cc46cb475
So far it only used the inverse of the node transformation to calculate the box used to check
Which gave wrong results as soon as one tried to pass an additional matrix transformation
Wasn't ever used internally or by examples in Irrlicht, so I guess no one ever noticed (also in some cases this still worked accidentally).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6577 dfc29bdd-3216-0410-991c-e03cc46cb475
Same as most elements. Other behaviour a bit unexpected and unlikely to be useful.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6576 dfc29bdd-3216-0410-991c-e03cc46cb475
Sometimes you only think about better implementations when the work is done *sigh*
Can get back to it when we add custom sorting for solid nodes some day (another very old open feature request...)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6575 dfc29bdd-3216-0410-991c-e03cc46cb475
While there are some cases this fixes, like MartinVee's nice example for orthographic camera at https://irrlicht.sourceforge.io/forum/viewtopic.php?t=51598
it seemed to cause more problems in complex 3d scenes with perspective cameras.
Well anyway - both options are available now for those which need it.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6574 dfc29bdd-3216-0410-991c-e03cc46cb475
Adding 2 algorithms to sort by distance to camera plane instead of camera position.
This is better in quite a few situations and extra cost is just one vector subtraction per node and an additional function parameter per call, I think that's worth it. So made the camera-plane to object-center now the new default.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6573 dfc29bdd-3216-0410-991c-e03cc46cb475
Until last summer we sorted by object origin to camera distance
Since then we used nearest transformed bbox-extent to camera.
I've now added an enum to allow switching those plus 2 new:
- none (so sorting based on scenegraph instead)
- object center to camera. Which I made the new default as it worked the best in my tests.
I already experimented with a few more ones like different sphere sizes (bbox radius, minimal inbound radius, maximal inbound radius) around center or origin to handle objects with different sizes, but that just gave worse results for all my test cases.
Likely algorithms we should still try:
- Collision point with bounding-box in line between camera and object center (sounds a bit slow, but maybe worth it)
- Distance to camera plane (instead of camera position). But needs additional parameter to distance functions first (maybe normalized view vector will do). That should be useful when working with planar objects.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6572 dfc29bdd-3216-0410-991c-e03cc46cb475
A bit annoying that it kinda has the opposite meaning for png and jpg compression for same parameter (png compression goes up, jpg goes down).
Also unfortunate we chose u32 instead of int here or we could at least use the usual zlib value range for png.
But I think it still won't mess up in many cases. Defaults (value 0) stay the same as before.
And setting a jpg range <= 10 is rarely done and even if so it just changes png sizes a bit now if people use writer for both.
People just have to be careful now when they override defaults for png and then also write jpg - but can't help it.
And it's too useful to not have this - this can massively change the write-speed for png's (like up to 3 times faster with no compression on my system).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6570 dfc29bdd-3216-0410-991c-e03cc46cb475
Different UserData values are no longer by default causing materials to be different.
It now always checks in this case the IUserData != operator.
This allows more user control. Can still have them be different by checking pointers in overloaded compare function.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6569 dfc29bdd-3216-0410-991c-e03cc46cb475
This can't work as on deserialize it would need to have the type for IUserData already.
And that's impossible with the way it's used right now.
Would need some kind of factory or so probably, but I'll ignore this for now.
Note that it's still possible to call some serialization manually on the derived classes by adding it there if needed.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6568 dfc29bdd-3216-0410-991c-e03cc46cb475
Irrlicht generally avoided user pointers in the past, but after trying all kind of ugly workarounds - this is just easier and
not that much downsides really. Tiny speed costs due to additional SMaterial memory size and new comparison tests.
But allows to keep SMaterial alive and useful for a while longer without needing a complete rewrite and it can now be used for stuff like writing PBR shaders.
Using a new interface io::IUserData for this which also allows serialization the user data (that part is untested so far, sorry)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6567 dfc29bdd-3216-0410-991c-e03cc46cb475
LensShift got added recently.
Also there was some change in PolygonOffsetDirection longer ago (although that one didn't cause tests to fail)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6566 dfc29bdd-3216-0410-991c-e03cc46cb475
As Blender docs describe it so nicely: Using lens shift is equivalent to rendering an image with a larger FOV and cropping it off-center.
This can be quite useful for architecture renderings, but I guess also has it's use in other situations.
Note: Didn't make the ICameraSceneNode functions pure virtual so users don't have to update their cameras for this
Also some change in serialization - same as in other places by now, do use existing values as defaults values when they are not found instead of resetting them to 0.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6565 dfc29bdd-3216-0410-991c-e03cc46cb475
Returns now getMipMapsData instead which for now will always be 0 in this case (but might work one day)
Also removing comment about ITexture::lock() mipmapLevel parameter being broken. It got fixed in November 2019.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6563 dfc29bdd-3216-0410-991c-e03cc46cb475
Software driver sometimes works with original image (in 2D) and sometimes with POT version of the image (in 3D).
That is probably useful so it can draw the UI in best quality while having relative fast 3D.
The problem is that lock() only returns one data - so it decided to return the original data and then in unlock it updates the other data. But lock() data usually depends on getSize() so using EDT_SOFTWARE like other drivers causes crashes.
Not sure what the best solution here would be (maybe more flags or more lock functions?), so I just document the deviating behaviour and leave it as is.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6559 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously we handled all sizes as unsigned, but Windows BMP files can have negative height to signal top-down images.
No clue about left-right (would be trivial to swap as well, but found no info so far if that would be correct)
Also casting away some new compile warning in gcc for COBJMeshFileLoader
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6558 dfc29bdd-3216-0410-991c-e03cc46cb475
Caused by recent patches for 1.8 - which still had different parameter types in IReadFile::read
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6557 dfc29bdd-3216-0410-991c-e03cc46cb475
All about bounds checks and preventing buffer overruns in b3d and obj files based on sfan5 patches for Minetest
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6554 dfc29bdd-3216-0410-991c-e03cc46cb475
Just updating changes.txt (stuff got backported, so changes are now mentioned in 1.8.6 instead of 1.9)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6550 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @sfan5 for report and patch
Was part of the Minetest commit 80e1609 patch which was applied earlier
(couldn't apply this with the rest as the rest could be fixed in Irrlicht 1.8, while this one is about new Irrlicht 1.9 code)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6548 dfc29bdd-3216-0410-991c-e03cc46cb475
Rest of Irrlicht is using left-handed rotatations.
But 2d vector rotations all uses ccw which is kinda the same direction as this one if you consider those as rotations around Y, so I guess that was maybe the reason back then.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6536 dfc29bdd-3216-0410-991c-e03cc46cb475
Image size calculation could overflow s32 in one place (but not others where it was done correct), which first lead to wrong amount of memory getting allocated for image data and later crash in the CColorConverter.
Thanks @sfan5 for his fuzzing tests @https://github.com/minetest/irrlicht/issues/236
and @erlehmann for passing them on: https://irrlicht.sourceforge.io/forum/viewtopic.php?t=52925
Also updating changes.txt with TGA loader changes from this and previous commits.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6535 dfc29bdd-3216-0410-991c-e03cc46cb475
From sfan5's fuzzing test reported in Minetest here: https://github.com/minetest/irrlicht/issues/236
Was missing test if it writes beyond allocated memory which can be triggered by TGA's which lie in their RLE data.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6534 dfc29bdd-3216-0410-991c-e03cc46cb475
Was creating 16-bit images for those before.
Could also support 24-bit images, but either we need another convert function or another palette for that (the 16 and 32 bit both work with 32 bit palettes, the 24 bit conversion function only with 24 bit palettes)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6533 dfc29bdd-3216-0410-991c-e03cc46cb475
TGA's can claim to use less palette colors than they later do.
We only support 8-bit palettes, so to make this safer lets just always allocate at least 256 bytes.
Thanks @erlehmann for report and testcase: https://irrlicht.sourceforge.io/forum/viewtopic.php?p=307191
Based on Minetest bug report: https://github.com/minetest/irrlicht/issues/236
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6532 dfc29bdd-3216-0410-991c-e03cc46cb475
Parameter already called fovy, but shouldn't hurt to mention it twice
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6531 dfc29bdd-3216-0410-991c-e03cc46cb475
We had 4 near identical functions, those now all call buildProjectionMatrixPerspectiveFov
They were a bit hard to check for errors otherwise.
Especially with the tiny confusing non-differences like one using (a-b) and other -(b-a)
Also new one uses matrix template parameter in case someone needs for example a high-precision matrix.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6530 dfc29bdd-3216-0410-991c-e03cc46cb475
No reason to not have several times faster build-times
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6529 dfc29bdd-3216-0410-991c-e03cc46cb475
