Irrlicht 1.4.1 Mac OS X Demo problem

[utNero]

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...

[utNero]

Code: Select all

  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

Code: Select all

  Chipset Model:	ATY,RadeonX1600
  Type:	Display
  Bus:	PCIe
  PCIe Lane Width:	x16
  VRAM (Total):	256 MB
  Vendor:	ATI (0x1002)
  Device ID:	0x71c5
  Revision ID:	0x0000
  ROM Revision:	113-xxxxxx-139
  EFI Driver Version:	01.00.139

[utNero]

This is what I see when running Collision.app

[christianclavet]

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!

[dlangdev]

"For the first picture, I don't even know what it is!"

looks like the tcoords got screwed-up there. they seem to be strecthed as if the x and y where too small.

[wyrmmage]

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

[utNero]

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.

[bitplane]

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.

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

[mmasters]

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.

Any suggestions on how to handle this correctly?

[hybrid]

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...

[utNero]

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.