ProRsoft and I are a bit baffled by our current Heartseed WIP and we could sure use some additional eyes on what our problem might be so here goes: ( we are using ProRSofts ‘pgmm’ code which is a implementation of the Geometrical Mipmapping algorithm )
We load the alpha maps into the vertex color values, one alpha map per channel. we blend the textures using a shader together using the alpha maps, and apply a color map (texture) on top of it. Since we are limited to 4 texturestages, we use 3 stages for the 4 textures, and stuff one texture into the alpha channels of the other 3.
Ok now some pictures to see what is going on:
PRorSofts output of specs & then running game pics:
The problem is indeed very frustrating… If someone has ANY help or suggestion how to fix it, ANY comment is appreciated.
The problem cannot be OS specific. I’ve tested it under the same conditions as lee with the same build, though again, my terrain looks OK, though lee’s looks like hell. We’re very confused, since we have both an Nvidia card, both use OpenGL, with (almost) the same drivers.
Are the rgb values of tex_0 (or tex_1, or text_2) the same and are the a values of tex_1 and tex_2 one?
“o_color=tex1*l_color.r” tex_0.a ist not always 1, because you use it otherwise, is this equation really what you want?
In which range ist l_texcoord0*25.6? Is there a problem with texture clamping (nvidia drivers didn’t implement this correctly long time ago, nowaday you can select this in most drivers AFAIK)?
Fact is that tex4 has the following form (x, x, x, 1) but that must not be true for tex1, tex2 and tex3.
maybe min/max o_color r, g, b and a.
One more question. Why don’t you mix together your 4 alpha maps to only one texture?
I have a theory - one of you has a GeForce, the other has a Radeon. On the Radeon, the Cg is getting compiled into ARB_fragment_program. On the GeForce, the Cg is getting compiled into some nvidia-proprietary language. One of the two compilers contains a bug, the other doesn’t.
I’m about to release 1.4.2, which contains a new config flag: “basic-shaders-only”. This will force it to always compile to ARB_fragment_program. Let’s see what happens.
Thanks both Azraiyl and Josh for your quick responses!
News: we’ve tested it on an nvidia 7400 GO and have the ugly-terrain problem there too.
We don’t, as the debug output tells:
pro-rsoft’s card: GeForce FX 5200/AGP/SSE/3DNOW!
neighborlee’s card: GeForce 7600 GT/PCI/SSE2/3DNOW!
We have almost identical cards.
Though you might have a point, since we have different shader profile things: lee has vp40 fp40 and I have vp30 fp30.
OK, ill download it as soon as you’ve uploaded the deb.
But, wouldnt this limit us other things too? This is a pretty basic shader, but we also have more advanced shaders running in our game…
No. the alpha values of 1,2,3 contain the rgb values for texture 4.
To fix that, we put an ‘o_color.a=1.0;’ at the end.
Should be right. l_texcoord0 is in the range 0.0 - 1.0, and the 25.6 is to have the texture repeated 25.6 times over the terrain.
tex4 consists of (tex1.a,tex2.a,tex3.a). That is indeed not true for tex1, tex2 and tex3.
The images are preprocessed in the python code before running the shader and that python code puts the tex4 in the alpha channel of tex1-tex3.
You mean I have to clamp the values? Shouldn’t be necessary. GPU should saturate them… But it isnt necessary at all, since the values are not larger than 1.0, except at some small spots perhaps.
EDIT: On second thought, you might have a point: lee’s GPU could be normalizing the values since mine saturates them instead? I doubt it, but we can test it.
We’re already doing that. its in l_color.r, .g, ,.b, .a respectively.
Also, remember that it isn’t an ordinary problem. It does appear on my pc, but not on lee’s. While we have the same brand GPU.
I think you’re wrong. If I do setTexture on an object more than 4 times, the texture number 5 doesnt show right. Or am I wrong?
Or, do I need to apply the texture using setShaderInput?
Some more news: we’ve isolated the problem some more: When i do in the fragment shader just this line:
{ o_color=l_color; }
to display only the vertex colors which are used as alpha map.
Well, at lee’s they look wrong, at least different from mine. So the vertex color values are wrong OR they are handled wrong by GPU.
This comment doesn’t do anything any more. At some point I had to reimplement the shader subsystem and this feature got dropped. I recently added the basic-shaders-only config variable instead.
ynjh_jo, you’re da man! And I always were breaking my head about ways to pack all my textures into just 4! Thanks a lot!
Now, we could make a workaround around our original problem and use a detailmap as texture instead of in the vertex colors.
Though, this does not work on very large terrains, and we would still like to know the solution to our problem, since vertex colors are faster than using a texture. Do you have any idea what could be causing it?
I just posted 1.4.2. Try using the basic-shaders-only config flag, and see what happens.
BTW, “basic shaders” means ARB_fragment_program, which is actually quite capable — I think that’s full DX9, which frankly, is as bleeding edge as I like to go right now.