News | Forum | People | FAQ | Links | Search | Register | Log in
Screenshots & Betas
This is the place to post screenshots of your upcoming masterpiece and get criticism, or just have people implore you to finish it. You should also use this thread to post beta versions of your maps.

Need a place to host your screenshots? Upload them here:
http://www.quaketastic.com/
Username: quaketastic
Password: ZigguratVertigoBlewTronynsSocksOff
File size limit is 128MB.
First | Previous | Next | Last
 
Yeah, I'm afraid that doesn't work :/ thanks, though. 
Killpixel: 
are you talking about the weird artifacts seen in this screenshot?

http://quakeone.com/~files/water_dm3_9NC.jpg

The reflected image has weird cracks along the waterline? 
Yessir 
 
 
yeah those bug me too. 
More On This 
setting r_water_reflectdistort to 0 will solve the problem (aside from a hairline seam, which is made more obvious by linear texture filtering and AA) but at the cost of no reflection distortion.

I thought about using cubemaps instead of realtime reflections but AFAIK you can only have one cumbemap per level and you can't link specific cubemaps to specific water brushes. You would still need realtime entity reflections too... and light styles. 
Found A Solution 
https://www.youtube.com/watch?v=qgDPSnZPGMA

in this example, by knowing the depth of the water you can find the edges and alphablend the reflection/refraction distortion.

this is similar to my janky map-side solution which is to use water "trim", i.e. water brushes without distortion to run along the edges of geometry. 
 
yeah, the only reliable solution is to compare the depth values from the refraction fbo to the water surface.
if you're trying to do nice sandy beaches, that distance in depth can also be used to determine how much surf to include (which is even better for obscuring any boundary issues).
of course, that gets a bit fancy.

the other option is to just copy the current framebuffer and use that as the refraction image, then any seams are much less obvious, but the refraction can still show parts that are not from the water areas. 
 
the only reliable solution is to compare the depth values from the refraction fbo to the water surface.

interesting. thanks for confirming that. I'll look more into this. I have a question, though:

the other option is to just copy the current framebuffer and use that as the refraction image, then any seams are much less obvious, but the refraction can still show parts that are not from the water areas.

could that be enlarged slightly so as not to reveal any unwanted areas? that might look pretty bad though. Maybe a parallel frame rendered at a slightly higher rez/aspect ratio so the scale and pixel density is the same but you have "extra" image on all sides preventing unwanted reflections. this is probably pretty resource heavy :/ 
 
using the current backbuffer as the refraction image is generally sufficient to hide the glitches that you're referring to thanks to them normally only being a few pixels anyway. the 'new' glitches appear from the viewmodel etc overlapping water, giving a sort of halo. Copying the backbuffer like that is actually more efficient than re-rendering half the scene, so if it wasn't for the viewmodel and opaque water vising this would probably be the preferred option.

another possibility is to try nudging the refraction image up by a few pixels, you might get some boundary clamping at the bottom of the screen (or you could extend the size of the refraction texture offscreen, assuming you're in to engine modifications), but it should help hide the cracks a little better. 
 
if you or someone else wants to use it for quake i'll upload the source files for the tests i've shown. i recommend making your own, though, as you'll probably get better results.
I wouldn't know what to do! If no-one else is up to the task, having the source files would be a first step towards learning the know-how.

setting r_water_reflectdistort to 0 will solve the problem but at the cost of no reflection distortion.
I talked about that with Seven once, his answer was not to set this cvar to 0 but instead to lower both this one and r_water_refractdistort. But...

Found A Solution
If you've really found a way to fix it without modifying the cvars, once you implement it in your game it would be super mega awesome if you'd be so kind as to update DP-water with your fix for all us quakers to enjoy. 
 
@spike - hrm, interesting ideas. it seems using depth values is the most correct way to do it.

@mugwump - here's the source. You'll probably have to tweak the shader for q1, or at least the texture paths. Looks at existing shaders created for q1, like pretty water, to get an idea. Here's the q3 shader manual for reference if you get stuck on something.

update DP-water with your fix for all us quakers to enjoy.

This is on the to-do list, but not the top, so it's a ways out. But, when it's done the source will be publicly available.

Ok, I'm done spamming the fuck outta this thread for a while :P 
Thanks Killpixel 
I'll look into it. 
 
My Egypt Map In A Nutshell 
mfw 
Lol 
Nice 
Update On My Quake Map (WIP) 
Trippy 
Some crazy stuff going on...like the inverted grave stones! 
Surrealism Always Suits Quake Well 
Can't wait to get my hands on your map, Serge. Any ETA? 
Kinda E4-ish 
And some of the background designs look a bit bland in that E4 corridor sort of way. But it still looks well built and some of the ideas look very cool and promising - the floating rune things especially. Keep it going dude. 
Nice To Both Negke And SJ 
 
@mugwump 
It's too early to give you an estimation since because it really depends on how much free time I have and right now it's not all that much :)
I'd say the map is about 30% completed. 
 
 
Two info_player_starts?

BTW, you know you can make albums in imgur, right? You don't have to post one link per screenshot. 
#14440 
If you're using tyrutils-ericw compilers, you should check Surface lights. Might be useful in this case. 
Mukor 
lookin good! 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.