Problemos with dem normal maps.
- Thread starter mr.master
- Start date
Users who are viewing this thread
mr.master said:
Aha. Me too.
Although Crazybump, which is also using OpenGL to display even parallax mapping and direct occlusion...
It renders them perfectly speedy on my laptop's hardware.
* Yamabusi's model.
Can't you make it to use two shaders? A simpler/cheap one for non-OGL2.0 mode.
For example. NeHe example tutorials one works fine for me. And looks like it don't need all those API extensions by using a dot? shader.
And yeah, I know, 3d programming retard over here.
Sigh, again. Sorry. Maybe report the graphic card, lets' see if there's a pattern. Same with green and blue maps? With native and new objects alike?
The new brf uses like 4 more shaders than the last version one: one additional bumbmaps shader (for green ones) for each old bumpmap shader. Plenty of rooms for possible errors.
As for OpenGL2.0, the confusion is my fault. I should not have labelled that option "use 2.0 or not". It uses 2.0, but that's not the point. The point is that I cannot even use two textures (bump and color) or anything like that without using opengl extensions, and extensions have to be enabled via glew, and glew makes a few machines out there just crash because it is a twisted, horrible, badly maintained, ugly-stepchild monster of the of graphic card drivers and APIs family. So it is not a matter of OpenGL 2.0, it is a matter of extensions. There is no way I can make a bumpmap shader without extensions, and I found no way currently I can use OpenGL extensions without making a few computer here and there crash. Hence the mislabelled "openGL 2.0" option.
Hopefully, soon QT library will embed these mechanism and when it will make sure my calls are executed correctly on any card (or that at least there is some reliable diagnostics and smooth fallback solutions if not). At that point, probably we will stop having problems.
The new brf uses like 4 more shaders than the last version one: one additional bumbmaps shader (for green ones) for each old bumpmap shader. Plenty of rooms for possible errors.
As for OpenGL2.0, the confusion is my fault. I should not have labelled that option "use 2.0 or not". It uses 2.0, but that's not the point. The point is that I cannot even use two textures (bump and color) or anything like that without using opengl extensions, and extensions have to be enabled via glew, and glew makes a few machines out there just crash because it is a twisted, horrible, badly maintained, ugly-stepchild monster of the of graphic card drivers and APIs family. So it is not a matter of OpenGL 2.0, it is a matter of extensions. There is no way I can make a bumpmap shader without extensions, and I found no way currently I can use OpenGL extensions without making a few computer here and there crash. Hence the mislabelled "openGL 2.0" option.
Hopefully, soon QT library will embed these mechanism and when it will make sure my calls are executed correctly on any card (or that at least there is some reliable diagnostics and smooth fallback solutions if not). At that point, probably we will stop having problems.
1. I see black, but it's the specular map.
2. If I disable that, I get blue-purple, but it's not using the uv coordinates correctly, or something, and looks pretty funky.
3. If I disable that, I get the diffuse with lighting.
On the issues getting it to work via Glew, just a couple of things:
1. Here's an example walking through Glew to utilize GLSL.
2. You can, at runtime, attempt to compile GLSL or query the drivers about the required extensions, or both. If the GLSL fails to compile, you can fall back and have it spit out a log of the compilation errors (and I can debug GLSL for ATi, if you need some assistance- I have a fair amount of experience dealing with that hassle).
2. If I disable that, I get blue-purple, but it's not using the uv coordinates correctly, or something, and looks pretty funky.
3. If I disable that, I get the diffuse with lighting.
On the issues getting it to work via Glew, just a couple of things:
1. Here's an example walking through Glew to utilize GLSL.
2. You can, at runtime, attempt to compile GLSL or query the drivers about the required extensions, or both. If the GLSL fails to compile, you can fall back and have it spit out a log of the compilation errors (and I can debug GLSL for ATi, if you need some assistance- I have a fair amount of experience dealing with that hassle).
Yoshiboy
Count
Hmm, I used GLee with the last OpenGL application I did. I have to admit it didn't work much better than Glew so perhaps it is worth trying, but I don't know if it can be considered a fix-all. The problem might well be with old graphics cards or graphics cards where finding the function pointer is non-conventional.
Can I have the name of a model of native where the problem arises?
Or, failing that, be sent a model (including textures).
I'll try to test it on different computer, when I'll have time.
It could well be something stupid I did, some small error that some card forgives, some doesn't.
If I replicate the bug, maybe I can fix it easily.
Or, failing that, be sent a model (including textures).
I'll try to test it on different computer, when I'll have time.
It could well be something stupid I did, some small error that some card forgives, some doesn't.
If I replicate the bug, maybe I can fix it easily.
MYSTERY SOLVED...
DXT1 => BLUE-NORMALMAPS
DXT3 => GREEN-NORMALMAPS
DXT5 => GREEN-NORMALMAPS
Save your BLUE normalmaps in DXT1, your GREEN ones in DXT3 or DXT5.
That way OpenBRF will understand which type of normalmap is which, and the game will increase performance.
(DXT3 and DXT5 waste half of the space they occupy in alpha channel, which is just not used at all by the blue normalmaps).
(background: that's the two kinds of normalmaps used by M&B/WB: "blue" and "green".
Blue = normal's XYZ stored in RGB. Green: normal's XY stored in Green and Alpha, normal's Z implicit.
Blue = cheaper in memory, disk, rendering time. Green = more accurate.
Blue = looks bluish. Green = looks greenish. [when textures is inspected as color images].
OpenBRF distinguishes between the two kinds by looking at the way they are compressed: DXT1, 3 or 5.)
Can those who had problems confirm that this solved it?
DXT1 => BLUE-NORMALMAPS
DXT3 => GREEN-NORMALMAPS
DXT5 => GREEN-NORMALMAPS
Save your BLUE normalmaps in DXT1, your GREEN ones in DXT3 or DXT5.
That way OpenBRF will understand which type of normalmap is which, and the game will increase performance.
(DXT3 and DXT5 waste half of the space they occupy in alpha channel, which is just not used at all by the blue normalmaps).
(background: that's the two kinds of normalmaps used by M&B/WB: "blue" and "green".
Blue = normal's XYZ stored in RGB. Green: normal's XY stored in Green and Alpha, normal's Z implicit.
Blue = cheaper in memory, disk, rendering time. Green = more accurate.
Blue = looks bluish. Green = looks greenish. [when textures is inspected as color images].
OpenBRF distinguishes between the two kinds by looking at the way they are compressed: DXT1, 3 or 5.)
Can those who had problems confirm that this solved it?
Barf
Sergeant Knight at Arms
I still have the problem, but while messing around I found out that if I remove the reference to the specular texture in the material
the normal map works but not vice-versa, (the specular map doesn't work even if I remove the normal map).
An example of this is "coat_of_plates_a" in "armors_d"
The horses in horse_a.brf work nicely but neither have specular, infact all the horses except the ones with speculars work fine for me.
OpenBRF 0.0.63 and ATI hd6850
the normal map works but not vice-versa, (the specular map doesn't work even if I remove the normal map).
An example of this is "coat_of_plates_a" in "armors_d"
The horses in horse_a.brf work nicely but neither have specular, infact all the horses except the ones with speculars work fine for me.
OpenBRF 0.0.63 and ATI hd6850
I'm really sorry for saying that, but, not for me.
I'm thinking that GLew doesn't fallbacks correctly on some GPUs, so the instructions gets messed up. It can be really simple.
And there aren't any drawbacks. It can only be the same or, hopefully, better result.
It's worth a try. At least only for my cumbersomeness. And this happy face.
I'm thinking that GLew doesn't fallbacks correctly on some GPUs, so the instructions gets messed up. It can be really simple.
And there aren't any drawbacks. It can only be the same or, hopefully, better result.
It's worth a try. At least only for my cumbersomeness. And this happy face.
hey
ok i think i have very similar problem as most of you
today have tryed new version 0.0.64 on work laptop with nvidia 140m video card from beginning for some reason openbrf didint worked at all
but after ~30 min it started work and all was ok (and i really liked new features )
after i back from work i have tryed to get new brf in mine home laptop to with ATI Mobility radeon HD 5730 video card
results was something very strange (looks like normal and spectacular maps do not really work as it must, the do not even react in light
and here is some pictures
by the way if the spectacular map (also with normal map same isue) use dxt5 and spect map is selected mesh dont shows up at all
ok i think i have very similar problem as most of you
today have tryed new version 0.0.64 on work laptop with nvidia 140m video card from beginning for some reason openbrf didint worked at all
but after ~30 min it started work and all was ok (and i really liked new features
)after i back from work i have tryed to get new brf in mine home laptop to with ATI Mobility radeon HD 5730 video card
results was something very strange (looks like normal and spectacular maps do not really work as it must, the do not even react in light
and here is some pictures
by the way if the spectacular map (also with normal map same isue) use dxt5 and spect map is selected mesh dont shows up at all
