Stuff needed for terrain and good looking water

stumbled on some barriers when implementing some terrain and water stuff…

  1. TextureRenderer works pretty well in rendering the needed reflection and refraction textures. But now I need a way to get the depth texture. Looks like I would have to modify the lwjgltexturerenderer to have a setting  for making glcopytexture with the depth identifier set…anyone know of another way?

  2. I've done an implementation of the geomipmap algorithm. I dont want to set all vertices + indices into a buffer and then render it, I want to build and render every patch during rendering(the way i'm doing it now). I have extended Geometry instead of TriMesh to get around the whole index buffer. the problem is that i want to make use of the renderers predraw and postdraw methods(that sets up matrices and other things). any good way of incorporating new types of leaf-nodes into jME that doesnt fit into the TriMesh type?

  3. i would like to add a post bloom effect, and therefore the full framebuffer on final rendering to a texture. is the best way really to put the full kaboom under a TextureRenderer or is there a cleaner way to dump the framebuffer to a texture?

    I know how to do all this in hardcore opengl, but i want my code to be as jme-friendly as possible…

Have you looked at MonkeyWorld3D? They just released a new version today and from the screenshots (haven't been able to try it out yet) it looks like they have decent water support.


  1. So you want to grab the depth buffer as a texture?  We could set that as a flag in TR.

  2. Hmm, we could do a draw(Geometry) could we not?  Trimesh should still hit the draw(Trimesh) method, etc.

  3. If you want RTT you'd need to use TextureRenderer…  If you are ok with copy texture, we could work out some shared code with TextureRenderer.

all those things sounds great renanse!

i’ve tried to modify the texturerenderer to dump the depth texture through pbuffers but cant get it to work…do i need to create a special type of rendertexture?

about point nr 3, RTT is really preferred…

some first beta shots…(still need that depthbuffer to get waterdepth dependant effects)

reflections and speculars:

under water:


forgive my unqualified comment: already looks great!!  :slight_smile:

thanks irrisor!

just remembered, another needed thing is cubemaps, loading and applying…noticed there's a dds loader, but it doesnt support cubemaps yet…cubemaps are nice both for skyspheres and land-sky reflections…

for the texturerenderer it would be nice if the getDepth=true just did the extra extraction of the depth to a texture in the same renderpass as the usual texture (not having to do two renderpasses to get both)

perhaps just an extra

render(Spatial spat, Texture tex, Texture depthTex)

and a


for the texturerenderer

For #3, I'm curious as to how you'd expect RTT to work if you're trying to copy existing color buffer data to a texture?  RTT is rendering items directly to a texture… not copying existing stuff.  Or am I wrong about what you are looking for?  :slight_smile:

Couple points:

  1. Very cool (although the pictures seem to have gone away). I'm quite impressed.
  2. We'll definately look into storing the depth buffer as a texture, although I'm a bit confused how to do that.
  3. We'd absolutely LOVE it you could:

      a) provide your technique as a TestWater type demo we could use in jME

      b) write a wiki article on your technique.
  4. Cube map support is slated for 0.11 currently.

    Keep us updated with screenshots… that's very cool.
  1. looks like that crappy fileserver is down for maintanance. anyone got any tips on better places to share pics and files?
  2. I know that the depth buffer can be fetched just like fetching the regular framebuffer through:

        glBindTexture(GL_TEXTURE_2D, tex);

        glCopyTexSubImage2D(GL_TEXTURE_2D,0,0,0,0,0,width, height);

        glBindTexture(GL_TEXTURE_2D, depthtex);

        glCopyTexImage2D(GL_TEXTURE_2D,0,GL_DEPTH_COMPONENT, 0,0, width,height, 0);

    I figured that the same can be acomplished through pbuffer with the DEPTH-bind option…will get back to you on this.
  3. I will definitely submit everything I'm working on to the jME community. Just have to clean it up and package everything, a GLSLWaterEffect, a GeoMipmapTerrain and so on. (we are also working on a Filmbox loader, with support for multitexturing, animation and so on, plus an animation package, as you know from my mail mojo).

    A TestWater is in the making too offcourse.
  4. Great, maybe I can speed that development up  :slight_smile:

    Will keep you updated (and bog you down with questions)  8)

Try out and let me know what you think, I wrote it. :-p


niiiiice I will definitely give that a try!! (i'm expecting zero bugs ofcourse  :))

i'll pitch in on that cube map stuff I need it too.  Just wondering are would that be dynamic cubemaps,static cubemaps, or both.  Static is easy, dynamic you render the sence 7 times.  Need a pretty good graphics card to get decent fps.  i get good enough on my ti 4800

irt depth->texture: In testing, I've been able to get the TextureRenderer to render the depth buffer only via glCopyTexImage2D as you note above.  It's not a big deal though…  I'll setup things to allow for depth -> texture and should have this in by tomorrow.

Also with you guys implamenting depth textures shadow mapping can probably be implamented


true, shadowmapping uses the depthtexture too…

i was thinking about static cubemaps…dynamic cubemaps are still a bit too next-gen for our games at this point at least…


that's just great, you are just darn fast!  :smiley:

would it hurt to implament dynamic cubemaps?  If your not prepared for the future you'll be left in the dust

you know cubemaps and shadow maps almost give raytracing a run for it's money.  I've seen the same sence rendered twice, one raytraced and the other had dynamic cube maps and shadow mapping.  the 2nd one used more memory(7 textures created per frame but with java and garbage collector that wouldn't be as much as a problem) but looked just as good.  That just leaves indirect lighting and my game has it's graphics engine  foundation laid out.

also about dynamic cubemaps you only have to update the cubemap when something changes.  Even then only dynamic stuff can change.  And still you might only have to update 1 texture in the cubemap.  Dynamic isn’t nextgen my gefore Ti gets 60fps on a dynamic cubemap demo which is the fps limit.

Thats my two cents.  I’ll stop talking about dynamic cubemaps now.

Patrick…  my goodness man.  :)  Relax.  We are always looking to add the next cool feature, and pretty much anyone you ask will say that jME improves and adds features at a very healthy pace.  That said, we still have to crawl, walk and then run if we want our foundation to be solid.

In other words, it may be that when cubemaps are implemented in .11 (yes, you'll have to wait for then…  but .10 is getting closer everyday) they may only be static.  Or we may go nuts and go dynamic as well… you know us.  Even if we do end up with just static maps in .11 though, you can be sure we won't leave it at that as things move forward.