Terrain -> water -> clipping

Started by
12 comments, last by Fovster 23 years, 1 month ago
Yo br0nx. I have a little problem with my llama terrain engine. I''ve been implementing water for some time now, and got a hard time figuring how to fix some clipping problems i have with it. So at initialization time my little engine creates a kind of a ''grid'' or ''layer'' for the water that is drawn on top of the terrain. The water grid is constructed so that it goes a little ''inside'' the land, and this is where i''m having problems. The water grid is just depth tested against the land and clipped, and this is producing some pretty weird results. I''m altering the heights of the points in the water grid according to a sinus wave. Here are two screenshots that might clear things up a little: Textured And wireframe You can probably see the distortion where the water hits the land. So i was wondering if i should check the exact coordinates where each waterpoint meets the land, set them to exactly those coordinates and not alter the height of those points that meet with land. Or would someone have tips how to properly clip the water. I''m pretty new to opengl so it could be i''m just doing everything wrong but.. Hope i''m making even a little bit of sense here. Thanks in advance. ''''2+2=5 for extremely large values of 2.''''
- Fovster
Advertisement
Don''t know how to solve your problem, but I just wanted to say that it looks really cool! :D

newbie2001
Ey thanks!
I''ve been staring at it too much already, can''t see much cool about it :D
- Fovster
The visual distortion you see is from your video card. Along the border where the water intersects with the land, they both have the exact same height value. The depth buffer can''t tell the difference because they''re the same. The only way to kill it would be to not use one big grid for the water that covers the whole map. The best approach would be mathematically intensive, and it would require calulating individual triangle meshes for each body of water. The edge triangles wouldn''t end up on the grid like every thing else is. The triangles that touch land would have to have endpoints at the intersection points of the triangles, but not actually intersect the land.
I may be mistaken and there may be an easier way, but I just wanted to throw my 2 cents.

Feel free to email me.
[email=JValentine_13@hotmail.com]contact[/email]
Okay thanks for the 2 cents

I though about that too, to set the endpoints of the triangles that intersect with land would be pretty exactly where the height of the land is the same as it is with the water. I think I could do that without very large problems, but then i couldn't continuously change the height of the points of the intersecting triangles as there afaik would be too much calculations..

So the endpoints would be static but the heights of other points could still be altered.. Not a bad idea, just hoped there would be a way to do it as i attempted.

And btw, i already have individual mesh(es) for the water, but the endpoints of the mesh are not exactly where the water intersects with the land but rather a little inside the land because there would otherwise be 'holes' in the water as the endpoints raise. So for this also it's probably better to set the endpoints properly and not to change their heights.

2+2=5 for extremely large values of 2.

Edited by - fovster on March 17, 2001 9:08:02 AM
- Fovster
Well, only if you pre-calculate the endpoints. If you determine them dynamically you could alter them too, but your vis-detection should be fast cause thats a lot of calculation. Maybe if you used a timer so that the water waves were updated at X fps
instead of every frame, you could calculated X endpoints and cycle through them instead if glueing them to the land.

Feel free to email me.
[email=JValentine_13@hotmail.com]contact[/email]
Random suggestions:

A simple solution would be to increase the resolution of the depth buffer. If that''s not possible, try rescaling your near & far view range to reduce the granularity of distance->z-buffer mappings...

If neither of those are possible then you''ll have to perform edge clipping

HTH

Jans.

-----------------
Janucybermetaltvgothmogbunny
Lord Karnus:
Yipp, might be a good idea not to alter the height every frame, dunno if it would be good in any case as i can''t make up a fast way to get the heights. A chance would be to store the heights in memory but that would eat pretty much mem too..

Jansic:
Thanks for the tips! These methods sound a little advanced for me, which on the other hand is only a good thing as learning new is always fun (even tho could be frustrating at times). I might be a little megalomaniac as this is my first project with OpenGL AND C++.. you wouldn''t want to see my code
Still i''m pretty satisfied with the results, and am planning to rewrite the stuff properly using OOP.. currently it''s just C/C++ hybrid without much object orientation. I know the basic OOP principles since i''ve been developing java for a few years but got to learn to adapt it to C++. I''ll look into these methods you described.



''''2+2=5 for extremely large values of 2.''''
- Fovster
what u see there is due to lack of depth buffer resolution
solution
-push the z near plane out as far as posible glPerspective( .,..,near(MAKE bigger),.. )
-use a 24bit depth buffer

http://members.xoom.com/myBollux
Hey, your landscape thing looks really cool, are you going to release the source? Also, zedzeek and Jansic''s way is far easier than the other stuff you are talking about. A really simple way that might work if you dont want to do anything about the z-buffer or glperspective is to just scale everything up and enable GL_NORMALIZE.

This topic is closed to new replies.

Advertisement