From version 1.7 to the current SVN version, the performance has drop quite a bit. My "Olimpus Asteroid" scene drops from 85 FPS to around 60FPS And the scene and code are the same.
Although i haven't hinted the meshes to be stored in hardware (which i think it is the default behavior), i think it is a meaningful drop, to be only bugfixes. Am i missing something, or should i do something else in order to recover the old framerate?
Besides, i have found also that when you scale an octTree, the culling gets messed. Restoring the original scale makes things work correctly again, though, but i think it is something desirable that things work correctly independiently from the scale.
Noticeable performance drop-Mipmapping disabled?[solved]
Noticeable performance drop-Mipmapping disabled?[solved]
Last edited by Mel on Sat Apr 17, 2010 12:09 am, edited 3 times in total.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
-
shadowslair
- Posts: 758
- Joined: Mon Mar 31, 2008 3:32 pm
- Location: Bulgaria
I had similar problem when switching from 1.5.1 to 1.6. It turned to be my character`s model (.X format) exported from 3dsMax via Panda, causing 50 frames slowdown. When I exported it using different exporter and/or different model format problem was gone.
IMO, the information you give is insufficient to resolve the problem.
IMO, the information you give is insufficient to resolve the problem.
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
Hm, I fixed recently a problem with octree culling in the 1.7 svn branch (see http://irrlicht.svn.sourceforge.net/vie ... 54&r2=3257). I fixed a problem when the combination of frustum checks + parent checks was enabled (which should also be really fast now).
I rewrote parts of the octree for that, maybe there are side-effects which I can't reproduce here. In my profiling tests speed did not drop - but maybe you can do some experiments with adding/removing that patch and comparing. Otherwise I would need some scene to reproduce the problem.
I rewrote parts of the octree for that, maybe there are side-effects which I can't reproduce here. In my profiling tests speed did not drop - but maybe you can do some experiments with adding/removing that patch and comparing. Otherwise I would need some scene to reproduce the problem.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
I wasn't using octtrees. It was raw fixed pipeline rendering.
@Shadowslair: It is insuficient, indeed, but starting from similar conditions, the expected results should be, in average, quite close. In any case, i really can't point to any particular reason. But a performance drop of nearly the 30% is something to keep in mind, i think.
And the octtrees issue is totally unrelated, i am not pointing at it at all as the source of the performance drop. The octTrees work pretty well, in fact, they help to improve the performance of my test. The only drawback i see at them ATM is that you can't scale them.
@Shadowslair: It is insuficient, indeed, but starting from similar conditions, the expected results should be, in average, quite close. In any case, i really can't point to any particular reason. But a performance drop of nearly the 30% is something to keep in mind, i think.
And the octtrees issue is totally unrelated, i am not pointing at it at all as the source of the performance drop. The octTrees work pretty well, in fact, they help to improve the performance of my test. The only drawback i see at them ATM is that you can't scale them.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Just a question - with current svn you mean trunk or current 1.7 branch svn?
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
OK, thanks. I had a similar feeling when I switched a project this morning from the 1.7 branch to trunk. But had made no measurements, so not sure. I hope I find some time to compare the versions.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Also, i have noticed something else, and this may have to do with the performance loss.
It is that using the DX9 driver, the mipmapping gets disabled. I also noticed it seems to be a Code::Blocks issue, because with Visual Studio 2008, the engine compiles normally.
To reproduce the "potential" bug i've seen:
Compile the "Demo.exe" and compile the engine with these settings:
-s -O2 -OS -fexpensive-optimizations
all in code::blocks to reduce size, and increase speed. They never worked wrong.
And then, run it, everything seems to go well, but watchig the walls, they appear to have no mipmapping at all.
See these screens.
Compiled with Visual Studio Express 2008, Without any change to the compilation settings. The mipmapping can be seen working in the far walls.
Compiled with Code::Blocks 8.02. With the mentioned settings. no mipmapping at all.
Im OpenGL, on the other hand, everything works exactly the same.
It is that using the DX9 driver, the mipmapping gets disabled. I also noticed it seems to be a Code::Blocks issue, because with Visual Studio 2008, the engine compiles normally.
To reproduce the "potential" bug i've seen:
Compile the "Demo.exe" and compile the engine with these settings:
-s -O2 -OS -fexpensive-optimizations
all in code::blocks to reduce size, and increase speed. They never worked wrong.
And then, run it, everything seems to go well, but watchig the walls, they appear to have no mipmapping at all.
See these screens.
Compiled with Visual Studio Express 2008, Without any change to the compilation settings. The mipmapping can be seen working in the far walls.
Compiled with Code::Blocks 8.02. With the mentioned settings. no mipmapping at all.
Im OpenGL, on the other hand, everything works exactly the same.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
I switched today again between trunk and 1.7 in my day-project and while I still haven't profiled it - the difference was very real (using VS+DX9). So I just did a quick check with examples and so far it looks to me like directx9 got slower in windowed mode. Demo in trunk is around half the speed compared to the demo in 1.7. Fullscreen and with OpenGL everything seems to be fine (didn't test that yet in my day-project).
If I find time I will try to profile it, but not today. Anyone having further hints (or disagreeing that fullscreen or with GL everything is fine) will certainly help, maybe someone has a little more time and can run a few tests and see if he/she can figure out more.
If I find time I will try to profile it, but not today. Anyone having further hints (or disagreeing that fullscreen or with GL everything is fine) will certainly help, maybe someone has a little more time and can run a few tests and see if he/she can figure out more.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Seriously?CuteAlien wrote:... if he/she can ...
Sorry for OT, I just had to say that.
irrRenderer 1.0
Height2Normal v. 2.1 - convert height maps to normal maps
Step back! I have a void pointer, and I'm not afraid to use it!
Height2Normal v. 2.1 - convert height maps to normal maps
Step back! I have a void pointer, and I'm not afraid to use it!
Definately, i think it is a trouble with the mipmap filter not linking properly. I read the source briefly, and saw comments about that there was a problem when the DX8 and the DX9 drivers were compiled together, resulting in a link error with the mipmap filter of the DX libraries, and so, there was a workaround for it.
If the mipmapping is not available, the render becomes slow because all the time the render must be done with the highest texture resolution. That is fine when the rendered polygon is close to the viewer. But the far ones require memory reads of the texture that are not close enough, and that results in cache faults in the driver, requiring to access the texture almost for every pixel that is rendered far from the camera.
I still want to check one thing, and it is to disable mipmapping in OpenGL, if the performance loss is similar, then, the problem is pretty much the mipmapping not generated correctly.
If the mipmapping is not available, the render becomes slow because all the time the render must be done with the highest texture resolution. That is fine when the rendered polygon is close to the viewer. But the far ones require memory reads of the texture that are not close enough, and that results in cache faults in the driver, requiring to access the texture almost for every pixel that is rendered far from the camera.
I still want to check one thing, and it is to disable mipmapping in OpenGL, if the performance loss is similar, then, the problem is pretty much the mipmapping not generated correctly.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Please check-out newest version and try again. The new material-flag for mipmaps in d3d8 and d3d9 had accidentally switched mipmaping off when it was set to true instead of other way round. It's changed now in svn trunk.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Ah! great, let's check.
The test i ran disabling mipmapping under OpenGL resulted in a similar performance loss. So, it is highly probable it is the source of the low frame-rate
EDIT:
Indeed, now things work like always. Great job!
The test i ran disabling mipmapping under OpenGL resulted in a similar performance loss. So, it is highly probable it is the source of the low frame-rate
EDIT:
Indeed, now things work like always. Great job!
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt