Commit Graph

270 Commits

Author SHA1 Message Date
cutealien
66d189ce63 Bugfix: CTriangleSelector::getTriangles with bbox no longer ignores transform matrix
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
2023-12-13 14:14:12 +00:00
cutealien
952f11f806 Fix: CGUITabControl now catching EMIE_LMOUSE_PRESSED_DOWN
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
2023-12-05 13:40:33 +00:00
cutealien
8985248142 Add comment about transparency sorting.
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
2023-11-22 17:15:03 +00:00
cutealien
3752bd9bd4 Add more transparent node sorting algorithms
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
2023-11-22 16:34:55 +00:00
cutealien
3c4ac201ce Add options for transparency node sorting algorithm
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
2023-11-22 14:52:19 +00:00
cutealien
ad4cd6ca7d Grammar
Had missing word in comment

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6571 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-11-13 15:04:40 +00:00
cutealien
8bf9cf5471 writeImageToFile param now used by CImageWriterPNG for compression level
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
2023-11-13 14:53:44 +00:00
cutealien
feaed624f7 Remove serialization again from IUserData
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
2023-11-07 17:43:01 +00:00
cutealien
3c9a856e6d Add SMaterial::IUserData to make it easier passing additional values to shaders
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
2023-11-07 15:43:49 +00:00
cutealien
d4f6d8c17b Add lens shift support for the camera and the perspective projection functions
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
2023-10-19 16:04:43 +00:00
cutealien
567f8688e2 Mention in more places that ECFN_DISABLED disables zwrite as well
Easy to miss... 

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6564 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-10-18 16:51:56 +00:00
cutealien
2b08c37f89 CSoftwareTexture::lock no longer returns image data when a mipmapLevel is requested
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
2023-10-17 17:55:39 +00:00
cutealien
614308e19c Merging r6555 through r6560 from branch releases/1.8 to trunk
- Fixing buffer overflow in tga loader


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6561 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-10-16 20:59:41 +00:00
cutealien
f06347c8b7 Load top-down bmp images correctly
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
2023-10-05 21:04:55 +00:00
cutealien
099f83c023 Fix compiler warning in COBJMeshFileLoader
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
2023-10-03 15:55:45 +00:00
cutealien
857c75f37d Merging r6555 from branch releases/1.8 to trunk
- Fixing buffer ovverread in CXMeshFileLoader (sfan5 patch)


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6556 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-10-03 15:21:39 +00:00
cutealien
b6e9202272 Merging r6551 through r6553 from branch releases/1.8 to trunk
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
2023-10-03 15:08:40 +00:00
cutealien
7fd0f2b1fb COBJMeshFileLoader: Avoid memory leak when handling files with invalid vertex indices
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
2023-10-02 21:49:08 +00:00
cutealien
5a6e8c9d65 Merging r6522 through r6546 from branch releases/1.8 to trunk
- Fixing buffer overflows in bmp and obj loaders
- Fixed loading of rle4 encoded bmp images


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6547 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-10-02 21:42:40 +00:00
cutealien
298623541b Fix number overflows in TGA loader causing crashes
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
2023-09-23 19:01:01 +00:00
cutealien
9f48103263 Fix crash caused by memory overwriting in TGA loader caused by bad RLE data
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
2023-09-23 18:33:46 +00:00
cutealien
74d3a9967f TGA images with palettes in 24 or 32 bit now create 32 bit images
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
2023-09-23 17:08:43 +00:00
cutealien
811a9f3463 Fix TGA's with bad palette colors reading from behind palette memory
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
2023-09-23 16:34:42 +00:00
cutealien
c602a39598 Enable MultiProcessorCompilation in VC17 project file
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
2023-08-17 10:12:28 +00:00
cutealien
bd4ce386a2 Clean-up include dependencies (video namespace)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6528 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-08-15 18:42:05 +00:00
cutealien
ce1cdd2543 Clean-up include dependencies (scene namespace)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6527 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-08-14 22:01:22 +00:00
cutealien
f83697d0bb Clean-up include dependencies
Files in irr namespace
Also some spelling fixes

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6526 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-08-14 20:38:23 +00:00
cutealien
80ce85ecc2 Clean-up include dependencies in gui and io modules
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6525 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-08-13 20:19:25 +00:00
cutealien
1d58677e18 Clean up include dependencies in public headers
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
2023-08-13 15:31:42 +00:00
cutealien
e2a742e2fc Fix compile error with OS X 10.10 SDK, bug #463
Thanks @Ryan Schmidt for report and patch: https://sourceforge.net/p/irrlicht/bugs/463


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6522 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-08-04 15:46:17 +00:00
cutealien
2149bfb317 Merging r6511 through r6520 from branch releases/1.8 to trunk
Note: Due to OSX always failing merge OSX it's rather applying a second patch
from Ryan Schmidt from bugreport #462 to trunk
(Not sure why svn merging always fails for OSX. Probably related to MacOSX files getting moved in the past. Was that done without svn move commands? I guess that can't be fixed anymore now)


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6521 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-08-04 10:22:58 +00:00
cutealien
6f60edbded Merging r6511 through r6515 from branch releases/1.8 to trunk
Note that 6514 couldn't be merged as the xcode project seems to have been rewritten and the irrFramework-Info.plist no longer exists in trunk.


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6516 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-08-03 01:11:01 +00:00
cutealien
7ecaa18949 Merging r6506 through r6510 from branch releases/1.8 to trunk
Note those were mostly backport, so trunk already had most changes.
Also we've not merged all from 1.8 branch, will need another merge (backports tend to cause lots of ugly conflicts, so have to split this a bit)


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6515 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-08-03 00:59:44 +00:00
cutealien
31931b0455 Fix problems in rendering nodes outside SceneManager caused by new render-per-buffer code
Did no longer render nodes which were rendered in SceneManager + outside SceneManager if they didn't have the per-buffer-rendering enabled.

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6491 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-05-09 10:11:49 +00:00
cutealien
79e435d02a Reduce header dependencies in IVideoDriver.h
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6490 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-05-08 16:19:31 +00:00
cutealien
2a04d747d1 Fix: r6469 broke fixed function materials when shader materials where created but not used
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6489 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-05-08 14:15:49 +00:00
cutealien
c57da57edc Remove IMaterialRendererServices::setBasicRenderStates
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
2023-05-05 18:47:22 +00:00
cutealien
c928d1e1a6 Unify newlines
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6484 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-05-05 12:30:28 +00:00
cutealien
c4504c1d48 Add IMeshSceneNode::setNodeRegistration to allow registering MeshSceneNodes to the SceneManager per buffer instead of per node
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
2023-05-04 16:07:18 +00:00
cutealien
1b4912fcc4 Collada loader can now handle 32-bit meshbuffers
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6480 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-04-29 15:12:49 +00:00
cutealien
13619d8fdf Remove unused variable in CGUIContextMenu
y was set in 2 places, but never used for anything.


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6476 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-04-27 19:46:05 +00:00
cutealien
36fc0bc8d2 Spelling fixes
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6475 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-04-27 18:44:33 +00:00
cutealien
80788a4198 More fixes for CCubeSceneNode with multi-material cube
CCubeSceneNode::getMaterialCount now returning correct count
CCubeSceneNode::clone now cloning all materials

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6474 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-04-27 12:58:55 +00:00
cutealien
8b0534d4b7 Fix CCubeSceneNode using correct material per side for multi-material cubes
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6473 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-04-27 12:50:20 +00:00
cutealien
28856e78b6 CCubeSceneNode can now handle new multi-material cube type
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6472 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-04-26 18:52:08 +00:00
cutealien
e55af78b31 No longer move context sub-menu to left if there's even less space there
Probably still moving too often to the left - should find some better solution.
But at least some improvement.

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6471 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-04-25 13:14:52 +00:00
cutealien
37d821dcc3 Add MaterialType in COpenGLSLMaterialRenderer::OnSetMaterial back in
Shouldn't have been removed with last commit.
But adding some comments as it's slightly confusing.

git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6470 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-04-24 16:01:13 +00:00
cutealien
c4bbbe1aaf Add IMaterialRendererServices::startUseProgram/stopUseProgram
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
2023-04-24 14:46:09 +00:00
cutealien
16c960c5ed Add IShaderConstantSetCallBack::OnCreate to allow earlier access to IMaterialRendererServices
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
2023-04-21 14:41:01 +00:00
cutealien
02165eccc8 CD3D9HLSLMaterialRenderer now implementing IMaterialRendererServices itself
Basically now the same as GLSL material renderer already worked.
Before it was using IMaterialRendererServices from CD3D9Driver, but there had been several problems with that:
- The d3d9 driver called functions through the CD3D9MaterialRenderer interface, but CD3D9HLSLMaterialRenderer is not (or maybe no longer?) derived from that class. Reason it still worked was accidental luck - the same functions had been in the same order and due to casts the compiler wasn't noticing it was calling the functions of an unrelated class.
- It was making calls to set shader constants depend on the currently set material in the driver. Which was not necessary and just prevents we can use the IMaterialRendererServices interface without setting the material first (how I found the bug).
Still some problems left for now:
- There's 2 ways to call shader constants. One seems to be only used by hi-level shaders which links constants to the shader. The the other only by low-level shaders which uses global (shader independent) registers.
So maybe this should be 2 interfaces? But not certain, glsl material renderer seems to prevent setting the global registers, but maybe those could be used additionally? I've still allowed it for now in HLSL, just in case it had it's uses.
- setBasicRenderStates probably should not be in IMaterialRendererServices. I'm not seeing any case where this isn't just passed on to the driver. And all classes using it have access to the driver unless I missed one. So probably can just avoid that additional indirection and kick that out of the IMaterialRendererServices interface.


git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6464 dfc29bdd-3216-0410-991c-e03cc46cb475
2023-04-21 14:04:57 +00:00