Jump to content

  • Log In with Google      Sign In   
  • Create Account

Efficent semi-procedual terrain in GLSL?


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
No replies to this topic

#1 PAndersson   Members   -  Reputation: 394

Like
0Likes
Like

Posted 19 October 2012 - 11:52 AM

I'm curious about how one would best go about procedually generating terrain in a GLSL fragment shader. I'm not intrested in generating the vertices, as that is a solved problem for me. Actually generating the terrain is not very hard, but I'm unsure how I would best go about it when it comes to efficency. The terrain fragment shader will be fairly heavily used, and large inefficencies may lead to below acceptable performance (something I have encountered while playing around with it before, though in a less serious manner), I must admit that I have not measured how it would be in this instance, but I also ask becouse I want to understand how to best work on a GPU.

The terrain in the project needs to be changeable at runtime and in some cases guided by human design, I think it would be for the best to send a texture containing information about terrain types but not how it actually looks as that is what I want to generate procedually.
Presuming I associate a single terrain type with a unique value, how would I best go about actually using it?
Should I calculate the color for each terrain type, and the multiply it by either 0 or 1 depending on whether I want to use it or not and then simply adding them all together in the end resulting in only one color being used. If so, should I use branching statements to select the 'multiplication'
value or should I use some bitmanipulation or other method?
Or would the more straightforward if, else if, else if, ..... , else construct be roughly equal?

A given draw-call is unlikely to use more than half the availible terrain types, does that change anything?

Another option would be to create a new texture for each terrain type (where each pixel is effectivly a boolean, use or do not use) and do a new draw call for each of them with thier own shader program, this would mean terrain type selection would effecivly be handled by the CPU but that may not be efficient as the textures need to be quite large. For that reason, it would be difficult to cache these between draw calls as well.

Sponsor:



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