A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Assets and Asset Store' started by NWHCoding, Jul 3, 2019.
Dynamic Water Physics 2 is now on sale!
If anyone is experiencing any issues with import of the latest version just remove both SceneInputActions files from DWP2 (not common) folder. An update has been submitted and will hopefully be live today.
Update v2.3.2 is on the way with the following changes:
Added per-object simulation settings.
Added multiple throttle bindings.
Fixed inspector entering infinite loop on Unity 2020.2 when ReorderableList is drawn.
Dynamic Water Physics 2 is currently 40% off as a part of New Year sale.
Still getting a infinite loop on Unity 2020.2 when clicking on any asset ( boat for example) ...
First, make sure you are using the latest version. If that is the case go to the NUIDrawer.cs and find GetHeight function. Inside that function check that it looks like this:
public float GetHeight(string key)
float height = 0;
EditorCache.GetCachedValue("height", ref height, key);
return height <= 0 ? 1 : height;
Thanks guys...just deleted all and made the download again...Problem solved...
I cannot get boats (either mine or the ones provided) to interact with the water; they are currently falling right through the water. I am using the latest version of Crest and DWP2 2.3 with Unity 2019.4.14.
I do have multiple scenes, however the game objects with the water, water objects, and water object manager are all put into DontDestroyOnLoad. I am using the Crest Water Data Provider on the ocean, have the WaterObjectManger attached to a game object in DontDestroyOnLoad, and believe I have followed all the other steps from the documentation.
Is there something I'm missing? Has anyone had success with using DontDestroyOnLoad with Crest and DWP2?
could you please check the WaterObjectManager while in play mode. How many triangles/objects do you see there in the debug section? If you are loading the scenes with WaterObjects after the WaterObjectManager you should do: WaterObjectManager.Instance.Synchronize(); to force the manager to register the objects and update all the internal arrays (NativeArrays are quite expensive to re-initialize hence this is not done automatically).
Also, WaterObjectManager.FindSceneWaterObjects function does exactly that - finds all the WaterObjects in the current scene. To find the objects in all the loaded scenes replace it with:
private void FindSceneWaterObjects(ref List<WaterObject> waterObjects, bool includeInactive)
waterObjects = FindObjectsOfType<WaterObject>().ToList();
I have added this to the TODO for the next update and will include it.
Thanks for your reply. The change for FindSceneWaterObjects worked perfectly.
Glad it did. Have not tested the code .
I will add an option to switch between the two in the next update.
Update 2.3.3 is on the way with the following changes:
CameraMouseDrag can now be used for both 1st and 3rd person view (including rotation, panning and camera shake) and will replace other cameras in the future versions as an universal camera.
Reworked Submarine script and added a PID controller for better depth control.
Added option to synchronize WaterObjects in current scene or all loaded scenes.
Fixed editor division by zero when no WaterObjects present.
Fixed missing 'using Unity.Burst;' inside WaterTriangleJob.
Fixed Burst compatibility on newer versions of Unity.
So, it seems there is quite an oversight with the current version of DWP2 I'm using. I just imported what appears to be the latest version: 2.3.3
When WaterObjects or ships exist in the scene initially, they function as you'd expect.
However, when you spawn them in at runtime, they are ignored and not given buoyancy.
It appears that WaterObjectManager looks for all WaterObjects at Start() and adds them to a list. This list, however, is not repopulated or modified at runtime under normal circumstances. (I'll assume that enabling and disabling the water manager is not a "normal" circumstance.)
I believe the correct thing to do would be for WaterObjects to add and remove themselves from the list.
I'll attempt to make the change myself, but when I update DWP2 in the future, I'd like to know that this change will not get blown away. So, if I succeed, I can send you a copy of the code with my modifications.
After looking more deeply into the situation, I noticed you are already aware of the need to resync when new water objects are created and recommend against it.
Unfortunately the provided alternative solution of having these objects strictly pre-exist in the scene is not an option as it is not possible to know how many of these water objects will exist ahead of time.
In cases like mine, where I need to be able to add objects at runtime, the API provided by WaterManager (Synchronize()) is suboptimal:
If multiple objects are added in one frame, and each object calls Synchronize(), all of the work done for each call is wasted, except for the last one.
Each time Synchronize() is called, it does a slow search through everything in the scene. This step can be avoided altogether if WaterObject instances manage adding and removing themselves.
Instead, the approach I'm taking is to maintain a "public" list and a "private" list. Whenever a change is made to the public list, it is marked as dirty. At the start of the next FixedUpdate() call, it checks if the public list is dirty. If so, it will automatically resynchronize the private list and reallocate the arrays used by the water job.
By organizing it this way it is easier to:
Set an resync interval: Instead of resyncing every fixed update, it'd be easy to set a schedule for how often resynchronization occurs. For example, it waits until a full second goes by since the last sync before syncing again.
Since synchronization is done exclusively by the manager, and is not called arbitrarily by other classes, the process of resyncing can be put on another thread. If it takes time to refresh the arrays this will not interrupt gameplay.
Further, if the sync process is threaded, perhaps it might be possible to create a new set of arrays and set up a new WaterTriangleJob while the other one is currently running. When the new water job and its associated arrays are finished allocating, the previous water job can quit and the new one will take its place. This could prevent resyncing from interrupting the water system itself.
Use the pattern employed by the List class for managing the triangle arrays.
By "triangle array", I am referring to the arrays, both native and managed, which have a length of _triangleData.Count.
Start with a certain capacity for processing triangles, perhaps 1024. Whenever that capacity is exceeded, the triangle arrays' lengths are doubled.
That way when a new water object is added, the only cost involved is with reassigning which elements of the triangle array are associated with what objects. In other words, only _dataStarts, _dataLengths, and _triangleData, would undergo possible length changes. (Of course, the p0s, p1s, p2s and localToWorldMatrices would need to be reassigned, but this doesn't require reallocation.)
Also, simiarly to List, a Count property could be maintained so any processes using the triangle arrays can avoid processing unused elements. This might actually be *faster* than having a massive amount of preallocated triangle data in anticipation of spawned objects, since there would be less time wasted iterating through a list of inactive triangles (as identified by the _states and States arrays).
Edit: I've just confirmed that it is possible to specify a job length that is less than the capacity of the job object. In other words, a Count is possible. Perhaps this is the intended usage.
Well, glad that you already noticed that Synchronize is required when adding objects. I have an update queued and will start work on it somewhere mid this upcoming week to modify the code to pre-allocated additional space and only do the re-allocation if that space becomes filled.
I'll probably beat you to it. I'm already starting now.
If you like, we can keep in touch elsewhere so that I may submit my changes for my approval. It might clutter up this thread.
No problem. Please do not post larger chunks of code in the thread.
As mentioned I will be working on this so if you are not in an extreme hurry you do not need to spend time on it, it is a paid asset after all