debug ideas needed please

neighborlee · October 1, 2007, 6:08pm

hi there,

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:

heartseed.pastebin.com/f6a269798

i-imagehost.com/uploads/5763804c4f.png

now lee’s :

heartseed.pastebin.com/d6e30e464

heartseed.sourceforge.net/newest.png

We are blending the textures with this shader:

heartseed.svn.sourceforge.net/vi … a?view=log

We appreciate any help in this matter…as you can see MY terrain is rather abysmal atm

cheers
nl

rdb · October 1, 2007, 6:32pm

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.

Azraiyl · October 1, 2007, 9:55pm

Did you compared the images step by step e.g.

o_color=tex1*l_color.r;

o_color=tex1*l_color.r;
o_color+=tex2*l_color.g;

…

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?

Josh_Yelon · October 2, 2007, 3:19am

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.

rdb · October 2, 2007, 6:38am

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.

ynjh_jo · October 2, 2007, 11:11am

what if without :
//Cg profile arbvp1 arbfp1

If you use shader, that limit would be gone, am I wrong ?

that’s 10 textures on a card. I use FX52 as pro-rsoft does.

rdb · October 2, 2007, 3:49pm

Ok, we’ll try that out.

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?

rdb · October 2, 2007, 5:19pm

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.

EDIT BY LEE : picture of what I get:

heartseed.sf.net/images/newest.png

cheers
nl

Josh_Yelon · October 2, 2007, 5:24pm

//Cg profile arbvp1 arbfp1

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 · October 2, 2007, 11:39pm

the code of the screenshot :

from pandac.PandaModules import CardMaker,Shader,Texture,TextureStage,Vec4
import direct.directbase.DirectStart

CM=CardMaker('')
CM.setFrameFullscreenQuad()
card=aspect2d.attachNewNode(CM.generate())

myShader = Shader.load('mtex2.sha')
card.setShader(myShader)

numTex=10
for t in range(numTex):
    tex=loader.loadTexture(str(t+1)+'.jpg')
    tex.setWrapU(Texture.WMClamp)
    tex.setWrapV(Texture.WMClamp)
    scale=numTex-t
    TS=TextureStage('')
    card.setTexture(TS,tex)
#     card.setTexScale(TS,scale*scale*.15+.8)
    card.setShaderInput('texScale'+str(t),Vec4(scale*scale*.15+.8,0,0,0))

run()

//Cg

void vshader( in float4 vtx_position : POSITION,
              in float2 vtx_texcoord0 : TEXCOORD0,
              in uniform float4x4 mat_modelproj,
              out float2 l_texcoord0 : TEXCOORD0,
              out float4 l_position : POSITION)
{
  l_position=mul(mat_modelproj,vtx_position);
  l_texcoord0=vtx_texcoord0;
}
void fshader( in float4 l_position : POSITION,
              in float2 l_texcoord0 : TEXCOORD0,
              uniform float4 k_texScale0,
              uniform float4 k_texScale1,
              uniform float4 k_texScale2,
              uniform float4 k_texScale3,
              uniform float4 k_texScale4,
              uniform float4 k_texScale5,
              uniform float4 k_texScale6,
              uniform float4 k_texScale7,
              uniform float4 k_texScale8,
              uniform float4 k_texScale9,
              uniform sampler2D tex_0 : TEXUNIT0,
              uniform sampler2D tex_1 : TEXUNIT1,
              uniform sampler2D tex_2 : TEXUNIT2,
              uniform sampler2D tex_3 : TEXUNIT3,
              uniform sampler2D tex_4 : TEXUNIT4,
              uniform sampler2D tex_5 : TEXUNIT5,
              uniform sampler2D tex_6 : TEXUNIT6,
              uniform sampler2D tex_7 : TEXUNIT7,
              uniform sampler2D tex_8 : TEXUNIT8,
              uniform sampler2D tex_9 : TEXUNIT9,
              out float4 o_color : COLOR )
{
  o_color=
     tex2D(tex_0,l_texcoord0*k_texScale0.x) *
     tex2D(tex_1,l_texcoord0*k_texScale1.x) *
     tex2D(tex_2,l_texcoord0*k_texScale2.x) *
     tex2D(tex_3,l_texcoord0*k_texScale3.x) *
     tex2D(tex_4,l_texcoord0*k_texScale4.x) *
     tex2D(tex_5,l_texcoord0*k_texScale5.x) *
     tex2D(tex_6,l_texcoord0*k_texScale6.x) *
     tex2D(tex_7,l_texcoord0*k_texScale7.x) *
     tex2D(tex_8,l_texcoord0*k_texScale8.x) *
     tex2D(tex_9,l_texcoord0*k_texScale9.x)
     ;
}

rdb · October 3, 2007, 8:20am

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?

ynjh_jo · October 3, 2007, 9:05am

have you tried using different column name (not “color”) ?

[EDIT] :
I’m not sure abt this :

while you’re using

out float4 l_color : COLOR

the important part is the binding : COLOR0.

Josh_Yelon · October 3, 2007, 3:05pm

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.

treeform · October 3, 2007, 5:39pm

dx10 plz… also dx 9 supports texture prefetch in the vertex shader