Oh man, you are the man, ! Thank you very much, I’m so very happy now :o
Haven’t tried it yet, but looks amazing! Thank you alot for !
Okay, I really want to understand the source code, but I’m feeling overwhelmed as a C++ noob. There are two things the fluid surface in UE3 had that version doesn’t: the displacement occurred in objectspace, or along the surface normal, while one works only in worldspace. Also, there was the fluid surface normal node in the material editor that would receive a normal map generated by the surface and could be used by the material.
These two things are absolutely necessary for my project. However, I’m just a beginning programmer and I can’t get heads or tails from the source. Now, I do want to attempt to work on it myself, but if anyone can help with at least guiding me through the code, I would be very grateful.
Thank you very much! <3 It looks awesome <3
I have a little problem, as soon as I try to place the main fluid surface blueprint into a scene (The blueprint already placed on default level works ok), my video driver crashes, along with the editor. I guess that’s something wrong on my end? Anybody has a similar problem? GTX 760 here.
The fluid surface lags my entire system when I place it in with a landscape, I’m assuming is being looked into?
Great work so far, I really, really appreciate , more than words can describe, we’re going to compete with Crynegine now.
Also, is there a way to stop it from compiling shaders every time the editor starts up? (I mean where it gets stuck at 45%), and when you get in theres 10,000 shaders to compile, despite going through exact same process 3 times already.
As soon as I open 's project in Unreal, the engine crashes. Anyone have same problem?
Update: Nvm, forgot to copy the shaders.
Hi there Slavq!
Did you make sure to move the Shaders folder to your engine install?
See quote below:
If you did and it still is crashing that’s a big so let me know!
PS: Community please note I did not author and I can only do so much to maintain it by myself so if anyone else wants to help out do let us all know!
I can confirm lag happens for me too, simple landscape, small water plane, I went from 8 ms (120) to about 11-12ms (90s ish)
I dont know who is going to look into however, someone has to step up to the plate and I can only do a little to keep things rolling here.
So** please heed the Calling, O Brave and Adventurous UE4 programmer **who has more time than me,
Thine time to shine has come!
Yes, I’ve copied the Shaders folder content to my Epic Games\4.12\Engine\Shaders\ folder.
The fluid surface works without problems, but as soon as I try to drag & drop the ‘Fluid’ blueprint into the level, my video driver crashes, along with editor crash.
Here is crash log: http://pastebin.com/BQt91jJv, I hope it will help.
Here is what I did: 1. Play in editor, works fine 2.) Drag & drop the ‘Fluid’ blueprint into the scene, then it crashes.
Proposes Recapitulation of
Dear Community,
The started as something that ran on the CPU, obviously has some limits in size, but it would allow us to get the height of the waves on the game thread so that we can make physics objects respond.
Well went a completely different route, the gpu / render thread route. The core code that makes the waves is actually in a shader now, not in the C++ code.
So there’s really no way we can read the height of the waves to make game objects respond to the waves!
The current is positively great for larger surfaces and windows Dx11 machines.
But if we want to support mac and mobile, we need a cpu or hybrid solution.
I am proposing someone step up to the plate and try restarting from scratch from Goldings code.
I dont have time to do it myself, but I can tell you clearly why I think would be a good idea, at least as a variant to the current :
-
We could implement a CPU solution and then investigate supporting a hybrid solution where we do some stuff on render thread, but can still support reading height information.
-
We would be starting fresh with a new group of active contributors so communication will be easy as, well, we’re all still around
-
We know what issues the GPU / render thread version has encountered, and at the very least fresh start would be a different solution with a different set of compromises at first, but if all goes well and we do the hybrid solution right, we’ll ultimately exceed the current purely render thread solution.
-
Starting Fresh always leads to new and greater things I’ve found, especially when it comes to C++ coding.
**So let us have a fresh start! **
The current impl should not overshadow all the creativity of other developers who are now stuck with a they can’t really comprehend / feel stifled in contributing to and the original author is not around.
**A Fresh Start**
The original UE2 code can still be found here, from Golding:
https://forums.unrealengine.com/showthread.php?3609-Project--&p=23003&viewfull=1#post23003
Heart on Fire?
If your heart is on fire right now than you are the one, or one of the ones, to help make happen so please post and we can recapitulate entire project.
I 100% support , and I’m pretty sure most of the community would as well, if they knew what meant for the engine, we’d be on par or better than Crynegine, to be honest.
The only I’ve ran into is the taxing on my GPU, adding the fluid surface actor to a blueprint crashes my GPU, causing me to restart windows to recover, placing the actor in the scene and dragging it inside a static mesh causes frame drops on a massive level, putting the fluid surface into a scene with a landscape, and having it interact with the landscape causes extreme frame drops.
But these are the only issues I’ve come across, nothing else.
Excuse me,i have download the full project updated for 4.12 ,does it contain the files i need to put in my UE4 version? and how to set it up to make it work pls?
Well I have the ue2 code and the 4.8, 4.10 and 4.11 versions, whether we get time to do shaders, cross platform, and work it into the community ocean before TK the machine… we’ll see, but its all in our repo!
@,
sounds like a race!
I wish you luck!
Guys, , Thanks for effort! is a much needed .
On 4.13 I get “Plugins\Source\Public\FluidSurfaceComponent.h(50): error C3668: ‘UFluidSurfaceComponent::CreatePhysicsState’: method with override specifier ‘override’ did not override any base class methods” when compiling.
With 4.13, there’s now the ability to use blueprints to draw to render targets. The content examples include a fluid surface, which works nicely. Unfortunately, it’s nothing more than an example. There’s absolutely no indication as to what does what. I understand the parts where it outputs a heightmap and renders it to the render target, and converts it to a normal map as well, together with the collision and hit detection that creates a splat from which the ripples are formed. However, I do not understand how the ripples themselves are simulated. There are two materials which are used to calculate , which is then output to the render target, but I just don’t get it. Also, as the render target is set to Wrap, when the ripples reach one edge of the texture, they appear on the other side. If I set it to clamp, then the ripples are bouncing off the edge, while I want them to simply disappear and not wrap or bounce. is a really cool , but if there’s no documentation, I can’t wrap my head around it.
+1, I’d also love some more info about
Well I beleive its due to the #if WITH_EDITOR check but I havn’t tested that enough yet removing the override on just that function and seeing if things break, just getting into the code now and fixing other errors for 4.13.2 after fixing shaders.
I’ve gotten all the warnings out of FluidSurfaceComponent, now onto the harder stuff.
Edit: Fixed everything but that weird CreatePhysicsState not calling an override is causing headaches.
Edit2: Fixed it by calling itself recursively, I know its not right but it does compile. Putting out a commit and will post it when done.