wraitii

Thanks for the reports everybody. I'm going to go through with the afore-mentionned plan, having 5 different levels of details, so that should allow everybody to enjoy the water to its fullest. Fabio: could be related to the FBO used when rendering the shore waves, I'll have to ask you again when the 5 different level of details are done (the latest would only add shore waves).

Output is basically the same for me.

I guess I could make it run over multiple frames for a small overhead cost, in Atlas. Perhaps I could use another function that would basically be the same code updated to run over multiple turns. There are also likely optimizations, it's not the fastest code since it was not really needed in-game, but it probably can't be made much faster unless I realize my math is completely idiotic. Another solution is to only reload when "MT_TerrainChanged" is no longer being sent, ie when the player releases the mouse in Atlas or something. I'll have to check. Anyway, about the water: right now there are three levels -non-shader. A simple filter, using transparency. Extremely ugly, no fog support. -reflections. Shows real reflections and refractions (very slow. On my computer this is about 80/90% of the time to render water), waves, uses "depth at surface". Supports fog. -advanced. Uses the real depth, shows foam and waves, has "interpolated" wave effects that look nicer. Supports fog too. I'm thinking of switching to: -hypothetically, fixed function, like before, for compatibility mainly. -'lowest': simple shader based stuff. Using transparency instead of refraction, reflecting only the skybox (as a texture), perhaps some basic wave effect, fog support. Since that would not render reflections and refractions, it should allow most users to enjoy a water that's not too ugly, and functional -'low' level: this would have realistic reflections (ie the whole thing, not only the skybox), still use transparency instead of refraction, and use fake "surface" depth along with some semi-nice wave effect. -'medium' would add real refraction and real depth (refractions only if it's not too costly, might swap it with foam or something. ) -'High' would be the whole thing, adding shadows on the water, interpolated waves, foam… (perhaps a 'highest' could be considered, I'd have to check). This would have the benefit of allowing most users to enjoy a water that's not too ugly, at a little cost since refractions/reflections is really slow. Also, I think up to 'medium' ARB support would be possible. After that it may require too many different texture sampling for ARB, which is pretty limited in that aspect. @Fabio: ah, I see. Seems pretty weird, the drop should be between no shader at all and fancywater, not between superfancywater and fancywater. Who knows. As for the black areas, report again whenever you can, as long as it doesn't crash I'm going to say it's not highest priority.

I believe it's because it's DLLLoader.cpp that loads it. It explicitly calls a path, which OSX may consider as an absolute path.

I'm mainly asking or the difference between fancy and superfancy. The reflections/refractions are really causing the lag with the water. Do these black areas move? Are they waviness dependent?

Your second point is "probably not much", HWDetect.cpp basically is the place for that and almost already does it, it checks for a few other stuffs. I think the advanced water might also require such changes, BTW.

Hmpf, I'm getting a segfault on cycaldic archipelago and some other errors (not the ones you have though). Should look into that, might be related to Lion's problems. edit: ah, no, that sounds related to some AI changes. Nevermind. Edit 2: Okay, so I'm getting neither, so this is another hardware problem. I am getting some weird stuffs with the foam and the LOS though, should check that. About the waves: it's also an artifact of the way I generate waves. I'm about 30% happy with it... Fabio: the black areas could be a problem with the depth buffer. How does the fog work for your computer? Edit3: could some testers report on performance, too? On my computer, the difference between superfancywater = false and superfancywater = true is basically 0.2 ms, negligible enough. Mainly, I'm considering making the "normal" water also use the depth buffer for depth, it'd give a much nicer result.

Pretty weird... I'll look into that, I've got something to do atm. I've fixed some errors with shadows being off, I'll commit when I get back (see IRC, FeXoR's having a weird issue). Fabio: it happens on all maps?

I guess I could be passing some wrong parameters, but it's probably more likely a good old memory corruption mistake. I'll give a look at the code to see if i can find anything. (I'm fixing some issues with shadows right now, and perhaps some issues with retro-compatibility on some older hardwares.)

Indeed it does. I just committed a fix, I was using some too complicated (and unnecessary) logic for the GUI in the checks.

Small "concern": the trees are not centered correctly, it would appear there is a strip around the bottom left "side" of the map where there are no trees (the image comes from the AI terrain detection I'm working on, you can see the white strip in the bottom left)

Yes, I added a toolbox. Ultimately this should probably be a dropdown box with "lowest, low, medium, high, highest" setting but I haven't implemented such flexibility yet.

If I'm reading this correctly, your issue is caused by the ntdll.dll library... Which is weird. I'm not even sure what that library is. Does anybody else have input on this? (edit: another screenshot. This is addictive as hell.)

Interesting... Seems like you have an intel GMA 950, perhaps it doesn't support some of the stuff I'm doing. Does the post processing work (independently from the water)? If it happens every time, could you try debugging using gdb? I'm afraid the logs don't give enough information. (while this gets sorted out, check these (1,2) out.)

@Historic_Bruno: I might be wrong, but I believe Atlas doesn't work either without this change.

you should set fancywater and superfancywater to true, and it ought to work. It's disabled in Atlas though, for performance reasons. (and it requires recompiling)

@Zaggy: frankly, I don't believe there's an easy way. It should be possible, but using a different system than the one I'm currently using, and I'm probably not going to have enough time to do that now. (note that I'm not completely happy with waves. If most people feel they look fake, I'll deactivate them for the time being).

Should be committed... And it's probably a bit too late for "before" screenshots, unless someone else wants to do them. Else I could try recreating an existing screenshot.

From earlier testing, the medium setting is on par or faster than the regular one. The super high quality one is probably slower, but I believe it's acceptable... I could fine tune it and add more settings for customization (enabling waves, foam, realistic depth, shadows independently, mainly) if it's needed.

And of course that's what it was, thanks a lot Myconid. Okay, I'm taking various screenshots because it looks cool and the new post-proc effects are dead awesome, then I'm busy for a while. I think I'll commit tomorrow morning in case there's any problem. Else I can do it in circa 4 hours, but I'll only be here on and off for 5/6 hours. Link to said screenshots (I'm digging the full skyboxes BTW, but the lower bound should be slightly below the horizon. On the "man" image, I had to touch up the horizon because there were black lines). Apart from said slight touch-up of the horizon, it's all in-game screenshots.

Okay, there is a conflict with the post-process manager and the very high quality water shader, which is a bit too bad obviously. I believe it's linked to the depth buffer, Myconid's probably changed something at some point. Should be an 'easy' fix (though not right now, I'm getting a haircut)

I think it's a path issue. I've had the very same issue with the collada lib, and changing the DLLLoader.cpp file (in source/ps) from #if OS_UNIX static CStr prefix = "lib"; #else static CStr prefix = ""; #endif to #if OS_MACOSX static CStr prefix = "@executable_path/lib"; #elif OS_UNIX static CStr prefix = "lib"; #else static CStr prefix = ""; #endif made it load properly. However, the collada library must be put in the same folder as the executable (in the current repo architecture, it should be that way. If it's a packaged app however, the path may need to be changed. As I understand it, Geek, you're trying to compile the project created by update-workspaces, so you should only have to apply the change I just wrote).

I think it's only GLSL at the moment, wether it's activated or not. There were no ARB water shaders before, and I haven't ported those yet. I'll do a series of testing tomorrow, check the code is allright and then commit-IRC if I feel it's allright.

Got this to work again against the latest SVN, no noticeable issues appeared. Should I post a patch to be reviewed or should I commit and then quickfix if by bad luck it does break a few stuffs? (Asking because it's basically mostly art.)

Having translated those before (pre wind-changes and many other stuffs), your code seems allright. You're using the same texCoord (4) for both v_tangent and v_normal in some cases though. Also, if you hit the hard limit of 8 texCoords, you may want to put some things together to use the 4 coordinates (can't recall exactly, but perhaps v_los is only 2 parameters for example, and could be put with v_tex). Dunno if you'll need it, I seem to recall having to do it but that may have been before some optimizations in the code/myconid's work.