next »

[dancing_dead]

hats off to you, Joar, for coming up with original and interesting solutions!

lookin' very good

[JLJac]

Thanks 

Ugh, can someone clue me in on the quirks of the CG compiler? Is there a list somewhere? It certainly does not execute the the code linearly in the way that I'd expect, that's for sure!

Example:

Code:

if (light){
  setColor = half4(0, 1, 0, 1);
}else{
  setColor = half4(1, 0, 1, 1);
}

This code makes the lit areas green and the other areas purple, as expected. This though:

Code:

if (light){
  setColor = tex2D(_PalTex, float2(red/30.0, 1.0-((paletteColor + 3)/7.0)));
}else{
  setColor = tex2D(_PalTex, float2(red/30.0, 1.0-(paletteColor/7.0)));
}

doesn't work, it executes the "else" always, never the "if" No other changes!

This:

Code:

 if (light)
   paletteColor += 3;

 setColor = tex2D(_PalTex, float2(red/30.0, 1.0-(paletteColor/7.0)));

works, and according to my logic that is the exact same thing as the one above it. Confused 

I've been told that shaders work more in parallel an less linearly, and I guess this is that, but I just can't wrap my head around how it works. To me it seems to just be random. What's going on?

[eigenbom]

Looking good dude, you're making great progress!

[migrafael]

Need to track this. Amazing looking stuff.

[Ben H]

Code:

if (light){
  setColor = tex2D(_PalTex, float2(red/30.0, 1.0-((paletteColor + 3)/7.0)));
}else{
  setColor = tex2D(_PalTex, float2(red/30.0, 1.0-(paletteColor/7.0)));
}

I'm not sure but calling tex2D on the same tex, with different UV coords, in the same shader, fugged me up once.

[Nilanjan]

@Joar The way you come up with original solutions is f*****ng brilliant!!! You Sir are not a mere mortal 

[Vovosunt]

No, I'm actually not raymarching, as I don't do any step-by-step checking of different depths. Instead the procedure has only two steps:

1. Check the pixel and get its info, which is color info but also depth (already encoded by the level editor).

2. Use the depth to check for where in the grab texture to look for objects that shadow this pixel. The greater the depth, the more up/left we check.

Effect: If you are in front of a wall, there will be a shadow on the wall. The further back the wall is, the further down/right the shadow will appear.

Oh, I misunderstood then.
(But that could still be considered raymarching with one step )

Your pseudo code is super helpful, by reading it I see a lot of things I can optimize in my shader! It's impressive that you manage to keep away from if-statements like that!

My texture looks like this:



So that's the same basic idea, right?

That is pretty much exactly what I tried to illustrate 

Code:

if (light){
  setColor = tex2D(_PalTex, float2(red/30.0, 1.0-((paletteColor + 3)/7.0)));
}else{
  setColor = tex2D(_PalTex, float2(red/30.0, 1.0-(paletteColor/7.0)));
}

That should work... weird
Try mixing uvs instead (should be faster):

Code:

//considering light a float that has been clamped to 0 or 1

float uvY = mix(paletteColor + 3, paletteColor, light);
setColor = tex2D(_PalTex, float2(red/30, 1 - (uvY / 7)));

EDIT: just remembered that mix is a glsl function.
I believe it's called lerp in CG.


BTW guys, why doesn't tigsource have a rainworld emoticon?

[Gimym JIMBERT]

Yep don't do if, use things like lerp, max, min etc ...
For exemple: (pseudocode) setdata = lerp (A,B, 0) is effectively picking A when 0 but pick B if 1.
Also be sure to set up your texture as not wrapping and filter none (bi/tri linear off)

If don't save a branch in shader because parallelism, it execute both code, you basically overwrite the data that's why it does not work for the texture picker.

Do something like
c1 = texpicked1
c2 = texpicked2
color = lerp (c1,c2,light)

or
color = lerp (texpicked1,texpicked2,light) ?

[Zaphos]

Code:

if (light){
  setColor = tex2D(_PalTex, float2(red/30.0, 1.0-((paletteColor + 3)/7.0)));
}else{
  setColor = tex2D(_PalTex, float2(red/30.0, 1.0-(paletteColor/7.0)));
}

lerp/mix are good to know but for this you could also have just done:

Code:

setColor = tex2D(_PalTex, float2(red/30.0, 1.0-((paletteColor + 3*light)/7.0))); //light is 0 or 1

[JLJac]

Thanks guys! Yeap, those solutions are actually how I solved it! But the reason why I wanted to do it with proper if statements was that I didn't want to check for shadowing objects if I already knew the pixel was in shadow. I didn't want it to run that code unless necessary.

Speaking of which, how expensive is tex2D? I do it quite a lot, heh -

[Gimym JIMBERT]

If don't work like that in shader

[Chromanoid]

http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter34.html might be interesting for you. It's probably outdated, but it gives you a basic understanding of flow control in GPUs.

[Zaphos]

Even on a CPU, "3*light" would be cheaper than an if statement.  Conditional statements can have an extra cost beyond normal instructions, depending on how predictable they are.  CPUs basically have a pipeline where they pre-load instructions and data, and when they see if statements they have to guess which way the if statement will go, and pre-load based on the guess.  If they guess wrong, they throw out that pre-loading work and go back to do the other branch, and this is relatively expensive.  See: http://en.wikipedia.org/wiki/Branch_predictor

(And GPUs are worse at branching than CPUs -- really old ones can't even branch, they just do all the paths and suppress the results of the wrong branches... See Chromanoid's link!)

[RealityShifter]

Even on a CPU, "3*light" would be cheaper than an if statement.  Conditional statements can have an extra cost beyond normal instructions, depending on how predictable they are.  CPUs basically have a pipeline where they pre-load instructions and data, and when they see if statements they have to guess which way the if statement will go, and pre-load based on the guess.  If they guess wrong, they throw out that pre-loading work and go back to do the other branch, and this is relatively expensive.  See: http://en.wikipedia.org/wiki/Branch_predictor

(And GPUs are worse at branching than CPUs -- really old ones can't even branch, they just do all the paths and suppress the results of the wrong branches... See Chromanoid's link!)

This is good to know. O.O

[JLJac]

Super relevant info, guys! What would I even do without you!?

[Gimym JIMBERT]

rain world?

[JLJac]

  probably not, no! I'd still be beating my head against Macromedia Director!

[Slader16]

Just wanted to let you know, in Unity lerp is Mathf.Lerp 

[Gimym JIMBERT]

Just wanted to let you know, in Unity lerp is Mathf.Lerp 

not in shader?

[Slader16]

Just wanted to let you know, in Unity lerp is Mathf.Lerp 

not in shader?

I don't know anything about shaders or if Joar is using Unity's built in methods, but if I was going to use a lerp it would be Mathf.Lerp. An example is moving an objects position: Mathf.Lerp(currentPosition, newPosition, Time.deltatime);. I could be thinking of something different though since what Joar uses relates to shaders.