Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


Determine 'gradient' of interpolated value in pixel shader?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 comfy chair   Members   -  Reputation: 571

Like
0Likes
Like

Posted 04 October 2012 - 10:35 AM

Hi,

I am working on a terrain shader where I use interpolated terrain weights in the pixel shader to determine the alpha that I draw the corresponding terrain texture with.

Now I would like to apply some noise to the line where one terrain type (like sand) blends into another type (like dirt).
However, I do not want noise where the two terrain types are blended together over large areas.

Is there a way in HLSL that I can see not just the interpolated value of the terrain weight, but also its degree of change? That would allow me to see where there is a sharp line between two terrain types.

If not, is there some other way I can achieve what I want?

Thank you.

Sponsor:

#2 comfy chair   Members   -  Reputation: 571

Like
0Likes
Like

Posted 04 October 2012 - 10:46 AM

Can the dsx and dsy instructions in HLSL be useful, do you think?

"Compute the rate of change in the render target's x-direction"

http://msdn.microsoft.com/en-us/library/windows/desktop/bb219791(v=vs.85).aspx

#3 jefferytitan   Crossbones+   -  Reputation: 2217

Like
0Likes
Like

Posted 04 October 2012 - 01:32 PM

When you say interpolated weights, so you mean like a splat map, or do you mean interpolated programmatically, such as by terrain height? The reason I ask is that I would approach them separately. If it's based on height or similar, you could extract the rate of change from your mesh, such as the normal if it's height-based. If it's a splat map... it's essentially a bitmap so you could make a design-time tool to do whatever you want in a global context.

#4 comfy chair   Members   -  Reputation: 571

Like
0Likes
Like

Posted 04 October 2012 - 02:05 PM

I guess it is a form of splat map. My world is divided into tiles, which each have values (weights) corresponding to the different soil and vegetation types in that tile. For each tile I create a vertex, that I connect into triangles with its neighbours, and the shader uses the interpolated weights to draw the terrain.

I cannot make a design time tool because the terrain is dynamic.

#5 jefferytitan   Crossbones+   -  Reputation: 2217

Like
0Likes
Like

Posted 04 October 2012 - 03:01 PM

I'm not an expert, but I'm pretty sure your vertex shader can attach custom information for your pixel shader to use, e.g. the rate of change between vertices. Is that the scale you'd be looking at, or are you thinking more about the rate of change across many tiles? Once your pixel shader knows the rate of change, use that as a weight for adding perlin or simplex noise to your splat map weights.

#6 comfy chair   Members   -  Reputation: 571

Like
0Likes
Like

Posted 04 October 2012 - 04:03 PM

Yes, I can do it on the CPU as you describe... but having the GPU do the work would really be the best solution for me.

#7 jefferytitan   Crossbones+   -  Reputation: 2217

Like
0Likes
Like

Posted 04 October 2012 - 05:53 PM

I'm not sure any of that has to be done in the CPU. If the scale you're talking about is blending between the corners of one tile, it should be totally doable in the GPU. If you're talking about blending on a larger scale, you're just getting the rate of change and passing a couple more parameters to your shader. But definitely passing custom vertex info to the pixel shader and Perlin noise, that is GPU work. I've done Perlin noise blending of textures before, all in shaders.

#8 comfy chair   Members   -  Reputation: 571

Like
0Likes
Like

Posted 05 October 2012 - 07:37 AM

The CPU would have to execute code that compared terrain weights for all neighboring tiles, for all types of terrain in that tile in order to compute gradients. Then it would fill in extra vertex info and pass it to the shader. All the shader would do would be to scale noise by the gradient that the CPU had already computed for it.

This would mean extra code and optimizations to make sure that the FPS doesn't go down too much.

I'd like a solution where the shader did all the work. and I didn't have to extend the custom vertex structure which is already packed with stuff. But when it comes to shader programming, I only know the basics.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS