#1743 closed defect (fixed)
Super fancy water problems in Atlas
Reported by: | historic_bruno | Owned by: | wraitii |
---|---|---|---|
Priority: | Should Have | Milestone: | Alpha 16 |
Component: | Atlas editor | Keywords: | |
Cc: | wraitii | Patch: |
Description (last modified by )
Atlas cannot have foam or waves because it is currently too slow to compute. This is linked with some water settings (waviness notably) which should force an update whenever they are updated.
To help with this issue, we could:
- Wait until the user has stopped modifying terrain/settings to update, which would improve usability drastically if it's really slow. Alternatively, we could only update the patches visible on camera when updating, and update the others when the user is finished (this could also be used for in-game terrain changes if it happens to be too slow).
- Do partial update of the data (currently 4 arrays: 2 for wave direction, one for foam amount, one for "distance to shore"). If we could update only the foam amount, for example, it would be much faster to simply change the waviness and we could likely re-enable foam in Atlas.
Ultimately, we could also thread the computation, optimize it as much as possible, or do it in multiple steps. Two related problems:
Modifying terrain causes a noticeable delay in Atlas when super fancy water effects are enabled, since it recomputes all the water render data.I think one thing which would help is waiting until the user has stopped modifying terrain before updating, but it will still cause a delay.Not sure if it's feasible to do a partial update of the data, perhaps restricted to a certain area which was modified?Another thing to consider, if we allow terrain to change during games, the same case will be used, and as annoying as it is in Atlas, it would be far worse to experience this delay in-game.Other options: threading or optimizing the computation, or splitting it into multiple steps?
Changing water height doesn't force the data to update, should be a simple fix toCCmpWaterManager
.
Attachments (1)
Change History (15)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
I'm somewhat regretting that I suggested enabling the superfancy water in Atlas. If we can't make it more efficient, then it should be disabled, and map designers will simply have to load the map in game to view the full water appearance.
comment:3 by , 11 years ago
It can still be made more efficient (much more). I however haven't had time... So maybe going back is better here, it's a pretty simple change.
comment:5 by , 11 years ago
comment:8 by , 11 years ago
Milestone: | Alpha 13 → Backlog |
---|---|
Owner: | set to |
Priority: | Must Have → Should Have |
Status: | new → assigned |
So this has been "fixed" by not having the fancy water foam or waves in Atlas for now. I'll fix this more properly when I get some time to work on it, probably this summer. In the meantime, backlogging it and moving to a should have status.
comment:9 by , 11 years ago
Water is glitchy in Atlas now (#2063), it may or may not be related to special casing to avoid superfancy water computation.
Also the proper fix will become higher priority once we have terrain flattening under buildings (#21). Philip already has a prototype for that, so I think we need to address this.
comment:11 by , 11 years ago
Description: | modified (diff) |
---|
Okay so the proper fix is on its way with [13698]. Basically I made incremental changes possible (the game will only update relevant patches).
To further fix this, I need to allow actual partial data information (no need to recompute, for example, the distance to shore, which is really slow, if we're only changing the waviness). This might allow to have foam and waves in Atlas again.
comment:12 by , 10 years ago
Milestone: | Backlog → Alpha 16 |
---|
This would fix those issues, but I've got an issue with Atlas and am not sure I'm not breaking everything, so here's a patch.
by , 10 years ago
Attachment: | WaterFix.patch added |
---|
comment:14 by , 10 years ago
I don't see the button to recomputer water parameters, on Windows 7 custom build. There is an empty space where I think it should be.
I'll look into the second... For the first, I believe I tried implementing the first solution but it didn't really work. The second: perhaps, I'm not sure the terrain code allows it... I'll probably try to implement doing it over multiple frames. Not sure I'll be able to this WE, but it sounds possible.