What's the best way to use UIWS with World Composition?

Development Rendering
,
1

So what would be the best way to go about implimenting the Unified Interactive Water System in world composition?

I read from the UIWS documentation that I need to add a UIWS manager to the persistent level to be able to load UIWS water actors alongside streamed levels when they become visible and I also saw in a debug tutorial that only the water around the character is simulated so the rest of the water body is not simulated until a character walks close, but my question is:

Is it more performance friendly to use one water actor inside the persistent level spanning the entire map or is it better to just add a manager to persistent level and add water actors to each streamed level individually, and if so, then what is the best way to scale each individual actor to fit the bounds of their respective level?

2

In short. Don’t use the water system.
Make your own.

For A bit more info.

Adding to the persistent is only applicable to non rendered actors.
Why?
Because if rendered, they will always be rendered when present in persistent.

As such,
Putting a water actor that renders water in persistent is an immediate red flag for performance.
Putting in an actor that handles water interaction but isn’t “always rendered” doesn’t affect performance.

Adding individualized actors to each level is always better.
This includes procedural foliage, RTs, and whatever other construct you can think of.

If the level isn’t there, why should the components that make up that level be loaded? They should not.

Why make your own?
Because the current system is a true mess. It’s not really thought for world comp, since they mentioned they want to remove world comp anyway.
Its basically unknown what they want to replace the system with, or when. And how much of the engine and old projects they will break.

Going by the overall company track record, forums fuckup included, we won’t be able to use the new engine version for a year or so until they actually solve the issues they created by removing functions.

So, if you want to get something done that will persist through engine versions, make your own.

Its pretty simple too at a base level.

You need a CPP class that allows for a blueprint function that returns the wave height at a specific location.
With that function, you can implement various ways to make characters/stuff “float”.

The same function you use in code is used in the shader to generate the graphics.

Thats the gist of it.

Interaction is done locally with flow maps and vector fields. Usually does not affect other things.

Last but not least. If you want something that’s a lot better than what you can cook, and a lot better than what the epic team has put together this far, BUT has completely ignored…
Nvidia waveworks.
The engine for it is behind in version, but the effects it gives, and cost of rendering is a real benefit…
If you are making a surfing game or something that requires high complexity, its something to really consider despite being stuck to an older engine.

1 Like
3

OP is talking about UIWS - Unified Interactive Water System in Code Plugins - UE Marketplace, not the ue4 water.

OP, I use UIWS, water manager in persistent level, then just scale each water actor you need for each sublevel and UIWS will take care of it all. you can set the size of the area that gets simulated in the manager.

2 Likes
4

Hi thanks for the detailed answer! It really cleared up a lot about world composition.

As for the water system, we’re talking about the Unified Interactive Water System right? By Elliot Grey? UIWS Plugin Overview - Unified Interactive Water System for UE4 - YouTube

I know UE 4.26 water system is still in development stages and UE 4.26 isn’t readily supported by many assets in the marketplace either so I’ve been sticking to 4.25 and as far as I’ve heard from others, UIWS seems to be the best water system for indie devs at the moment.

Lastly, Elliot did do some work on the UIWS to enable it for world composition, it’s in his patch notes:
UIWS 1.8 RELEASE NOTES:
" You now manually add a UIWS manager to your persistent level. No sub level (when level streaming) needs a manager anymore.

Hypothetically this should allow runtime creation of water bodies, but I’ll need to test this before I gaurantee that"

Lastly, I’ve been experimenting with keeping seperate UIWS water actors in each streamed level, it works performance-wise but I can’t seem to get the actor to span the entire area of the level, if I manually scale the actor to the exact bounds of the level, World Composition window shows my level’s bounds to be extended quite alot and I know actors that are placed outside the streamed level increase the level’s bounds, wasting memory. I had to delibrately scale down the actor to a size where at the edges of the level, there is quite a gap with n

Untitled
Untitled1560Ă—888 261 KB
o water because stretching the water actor any further increases the bounds.

5

Oh I don’t mind having a small simulated area, it’s the actor which I am unable ot scale to the edges of the level. I don’t even cross the edge of the level and it still shows the level bounds to be increased. I’ve attached a screenshot for it in another reply on this post.

6

I was indeed talking more about the ue4 water (or mess they made).
Can’t speak for the addon as I never used it before.

However.
Level bounds increase with collision (other volumes not necessarily visible) So if the object collision has a buffer around it - common occurrence to manage interaction and prep it before you reach a surface.

It could be you just need to create a custom component for each tile type that’s connected to a other component of the same - and swap the component accordingly.
The volume/collision, or whatever it is, is handled based on what the adjacent tile is.

A middle tile with all four sides into another water tile would be exact to the bounds.
Where
An edge tile going off to land would preserve the longer collision on that side only.

If that makes sense
And if that is the issue.

Try to enable bounds in editor. Maybe you can spot the actual size even if it is usually represented with a giant sphere.

Not the easiest thing to do on stuff you didn’t create… maybe you can tag the maker of the system here and he can better explain the issue he documented.

1 Like
7

I can certainly try and see if I can adjust the bounds of the UIWS water actor. I’m sure that the bounds are what’s causing this issue.

1 Like
8

Has to be something that isn’t directly visible, or you would see it visually, not just by the level bounds shift.

There’s also 2 ways to calculate extent - in case stuff is happening via code and adjusting bounds dynamically.
Just came across that making dynamic landscape materials a few weeks back.

The bounds can be calculated with accuracy if you use collision or Ignore collision (can’t remeber which option) - a bool option when you pull out the component/landscape extent.

