View Full Version : water water water ... :P
06-30-2007, 05:34 PM
Alright, here's my map... On the top, you can see the water is not working and is [color="#FF66FF"]♥[/color][color="#FF66FF"]♥[/color][color="#FF66FF"]♥[/color][color="#FF66FF"]♥[/color][color="#FF66FF"]♥[/color][color="#FF66FF"]♥[/color] framerate. On the bottom (same location, view slightly tilted down) you can see the water actually working...
Any ideas WHY??
06-30-2007, 06:11 PM
do you have cubemaps? maybe it's trying to load the cubemap from another really big map as a default. have you tried using different water materials?
06-30-2007, 06:35 PM
2) Don't think so; I've tried with and without cubemaps; same error.
07-01-2007, 06:02 AM
the water looks like that. it's how it's made. it is textures to use so you can see thru everywhere. maybe i should send you the map with all the water textures?? i made it a couple of weeks ago to test the water textures. if you want to, just send me a personal message.
07-01-2007, 06:24 AM
Maybe it just renders cheap water, because swap buffers is hitting the limit and screwing the performance.
What's the scale of the water texture?
Have you tried a higher scale?
Do you use a water_lod_control entity?
Tried other settings with this, which would improve performance (reduced range till cheap water e.g.)?
Maybe it's the texture's settings that cause this problem, tried another water texture?
I have a big water surface in my map (10000x3000 Units), which works perfectly without even stressing swap buffers. It just consists of multiple brushes and water scale is around 4.
07-01-2007, 02:03 PM
How big is your water brush? Ive had problems with water brushes not displaying correctly at all because of their size. Try scaling down your water brush and see if the problem still exists. If not, create multiple waterbrushes with one env_cubemap applied to all water surfaces. For better performance hint brushes might also be an option.
07-01-2007, 09:54 PM
Just curious, what are swap buffers for anyways? My guess would be sending and receiving images for processing per-pixel shaders between ram and video memory... But that can't be possible because it would go too slow.
1. Scale of texture was .7 x .7
2. No; don't think that has any affect
3. Yes; no change
4. Yes; no change
5. Don't think it's a problem with the material nor the video settings... I've tried other water materials and get the same problem.
However, I noticed something very peculiar: I only have this problem in specific vis-leafs.
position / position translated on the -y axis
pitch = 45http://img179.imageshack.us/img179/492/waterwaterwater2jx9.th.jpg (http://img179.imageshack.us/my.php?image=waterwaterwater1px0.jpg)http://img179.imageshack.us/img179/3882/waterwaterwater3di6.th.jpg (http://img179.imageshack.us/my.php?image=waterwaterwater3di6.jpg)
pitch = 25http://img179.imageshack.us/img179/2803/waterwaterwater0ek1.th.jpg (http://img179.imageshack.us/my.php?image=waterwaterwater0ek1.jpg)http://img179.imageshack.us/img179/4834/waterwaterwater1px0.th.jpg (http://img179.imageshack.us/my.php?image=waterwaterwater2jx9.jpg)
I decided to try moving the map 128 units +y (the distance between the split between those specific vis-leafs and the wall). Lo and behold, fixed the problem.
The other problem I found was that no brush or face was splitting the leafs like this. I remember reading somewhere in the developer.valvesoftware.com that vvis.exe will split vis leafs on the x, y, and z axes; and the beige/brown grid lines. Somehow, a beige line was originally splitting the water surface, causing the !@#$ing screw ups.
Here's what the result looks like, similar angles to the previous, different water material (testing, and it didn't have any affect), with a slightly different position (shouldn't have any affect, rather than pitch/yaw angles), and compiled with no lights
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.