You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
I tired the new 1.4.1 .dmg file in hopes that it would solve our Mac platform issues, but no luck =(.
Download .dmg from the website, unpack, double click on the Demo app. Result is shown below:
Also, the readme in the MacOS bin directory says that "this SDK has not been tested on MacOS X" and tells me to "download one specifically for Mac OS X from http://irrlicht.sourceforge.net/ . Is this just a broken readme, or is there really no testing on Mac OS X? Is there actually a difference in source code between the two releases? One of the main reasons Irrlicht is attractive is the promise of true cross-platform-ness...
Model Name: iMac
Model Identifier: iMac5,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.16 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 2 GB
Bus Speed: 667 MHz
It seem that texture are not rendered on certain types of mesh. Of the last picture, the .bsp map is rendered correctly, but the fairies doesnt seem to be textured.
Can you check other demo (if you can test the one with the dwarf) is the dwarf rendered properly? (Dwarf is a .B3D format, and I think the fairies are in .X (Microsoft DirectX format)
For the first picture, I don't even know what it is!
Just a guess, but you might want to try dragging the app to your desktop before running it; .app bundles can't write files to mounted .dmg files, but they can write them to your hard-drive; actually, reading files directly from a mounted .dmg file might be funky as well, although I don't know why it would be :\
-wyrmmage
wyrmmage wrote:Just a guess, but you might want to try dragging the app to your desktop before running it; .app bundles can't write files to mounted .dmg files, but they can write them to your hard-drive; actually, reading files directly from a mounted .dmg file might be funky as well, although I don't know why it would be :\
-wyrmmage
This is after I unpacked the image to my hard drive.
We are currently using the OpenGL profiler to look into this problem in our app, and it seems that some drivers work while others don't. This has been a very annoying problem for us, hopefully we can figure it out.
This looks like a render-state bug with the spheremap matrix not being reset. Debugging this could be tricky, try adding some different objects and seeing if drawing an EMT_SOLID material after the spheremap reflection fixes it. If so, it's either an issue with the spheremap reflection material or the lightmap material.
utNero wrote:This is what I see when running Collision.app
This looks like a problem with the separate specular extension, I've seen something similar in Windows but can't remember the conditions that cause it to happen.
Try undefining the GL_EXT_separate_specular_color macro or commenting out the separate specular calls in COpenGLDriver.cpp
HAHA!!! I've spent a lot of time on this and I think I know what the problem is. I've been running the 'demo' example application via OpenGL profiler on OSX. It gives you the ability to pick what driver you want the application to use. I went through EVERY driver available in OpenGL profiler and ALL of them work correctly. It was only the native one with the problem. I'm running into the same problem as utnero and I'm running under the same hardware. This problem doesn't exist on a macbook, which has a different video card.
With all that said...and after a lot of hunting....I think the problem has to do with GL_ARB_texture_non_power_of_two. This seems to be a bug in the driver. The value returned when you look this property up is 'true', which is causing all the problems.
If you change COpenGLExtensionHandler::queryFeature() to return false on EVDF_TEXTURE_NPOT, then everything works correctly. The demo application and the collision application both render correctly after I make this change.
I'm not sure if the OSX version also contains the wrong NPOT recognition. In that case you could easily change the check for NPOT support to only check the extensio string, instead of relying on NPOT support on all OpenGL 2.x drivers.
Otherwise we'd have to create a workaround for some OSX systems...
I think the problem is that the driver is reporting the wrong thing, or not supporting the extension it is reporting. We get GL_ARB_texture_non_power_of_two when in fact the driver does not support non_power_of_two sized textures.