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 this version doesn't: the displacement occurred in objectspace, or along the surface normal, while this 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 this is being looked into?
Great work so far, I really, really appreciate this, 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 this exact same process 3 times already.
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.
Hi there Slavq!
Did you make sure to move the Shaders folder to your engine install?
As soon as I open Rama's project in Unreal, the engine crashes. Anyone have same problem?
Update: Nvm, forgot to copy the shaders.
If you did and it still is crashing that's a big issue so let me know!
Rama
PS: Community please note I did not author this plugin 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!
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.
Last edited by Slavq; 07-08-2016, 05:44 PM.
Reason: More info
The plugin started as something that ran on the CPU, obviously this 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 this plugin 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 plugin 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 this plugin from scratch from James Goldings code.
I dont have time to do it myself, but I can tell you clearly why I think this would be a good idea, at least as a variant to the current plugin:
1. 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.
2. We would be starting fresh with a new group of active contributors so communication will be easy as, well, we're all still around
3. We know what issues the GPU / render thread version has encountered, and at the very least this 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.
4. 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 plugin they can't really comprehend / feel stifled in contributing to and the original author is not around.
If your heart is on fire right now than you are the one, or one of the ones, to help make this happen so please post and we can recapitulate this entire project.
I 100% support this, and I'm pretty sure most of the community would as well, if they knew what this meant for the engine, we'd be on par or better than Crynegine, to be honest.
The only issue 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 github 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 plugin before TK the machine... we'll see, but its all in our repo!
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 plugin before TK the machine... we'll see, but its all in our repo!
Comment