[Community Project] WIP Weather & Ocean Water Shader

[Thijs Linssen]

Hi guys,
I might have asked this before but want to check again... Is this project suitable and easy to integrate with Truesky?
Thx

[duke22]

I did FFT water on blueprints, both graphics and physics. What is so insane about it ?

Because it's something you want to squeeze every bit of performance out of, so you can't afford the overhead of either blueprint or the blueprint to c++ conversion. It's like writing a server in javascript (and before you chime in, node.js is written in c with a js front end).

[duke22]

Hi guys,
I might have asked this before but want to check again... Is this project suitable and easy to integrate with Truesky?
Thx

I don't see why not, it doesn't do anything out of the ordinary.

[Thijs Linssen]

I don't see why not, it doesn't do anything out of the ordinary.

Yeah good to hear. I'll give it a try! Was/am worried because the title says it's also a weather project it might override or cancel out some of the stuff truesky is doing. But we'll see

[Deathrey]

you can't afford the overhead of either blueprint or the blueprint to c++ conversion.

On reference hardware, there is no measurable game thread performance difference between running 2x32 grids on nativized blueprints and reference C++ implementation.
On reference hardware, there is an average of 0.14 ms GPU time difference and measurable, but insignificant differences on both threads between running 4x256 grids via blueprint render to texture and reference compute shader implementation in favor of the latter one.

No clue how you decided that this overhead is not affordable for it is clearly not the case. Overall, I'm pretty comfy with the mentioned overhead and I don't have any doubts, that a certain deal of engine users would warmly accept trading that cost for an option to stay way from plugins and/or source builds.

[duke22]

On reference hardware, there is no measurable game thread performance difference between running 2x32 grids on nativized blueprints and reference C++ implementation.
On reference hardware, there is an average of 0.14 ms GPU time difference and measurable, but insignificant differences on both threads between running 4x256 grids via blueprint render to texture and reference compute shader implementation in favor of the latter one.

No clue how you decided that this overhead is not affordable for it is clearly not the case. Overall, I'm pretty comfy with the mentioned overhead and I don't have any doubts, that a certain deal of engine users would warmly accept trading that cost for an option to stay way from plugins and/or source builds.

Well that's pretty cool.

[NilsonLima]

hey duke22

I was following the development of this community project in the past and what was really bothering me was not the project itself, but the constant changes into the UE API that required quite constantly each new release to make a lot of changes. A blueprint version in this case gives a little less headache, while I agree the matter about performance, once the blueprint nativization came out, for the assets where it works, it is a bless. Projects like PWS benefit from nativization because buoyancy in plain blueprint really does not perform well, and for me this community project does it right while placing anything about buoyancy inside the C++ code. I don't recall the source correctly, but I remember I have stripped in the past everything but buoyancy, because the other features I was not confortable leaving because thats more code to maintain, I didn't need them and I didn't regreat.. those features thou could be placed in a separate plugin for the sake of portability and isolation: ie: why the code does not works in this new release? Oh it is the fish manager, but oh I dont use it

The quality of this ocean is good enough for most projects and I think anyone wanting to use it, should learn from it, and MUST strip anything he thinks doesn't need to be there to seek performance, mainly the Ultra Ocean which has few things that can be changed. I don't have budget to look at it right now or I would contribute for it, but that might change in the future (soon (TM from someone)).

It is good and I congratulate everyone engaged into this project.

[CrashA51]

To get back to Deathrey's point, and my previous comments .... The advantages of a Blueprint implementation over adding yet another plug-in, with the frequent UE4 version releases, are many. And as Deathrey pointed out, the downside in performance is barely measurable.

I for one, and I think there are many that agree with me, would prefer this, 100% in Blueprints. This is an idea originally presented here by TK, in which he posted screenshots of his progress. Does anyone know the status of TKs Blueprint implementation? A second question, will EPIC allow this to be released on the Marketplace for free? Any thoughts on this? I would be willing to pay for a BP implementation, but recent events make that highly unlikely.

[Pantong51]

I want a C++ implementation with Blueprint integration. I'd like to take this even further with performance upgrades I might do once I wrap my head around everything, although from looking at the code I'd need to do it from scratch.

[NilsonLima]

To get back to Deathrey's point, and my previous comments .... The advantages of a Blueprint implementation over adding yet another plug-in, with the frequent UE4 version releases, are many. And as Deathrey pointed out, the downside in performance is barely measurable.

I for one, and I think there are many that agree with me, would prefer this, 100% in Blueprints. This is an idea originally presented here by TK, in which he posted screenshots of his progress. Does anyone know the status of TKs Blueprint implementation? A second question, will EPIC allow this to be released on the Marketplace for free? Any thoughts on this? I would be willing to pay for a BP implementation, but recent events make that highly unlikely.

I think it does not need to go to MP, it just needs an aditional folder created inside this project's github with the blueprint implementation where this could share all the materials and still be part of this project being a dual solution. The blueprints could be done in parts for each feature: buoyancy, sun and moon trajectories, fish manager, etc

[EvoPulseGaming]

I don't want to promise anything...

About a month ago, I had finished fleshing out a multi-sided armor system... but I needed some sort of weather system for temperature to determine armor cooling/heating via weather/water.

Which led me here... and while playing with this... I found this: https://github.com/igarciad/weather_simulation
This is a small scale weather simulator (limited by a single cloud type and a few things but overall a great start)

And I noticed something!

They both use lat/long and time! (Ocean uses it for Sun/Moon) (Weather Sim uses it for radiation/temperature calculations by calculating the position of sun/earth)
So since I can easily couple these two by lat/long and time, I decided to clean up OceanProject.

So, I made a pull request on github to update the project to IWYU so could reduce the iterative compile times by 25-50%, because I'm the type to try try try again until it works and the faster I can click the build button the better!

I PLANNED on doing what is done here : Heavy code in c++ and front end in blueprints...

but now i'm wondering if I should just take my effort to all BP since I am going through this whole mashup anyways...

If we can agree to leave mathematically heavy functions in code (Should never break?), then I can move all UObject, UCore ect into blueprint so its more upgrade/future proof.

[duke22]

I think it's best to keep it in code, but exposed to BP. BP should be the extension point. But that's just me

[sandfoxdev]

Good afternoon. I had a small problem when opening your project on a Linux system. Tell me, please, how to fix this?

Deabian 9 (xfce4) x64
GTX750Ti (Nvidia-smi 375.82)

I apologize for my bad English.

Log: https://gist.github.com/sandfoxdev/2...b1182943372396

[NilsonLima]

Good afternoon. I had a small problem when opening your project on a Linux system. Tell me, please, how to fix this?

Deabian 9 (xfce4) x64
GTX750Ti (Nvidia-smi 375.82)

I apologize for my bad English.

Log: https://gist.github.com/sandfoxdev/2...b1182943372396

It seems there are diffences in Linux regarding the support for texture samplers in a material. The material with issues is M_Ocean_SSR (but maybe more have same issues) and the thing to be checked in this material is if all textures are marked as Shared:Wrap to save up samplers. Im not going to be anywhere near the code atm to check for you since Im at airport to take a flight, but this is a good start.

[DWGS]

Anybody know how to get rid of these black artifacts? They appeared out of nowhere. I tried messing with the settings but I can't get it to work properly.

The only Shader that works correctly is the Ocean Ultra shader but I don't want to stick with that because it has big performance impacts.

It appears to be the strength variables of the normals(medium or far), try setting them below 3.0.