Any calculations based on that measure are either accurate or inaccurate based on the true/false flag.

So, if he’s adjusting the component’s bounds via blueprint or cpp - that could potentially be an issue.
(Which I don’t remember being an issue in .22 when I first tested runtime landscape material changes).

1 Like
9

I checked and it’s certainly the bounds of the actor. But I am unable to adjust the bounds enough to able to span the landscape. The bounds are extending beyond the water actor and are causing the landscape to increase it’s bounds

10

Okay so I’ve run into a dilemma here. I have a very large landscape, and using world composition, I have around 500 sub levels. I’m wondering if just using one gigantic water actor would be more feasible for me as otherwise,

-I’d have to set up each water actor for each sub level, which is tedious in itself,
-then I still have to figure out how to get the bounds of the water actor to fit correctly in the level, as stretching the water material to level bounds extends the level’s bounds due to the water actor’s bounds being a bit larger than the water material.
-then I’d have to make sure all water actors are at the same height,
-and maintenance and debugging would be a pain in the butt.

So I’m thinking of just using one water actor in persistent level that spans the entire map

11

Or, just make a blueptility script to place 9 tiles at a time, or however many you can concurrently load.

Its tedious, but it will perform much better. A single actor can never occlude. You’ll end up drop a ton of performance.

12

which tiles are we talking about here? the landscape tiles or something regarding UIWS?
also can you explain a bit more about the occlusion?

Because UIWS has it’s own LOD managment system and an adjustable simulation range so I could have the actor spanning 20 km and still have only 10 m around the character be simulating. It’s optimized really well. I was able to get the single actor spanning across the entire map and tweaked the resolution and tiling stuff to get it running quite smooth actually.

I made a little video: 2021-04-30 03-50-18.mkv - Google Drive

Currently getting around 250 mesh draw calls on this so I guess UIWS really did prove it’s worth? It IS like 400 USD on the marketplace so it better prove it’s worth. I should state that I am running this on a fairly low-end business laptop so mid-range PCs should fare off quite well

13

From the video I’m not sure I would call that excellent performance. BUT.
Water as a whole is challenging either way. So it’s probably not the worse it can be either.

As far as the tiles go.
I’m referring to the tiles in world composition.

Like discussed before, I don’t know much of anything about the specific plugin or how it handles things.

Regardless, at a base level, despite what the actor does of his own accord with however it is set up.

More actors = more draw calls
But also
More actors = more culling = possibly less draw calls

So its that give and take that you have to fine-tune for your project based on what machine it has to run on.

And to do that on a plugin that isn’t my own, I would set up benchmarks:

10x10 tiles of world comp with individual actors
vs
Same map copy but with 1 actor in persistent spanning the full extent.

I’ll tell you this much, using HISM properly you can actually reduce the ocean’s cost by a ton without having to resort to tricks.
Just using a 10mx10m mesh with 1mx1m tessellation at LOD0 and reduced all the way to 4 vert by lod 5 - plus the shared material is enough to get something that can run at any size on anything at all.

However consider this.
100mx100m area is 10x10 10m tiles and therefore 100 draw calls.

Scale that up and down as you may, when dealing with 120km^2 that’s a lot of calls regardless.

That’s why normally (not necessarily for this plugin) it’s better to keep stuff within its proper tile and allow it to occluded or not even load at all when the internal system says so.

1 Like
14

Ironically, the performance you’re seeing is actually the performance I get doing anything on this PC. Especially with the screen recorder running. It’s very low end lol. I’m quite happy with how the actor is working rn but I’ll update further when I start adding more actors to level and see how that goes.

Also, what’s HISM? And also, is it possible to use LODs with world composition? Cause world comp. just unloads the whole thing at a set distance so can LODs for actors and landscape even be used with world comp? I tried to search but didn’t find anything regarding how to handle LODs alongside world comp. Documentation for world comp is very scarce.

And in “reduced all the way to 4 vert”, do you mean, like 40%? I haven’t gotten to learning about LODs much but I did a bit of LOD for landscapes and there were different LOD levels and percentages that I could set as per each level. Would love it if you could tell me more or direct me to a good knowledge source for this.

Also, can you tell me how does the occlusion work and how do I let my actor get occluded?

15

HiSM = Hierarchical instanced static meshes (component).

Usually the thing you use to make collections of items like water tiles that helps with performance.
No idea if the plugin uses that in reality - but you can probably bet on it as a safe bet.

Re the LODs.
Yes.
When you generate level LODs a new level is created with whatever settings you picked.
You need to copy the water actor over to this level, or perhaps easier, replace the water actor which is completely useless here with just a 4vert plane.

This is if you do it on a per-tile basis and not as a global water thing.

There isn’t much out there, you just set up impostors on a “per tile” basis, double click the level that the engine creates (containing the mesh replacement and maybe/possibly the foliage replacement) and work on it directly by adding the water plane that will obviously be missing.

By reduced all the way to 4 vert I mean exactly that.
A plane made with only 4 vertex.
It’s all you need for the 2 tris that make up a plane to draw the plane.

Re Occlusion
FUSTRUM CULLING is built into the engine. You don’t really have to do anything so long as your actor bounds are set up properly.
Or the mesh bounds in the case of a repeating instance.

note that normally with water you want to bump the Z of the bounds up by a bit, or you get flickering at a distance because the view occluded the tile behind it. Also common on flat landscapes

1 Like
16

Thank you so much! This has really helped me understand a lot and given me material to search upon to further my understanding! <3

1 Like