The test which uses it is currently disabled as it has more problems (broken stencil), but this part is fine and probably just changed due to recent opengl fixes.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5774 dfc29bdd-3216-0410-991c-e03cc46cb475
SViewFrustum::recalculateBoundingBox no longer includes camera position in the bounding-box. Only using frustum corners now. Thx @DevSH for bugreport & patch.
CMatrix4::transformPlane was calculating the wrong plane-normal before. It added the matrix translation and also didn't normalize the normal.
planeMatrix tests had been checking for wrong results (did check calculations by hand now, so hopefully I got it right, anyone double-checking it for me would certainly be cool...)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5773 dfc29bdd-3216-0410-991c-e03cc46cb475
Fixes wrong near-plane values with OpenGL (showed too much before).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5772 dfc29bdd-3216-0410-991c-e03cc46cb475
Sorry, forgot some brackets around addition earlier on :-(
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5771 dfc29bdd-3216-0410-991c-e03cc46cb475
It fails, but it failed before (test is outcommented since a long time, will have to check why)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5770 dfc29bdd-3216-0410-991c-e03cc46cb475
Can now have target range of -w to w instead of only 0 to w.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5769 dfc29bdd-3216-0410-991c-e03cc46cb475
Old projection matrices always projected z from 0 to 1. For OpenGL we want a -1 to 1 target instead.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5768 dfc29bdd-3216-0410-991c-e03cc46cb475
Note: It would likely be nicer if it wouldn't switch back to a projection matrix at all but stay with ortho-matrix. But until I get to that - this will at least return the correct flag.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5767 dfc29bdd-3216-0410-991c-e03cc46cb475
SViewFrustum::setFrom now sets the correct near clipping plane when the projection matrix doesn't use a target depth range of 0 to z, but for example -z to z.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5766 dfc29bdd-3216-0410-991c-e03cc46cb475
We also did just read that box and then dropped the info immediately, so it wasn't used anyway. Not sure what that code was about, I hope it was just accidental and not about support for some strange Collada files in the wild.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5759 dfc29bdd-3216-0410-991c-e03cc46cb475
It already worked correct when Z_UP was set (we switched x/z in that case which also flips coordinate system)
But for the default (Y_UP) it had been wrong before (that one is still right-handed in Collada).
We do now convert all z to -z (so z coordinates do change, but it prevents objects from showing up mirrored).
Note: For readLookAtNode I also added code to regard Z_UP, but have no test-case yet.
Note: I have no test-case for readSkewNode, so not sure about that one.
Note: No fix for readBboxNode as I'm going to kick that out next.
I tested with Blender (which has no textures) and Collada (which needs manual adaptions in .dae files as Irrlicht can't read libraries order independent, but that's another problem).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5758 dfc29bdd-3216-0410-991c-e03cc46cb475
isdigit, isspace and isupper had #undef's before them. But our own replacement implementations are in a namespace, so there shouldn't be any conflicts. And if there are compile conflicts they should show that the wrong implementation is used, so we would want to see them.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5728 dfc29bdd-3216-0410-991c-e03cc46cb475
Writing might be slightly slower, but has to write less on disk on the other hand.
So loading the files later on will be faster.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5721 dfc29bdd-3216-0410-991c-e03cc46cb475
Note: Right now our Collada loader can no longer load the files we write correctly as it also has to be fixed.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5709 dfc29bdd-3216-0410-991c-e03cc46cb475
(just making it easier to read to prepare for some other changes).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5703 dfc29bdd-3216-0410-991c-e03cc46cb475
(first one is probably correct once we fix the rest of coordinates to a right-handed system)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5700 dfc29bdd-3216-0410-991c-e03cc46cb475
A workaround for broken Collada importers which insist on specific names.
Seems SketchUp insists on UV's being called "S" "T" or it won't show textures.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5695 dfc29bdd-3216-0410-991c-e03cc46cb475
Reasons are that it's more typical to use utf8 for xml's and that it allows SketchUp (which doesn't support xml's with wide-chars) can import our Colladas now.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5693 dfc29bdd-3216-0410-991c-e03cc46cb475
Default stays as it was - a roots is written when it's not the SceneManager root.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5691 dfc29bdd-3216-0410-991c-e03cc46cb475
This is Patch#319 from Artem Shoobovych (https://sourceforge.net/p/irrlicht/patches/319/)
Untested on my side due to lack of testing system.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5689 dfc29bdd-3216-0410-991c-e03cc46cb475
Just making life a little easier for the hg & git crowd.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5688 dfc29bdd-3216-0410-991c-e03cc46cb475
Reason is that 4 haven't been enough anymore for even pretty common graphic pipelines for a while now.
8 might still not be enough, but let's see first if people are happy with it.
This has some costs for people not needing more textures, as we have fatter Materials now.
- Memory usage increases by 64 bytes per SMaterial.
- Serialization files for the irr-format are now larger.
- Slight speed cost, thought mainly in debug
For people who don't need this and want to avoid some of the costs there is a new variable irr::video::MATERIAL_MAX_TEXTURES_USED which can be set to the maximal number of textures a project will need
before creating any device. This avoids pretty much all speed-costs involved with this change.
Software drivers are not much affected as they use their own texture-limits (2).
I did a few speed-comparison with varying numbers of _IRR_MATERIAL_MAX_TEXTURES_. The numbers displayed are FPS, so higher is better. I had 2 tests - one which forced many material changes and the other used a single material for all nodes. When there are 2 numbers in a result then I got different (generally lower) FPS when forcing material changes. The test used a simple model with 500 polygons and rendered it 4500 times.
OLD means - before working on all changes related to increasing texture-numbers and without changing materials (found a bunch of places to decrease the impact of this change which also sometimes did speed up Irrlicht generally). 1.8 refers to Irrlicht 1.8 with same test. All tests done on Windows/VisualStudio.
Max.textures 4 8 16 64 64 MATERIAL_MAX_TEXTURES_USED=4
GL/debug 50/68 44/58 35/45
GL/release 117 117 117 80/100 117
D3D9/debug 51/56 45/49 37/39
D3D9/release 168 168 152/168 90/87 168
OLD GL/debug 63
OLD GL/release 117
OLD D3D9/debug 44
OLD D3D9/rel 168
1.8 GL/debug 23/29
1.8 GL/release 94/117
1.8 D3D9/debug 59/63
1.8 D3D9/rel 142/152
Take all results with a grain of salt, it probably often is limited by fill-rate and doesn't even notice the texture-number changes (especially in release).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5682 dfc29bdd-3216-0410-991c-e03cc46cb475
I changed that while fixing SMaterial serialization, but bad optimization. Editors needs the info even when it's empty or it can't offer options to user.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5681 dfc29bdd-3216-0410-991c-e03cc46cb475
CD3D9Driver::setTransform limits no longer to MATERIAL_MAX_TEXTURES, but to MaxTextureUnits.
COpenGLCoreFeature::TextureUnit renamed to COpenGLCoreFeature::MaxTextureUnits (same as Direc3D names it and slightly better description)
Limiting used texture numbers with MATERIAL_MAX_TEXTURES_USED is currently not making a big speed difference. But it has a more noticable effect when we increase _IRR_MATERIAL_MAX_TEXTURES_ soon. It allows software which doesn't need more textures to mostly keep old speed.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5678 dfc29bdd-3216-0410-991c-e03cc46cb475
While possibly double-checking the pointer now (which would be slightly slower when it's non-0), it's generally increasing speed of SMaterialLayer as our allocator is still somewhat expensive when the pointer is 0 (which is generally the case). And the cost would increase further when we raise max texture numbers soon.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5676 dfc29bdd-3216-0410-991c-e03cc46cb475
This increases speed slightly (mainly in debug and more so when we increase max-texture-limit soon).
Texture-matrices are only used together with textures in the fixed function pipeline and for shaders the users
have to to pass them anyway on their own.
So the main difference now is that after setMaterial calls with empty texture pointers we no longer get
a changed texture matrix which can be checked with IVideoDriver::getTransform.
I suppose the main reason where we might want to still access that matrix without a textures is when it's abused to pass values for other stuff in shaders (which is still possible).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5674 dfc29bdd-3216-0410-991c-e03cc46cb475
Minor speed improvement, which also will make it less costly to increase max-textures in future.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5673 dfc29bdd-3216-0410-991c-e03cc46cb475
It's a binary representation of the resource file which shouldn't be checked-in as VS can rebuild it.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5671 dfc29bdd-3216-0410-991c-e03cc46cb475
Didn't release old one when switching between between rt's with different sizes.
Also some refactoring to make code easier to read.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5670 dfc29bdd-3216-0410-991c-e03cc46cb475
Those resets got removed in the materialrenderer rewrite in r4979, so sometimes we got wrong states now (stuck to blend or alphatest enabled when switching back to other materials). At least that was the case for alphatest, not so certain about blend which is also set in COpenGLDriver::setBasicRenderStates. That one is likely enabled/disabled more than once right now when setting up some materials (shader materials which have a transparent base material but SMaterial.BlendOperation != EBO_NONE). So better state-handling there could likely allow some speed optimization in the future.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5669 dfc29bdd-3216-0410-991c-e03cc46cb475
I suspect that was just some copy-paste error (some other nodes need this).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5667 dfc29bdd-3216-0410-991c-e03cc46cb475
While IGUIImage doesn't support those well yet, it at least allocates memory and that turns out to be useful sometimes. For example we can now lock() floating point textures and access the data on OpenGL, which wasn't possible before. If this turns out to cause any problems (shouldn't really) we can handle them case-by-case.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5666 dfc29bdd-3216-0410-991c-e03cc46cb475
- mipmapLevel is now the second parameter as it was in Irrlicht 1.8 (but currently not doing anything)
- layer moved to third parameter
- New parameter lockFlags which allows to disabled flipping the texture upside down for RTT's on OpenGL.
Sorry for any inconvenience this change causes, but as I had to break the interface now anyway I decided to make it backward compatible to Irrlicht 1.8. Anyone already using the new "layers" feature in trunk will have to move the layer parameter now. But the last interface change which replaced the mipmaplevel with another variable with very different meaning wasn't a solution.
Mipmap support can also likely be re-introduced. At least I still haven't seen a real reason why it shouldn't be possible to have that anymore.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5663 dfc29bdd-3216-0410-991c-e03cc46cb475
cutealien