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
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
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
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
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
Removing includes which were not needed by headers
Note that if you include those headers directly (instead of including irrlicht.h) you may have to add some new includes now.
Thought I generally tried to avoid removing headers where it leads to too much changes in user-code
Reason was mainly that IntelliSense in VisualStudio 17.7 added a new feature which shows those unused headers :)
Has to be used a bit careful as it doesn't know about defines and other platforms
And I only did clean up public headers so far (will probably do some more later or another time)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6524 dfc29bdd-3216-0410-991c-e03cc46cb475
Turns out we can avoid a square root and a division.
Patch comes even with proof: https://raw.org/proof/quaternion-from-two-vectors
(I also tested it a while and indeed got same results)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6511 dfc29bdd-3216-0410-991c-e03cc46cb475
What Irrlicht calls ShaderConstants is called uniforms by everyone else. So let's mention this at least.
Also reworked setVertexShaderConstant interface had an example for the old interface in the header.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6497 dfc29bdd-3216-0410-991c-e03cc46cb475
Fix: When appending to an empty mesh boundingbox has to be initialized with first position
Adding updateBoundingBox parameter as there is a bit costs involved in updating that and it might not be necessary at that point
Default is still to do it - and with the default parameter it's at least compile compatible to old interface (unless users created their own meshbuffers).
Optimizing the copying of vertices in CDynamicMeshBuffer::append by using memset when possible instead of pushing each vertex (which goes through quite a few virtual functions)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6496 dfc29bdd-3216-0410-991c-e03cc46cb475
Couldn't allocate enough memory before appending several buffers for all of them as first append shrunk the memory again.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6495 dfc29bdd-3216-0410-991c-e03cc46cb475
Doesn't change it's own type - so can still drop data. Or overflow 16-bit buffers (which creates broken models, but no crashes).
But it no longer has a problem adding 16-bit index-buffers to a 32-bit index-buffer for example.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6494 dfc29bdd-3216-0410-991c-e03cc46cb475
Some in CMeshBuffer got disabled in svn r1515 (before Irrlicht 1.7) without comment.
I suspect reason might have been that they are a bit unsafe and it was meant to be reworked.
Maybe was planned to put that into MeshManipulator?
And CDynamicMeshBuffer never had them.
Anyway, it's useful stuff and having functions do nothing doesn't help. So now they do at least basic work.
Meaning - as long as index and vertex types are identical it's possible to attach meshbuffers again.
While totally ignoring things like 16-bit index overflow for now (so could be improved).
It would probably be better if attach functions had info about vertex/index types, but just keeping interface as it is/was for now.
This also fixes Bug #310 reported by Gaz.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6493 dfc29bdd-3216-0410-991c-e03cc46cb475
SMaterialLayers are now identical when both have identity matrices.
Before it didn't consider them identical when one layer had set the identity matrix explicitly and the other didn't.
Generally didn't matter, just caused very rarely some extra state switches in the drivers. And just as rarely had a cheaper comparison. Just seems more correct this way.
operator= no longer releases texture memory which was allocated at one point.
Unless explicitly requested such memory is now always released later in the destructor.
This can avoid quite a few memory allocations/released in the driver. Usually not a noticeable performance difference on most platforms. But it can help avoid memory fragmentation.
We instead use an extra bool now to tell if the texture memory is used. So slight increase in SMaterialLayer and SMaterial size. But I did a quick performance test and this had no negative influence here, while it did improve speed in the case where it switched between material layers using/not using texture matrices a bit.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6488 dfc29bdd-3216-0410-991c-e03cc46cb475
Wasn't ever used by anything and not that well defined anyway.
So they all just passed it on to the drivers. And then sometimes the driver version was called and sometimes the IMaterialRendererServices version. So now everything just calls the driver - all places which need it have access to the driver anyway. Also made the driver version non-virtual for now. If someone actually really needs this for some reason I can add it back as virtual function directly in IVideoDriver. But I doubt it - the interface was hardly accessible until recently and originally only meant for internal stuff.
GLES version still to do, but checked them earlier and they also just do nothing with it.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6486 dfc29bdd-3216-0410-991c-e03cc46cb475
So far SceneManager always sorted Nodes per render stage.
Now we allow sorting per mesh-buffer per render stage by creating a new node for each mesh-buffer.
It's only supported for CMeshSceneNode so far.
This allows to enable better transparency sorting for meshes which have transparent buffers.
Previously those always got rendered in the order in which they got added and ignored mesh-buffer bounding-boxes, but just used the bbox of the full mesh. Now they can use the bbox for each meshbuffer which can sometimes avoid render errors.
Also depending on the scene this can be quite a bit faster because it can help reduce texture changes. We sort solid nodes per texture, but only per node. So nodes with several textures had a texture switch between rendering each meshbuffer. And those are rather expensive in Irrlicht right now (and we support no bindless textures yet...)
Lastly it's now also used to buffer the render-stage. Checking this twice (once in registering the node and once in render) constantly showed up in the profiler. Which was a bit surprising really, but anyway - now it's gone.
I tried to keep it working for all cases we had before (all kind of situations, like when people may want to call render() outside the SceneManager). But not (yet) supporting the case of changing the meshbuffers (adding or removing some) without calling setMesh() again. Reason is that this wasn't well supported before either (node materials never updated). So for now I just assume people will call setMesh() again when they change the mesh.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6483 dfc29bdd-3216-0410-991c-e03cc46cb475
New AbsPosUpdateBehavior which makes updateAbsolutePosition calls behave as if a node had no parent.
Allows for micro optimizations in cases where we have non-moving root node (all scenenodes are always added to the SceneManager which is generally not moved but it's transformation is still multiplied each frame for each node)
As a side-effect this also allows abusing the SceneManager to group objects without affecting transformations.
No real extra cost since I added ESNUA_TRANSFORM_POSITION already.
Thought turns out those matrix transformations are so fast that I also didn't noticed any difference in tests with > 20.000 nodes.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6481 dfc29bdd-3216-0410-991c-e03cc46cb475
This makes it possible to set high-level shader constants (which are attached to shader programs) to be set outside
of OnSetConstants.
IShaderConstantSetCallBack::OnCreate has it set automatically now so it works the same as OnSetConstants.
D3D9 and burnings both work different, so there hadn't been a problem with those.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6469 dfc29bdd-3216-0410-991c-e03cc46cb475
Accessing IMaterialRendererServices outside of OnSetConstants can be useful and Irrlicht made this a bit too hard to access.
Also OnCreate allows actually for nicer code where initialization and update of shader constants are strictly separated (see changed example).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6465 dfc29bdd-3216-0410-991c-e03cc46cb475
We had changed that once before in the other direction in svn r421
Reason back then was "Sleep(0) doesn't allow any lower priority threads to execute"
But Microsoft changed the behaviour of Sleep(0) after Windows XP so that's no longer true.
And the costs of it is pretty high - due to this using a timer with a 15ms resolutions it meant not just giving up the thread but it also always waited for 15ms on Windows.
I also replaced a few sleep calls in examples for that reason with yield() calls.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6459 dfc29bdd-3216-0410-991c-e03cc46cb475
