Sign in to follow this  

OpenGL Animated OpenGL water texture (without GLSL)

Recommended Posts


I am creating a 2D game using openGL and I would like to add some water in it.

I have a very little understanding of OpenGL yet so many questions about it but I will do my best to keep things simple and clear.

So basically I have two textures : the water texture and a perlin noise texture. What I would like to do is to alterate the positions at which OpenGL look into the water texture using values of the perlin noise texture.

so basically something like :

[code]looping trough all pixels to draw on screen for the water quad
texel_coordinate = glMagic();

texel_offsetXY = perlinNoise_texture[pixel_coordinate].redValue(); // Or .intensity().... idk

texel_coordinate.X + texel_offsetXY, texel_coordinate.Y + texel_offsetXY)

// keep looping for all the pixels to draw[/code]

...and all that, without using a shading language (GLSL).

is it possible ?
is it stupid ?
is it extremely computer intensive? (if it is possible of course)
is there a shader technique that is widely supported trough all computer between now and 2000 or does all GLSL are just as bad on the compatibility issue (if you never experience any compatibility issue with GLSL, this question isn't for you).

PS : I don't want to start a debate on what people think of how many computer they know support GLSL. I just want to know if it's possible & viable to draw water with a texel displacement effect without the use of GLSL.

Share this post

Link to post
Share on other sites
You're not going to get an acceptable solution for this that doesn't involve some kind of shader - what you're talking about is a [url=""]dependent texture read[/url] and that needs shaders (or some other kind of per-fragment programmability). The only way I can think of would be to tesselate your geometry really [i]really[/i] heavily (such that one triangle approximately maps to one pixel), keeping the noise texture in system memory, and doing your coord modification per-vertex. That's not going to run well at all - a combination of heavy tesselation and needing to resubmit all the texcoords for it every frame will pull down performance badly.

So, on to shaders.

The main question I'd ask is "are you really certain that you need to run on hardware going back to the year 2000?" That's 12-year old hardware now, and assuming that you can even find any that still works, would somebody who's clinging on to such ancient junk even be considered part of your target audience? On the surface, it has to be said, you seem to be being a great deal over-conservative here, and that's a requirement that I seriously recommend you rethink.

Let's move on and assume that some kind of shader support is acceptable as a baseline requirement.

Here we have a number of options. Something like the old NV register combiners would work if you really want to target older hardware, but they're not going to be so broadly available. ARB assembly programs are another option (moving up a little more) and they will meet your requirement while still maintaining very broad hardware compatibility - even integrated Intels from 6 years back will support them. They are more limited (and more complex to write - although the C interface is simpler) than GLSL however. And that brings us to GLSL itself where the compatibility problem is really not so bad. Shooting for something like the GL 2.1 version of GLSL will give you very good hardware compatibility across the vast majority of hardware you'll find in people's machines today - it's only the really old integrated Intels I mentioned before that won't support it (more recent ones do) so the question changes to one of "do you need to run on ancient integrated Intels?"

Bear in mind here that these Intels were really only ever found in business PCs, laptops, and el-cheapo high-street "multimedia" PCs and it comes back again to you needing to think more about who your target audience are. That's the first thing you need to define before any definitive recommendation on how to go forward can be given.

Share this post

Link to post
Share on other sites
[quote name='mhagain' timestamp='1334019505' post='4929713']you seem to be being a great deal over-conservative[/quote]
I am being over-conservative because of a lack of knowledge on so many levels reguarding this issue.

From what I could find on the web (along with what I could not find) (and along with your helpful reply) i will make the assumption that some shaders has to be used for this feature to be implemented in a intelligent way.

[quote name='mhagain' timestamp='1334019505' post='4929713']ARB assembly programs are another option[/quote]
I have been digging this possibility for a while (with some true interrest) yet found very little ressource on the subject. Many time I've read ARB fragments being called "outdated" and such, which made me wonder if they would even be supported by newer graphic cards (another issue that may not exist but concern me as well)... or maybe they are not supported by the latest versions of OpenGL which seem to remove support for old stuff from time to time (from what I have reed).

[quote name='mhagain' timestamp='1334019505' post='4929713']And that brings us to GLSL itself where the compatibility problem is really not so bad.[/quote]A debate for which I have read good argument on both sides. Without any real statistics on the subject, I would rather take the conservative side unless I dont have the skills for it (which is another possibility). I'm not here to debate on how peoples that would like to play my game can play GLSL games, I have no stats to back me up.

[quote]"do you need to run on ancient integrated Intels?"[/quote]
I have no idea, but as I said, without stats il take the concervative choice. I for myself own a not so old computer (5 years) with an integrated graphic card (intel I guess) that doesn't support GLSL, yet it can play some pretty decent games, go figure.

[quote]who your target audience are[/quote]
People who don't have the money to buy games that will undoubtly be better than mines.

...from there I can only guess some subcategories such as :
- people who can only afford old computers.
- people who spent money on bad games and are now looking for free games (yet own a good computer)

Now that I have read your replie I have a better understanding of my choices.
I will now aim at some ARB fragment shaders (since I believe it might not be too hard) (say the guy who know nothing about anything) since this animated water will most likely be the only and single aspect of my game using shaders (thus worth a little extra effort).

Also, I will take a look into GLSL 2.1. If I'm lucky enough, Nvidia has a software (that is hopefully free) that will allow me to code the shader once and export it to GLSL 2.1 and ARB. From there il let my game probe the computer it is run from and decide from there if GLSL 2.1 shaders are supported or if ARB shaders are supported.

Thanks you very much for your help mhagain !

Share this post

Link to post
Share on other sites
Assembly programs are going to remain supported for quite some time yet - reason why is that Doom 3 used them, so no hardware vendor is going to be too willing to drop Doom 3 support.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
    • Total Posts
  • Similar Content

    • By DelicateTreeFrog
      Hello! As an exercise for delving into modern OpenGL, I'm creating a simple .obj renderer. I want to support things like varying degrees of specularity, geometry opacity, things like that, on a per-material basis. Different materials can also have different textures. Basic .obj necessities. I've done this in old school OpenGL, but modern OpenGL has its own thing going on, and I'd like to conform as closely to the standards as possible so as to keep the program running correctly, and I'm hoping to avoid picking up bad habits this early on.
      Reading around on the OpenGL Wiki, one tip in particular really stands out to me on this page:
      For something like a renderer for .obj files, this sort of thing seems almost ideal, but according to the wiki, it's a bad idea. Interesting to note!
      So, here's what the plan is so far as far as loading goes:
      Set up a type for materials so that materials can be created and destroyed. They will contain things like diffuse color, diffuse texture, geometry opacity, and so on, for each material in the .mtl file. Since .obj files are conveniently split up by material, I can load different groups of vertices/normals/UVs and triangles into different blocks of data for different models. When it comes to the rendering, I get a bit lost. I can either:
      Between drawing triangle groups, call glUseProgram to use a different shader for that particular geometry (so a unique shader just for the material that is shared by this triangle group). or
      Between drawing triangle groups, call glUniform a few times to adjust different parameters within the "master shader", such as specularity, diffuse color, and geometry opacity. In both cases, I still have to call glBindTexture between drawing triangle groups in order to bind the diffuse texture used by the material, so there doesn't seem to be a way around having the CPU do *something* during the rendering process instead of letting the GPU do everything all at once.
      The second option here seems less cluttered, however. There are less shaders to keep up with while one "master shader" handles it all. I don't have to duplicate any code or compile multiple shaders. Arguably, I could always have the shader program for each material be embedded in the material itself, and be auto-generated upon loading the material from the .mtl file. But this still leads to constantly calling glUseProgram, much more than is probably necessary in order to properly render the .obj. There seem to be a number of differing opinions on if it's okay to use hundreds of shaders or if it's best to just use tens of shaders.
      So, ultimately, what is the "right" way to do this? Does using a "master shader" (or a few variants of one) bog down the system compared to using hundreds of shader programs each dedicated to their own corresponding materials? Keeping in mind that the "master shaders" would have to track these additional uniforms and potentially have numerous branches of ifs, it may be possible that the ifs will lead to additional and unnecessary processing. But would that more expensive than constantly calling glUseProgram to switch shaders, or storing the shaders to begin with?
      With all these angles to consider, it's difficult to come to a conclusion. Both possible methods work, and both seem rather convenient for their own reasons, but which is the most performant? Please help this beginner/dummy understand. Thank you!
    • By JJCDeveloper
      I want to make professional java 3d game with server program and database,packet handling for multiplayer and client-server communicating,maps rendering,models,and stuffs Which aspect of java can I learn and where can I learn java Lwjgl OpenGL rendering Like minecraft and world of tanks
    • By AyeRonTarpas
      A friend of mine and I are making a 2D game engine as a learning experience and to hopefully build upon the experience in the long run.

      -What I'm using:
          C++;. Since im learning this language while in college and its one of the popular language to make games with why not.     Visual Studios; Im using a windows so yea.     SDL or GLFW; was thinking about SDL since i do some research on it where it is catching my interest but i hear SDL is a huge package compared to GLFW, so i may do GLFW to start with as learning since i may get overwhelmed with SDL.  
      Knowing what we want in the engine what should our main focus be in terms of learning. File managements, with headers, functions ect. How can i properly manage files with out confusing myself and my friend when sharing code. Alternative to Visual studios: My friend has a mac and cant properly use Vis studios, is there another alternative to it?  
    • By ferreiradaselva
      Both functions are available since 3.0, and I'm currently using `glMapBuffer()`, which works fine.
      But, I was wondering if anyone has experienced advantage in using `glMapBufferRange()`, which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?
      Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.
    • By xhcao
      Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness. 
  • Popular Now