Does anyone know if it is possible to change the seed shape? I’d like to try out stuff like a torus rather than a sphere. Though id also like to try stuff like a dragons head if its possible.
Training Livestream - Realtime Simulation and Volume Modelling Experiments - May 2 - Live from Epic!
Thank you been learning a lot from you
Hi, I have some difficulty installing the plugin. I put the plugin in the plugin folder of the program files, and the content folder in my project content, but when I load a map, a ton of “Can’t find” appear. Can you tell me what I’m doing wrong? I’m using 4.18.3 btw, if that changes anything.
You need to browse the Plugin Content folder inside the editor, this is why you dont see anything, inside the project Content there is nothing. Browsing the Plugin Content folder you will find maps to test the stuff.
Thank you for your answer. Unfortunately, When I turn on “Show Plugin Content” Nothing appear… When I try to load a test map from the basic content browser, the map is empty (except for the primitives) and the log looks like the screenshot I attached. I don’t know what I’m doing wrong…
EDIT: I realized that none of the material are connected to the blueprints, and same thing for the Texture Samples inside the materials. I’m pretty sure this isn’t normal, but I don’t know how to correct it, except by pluging in everything by hand.
I will upload for you a project with all set up already. You just need to open the project. Give me one hour until I can have it done.
Thank you so much for taking the time to put together this scene! Sadly, it’s still not working. I first had to install visual studio, which is normal apparently, so no problem there. Then I tried to open the scene, and I made a copy to open it with 4.18. Then, before it opens, I get this message:
**Project files could not be generated. Log output:
Running C:/Program Files/Epic Games/UE_4.18/Engine/Binaries/DotNET/UnrealBuildTool.exe -projectfiles -project=“C:/Users//Desktop/GDC_Volumetric/GDC_Volumetric 4.18 - 2/GDC_Volumetric.uproject” -game -rocket -progress
Discovering modules, targets and source code for project…
While compiling C:\Users\Desktop\GDC_Volumetric\GDC_Volumetric 4.18 - 2\Intermediate\Build\BuildRules\GDC_VolumetricModuleRules.dll:
ERROR: c:\Users\Desktop\GDC_Volumetric\GDC_Volumetric 4.18 - 2\Source\GDC_Volumetric.Target.cs(19,12) : error CS0122: ‘UnrealBuildTool.UEBuildBinaryConfiguration’ is inaccessible due to its protection level
ERROR: c:\Users\Desktop\GDC_Volumetric\GDC_Volumetric 4.18 - 2\Source\GDC_Volumetric.Target.cs(17,23) : error CS0051: Inconsistent accessibility: parameter type ‘ref System.Collections…List<UnrealBuildTool.UEBuildBinaryConfiguration>’ is less accessible than method ‘GDC_VolumetricTarget.SetupBinaries(UnrealBuildTool.TargetInfo, ref System.Collections…List<UnrealBuildTool.UEBuildBinaryConfiguration>, ref System.Collections…List<string>)’
ERROR: c:\Users\Desktop\GDC_Volumetric\GDC_Volumetric 4.18 - 2\Source\GDC_VolumetricEditor.Target.cs(19,12) : error CS0122: ‘UnrealBuildTool.UEBuildBinaryConfiguration’ is inaccessible due to its protection level
ERROR: c:\Users\Desktop\GDC_Volumetric\GDC_Volumetric 4.18 - 2\Source\GDC_VolumetricEditor.Target.cs(17,23) : error CS0051: Inconsistent accessibility: parameter type ‘ref System.Collections…List<UnrealBuildTool.UEBuildBinaryConfiguration>’ is less accessible than method ‘GDC_VolumetricEditorTarget.SetupBinaries(UnrealBuildTool.TargetInfo, ref System.Collections…List<UnrealBuildTool.UEBuildBinaryConfiguration>, ref System.Collections…List<string>)’
ERROR: UnrealBuildTool Exception: Unable to compile source files.**
The scene doesn’t open after that.
I tried opening the 4.18 version after that, and they tell me that it requires the HoudiniEngine plugin, which I don’t have, and I’m also not sure if it’s necessary for this project.
I’m really grateful for all the time you take to help me, thank you so much!
Houdini is not necessary and you can ignore it. One portion of the project which needs the C++ code are related to VR gear to paint the volume texture’s velocities. When you install Visual Studio (2017 is preferable) there are some modules of it you need to install too as this is preventing the successful compilation. Check the forum for the tutorial about visual studio installation and it tells the module names, Im quite not with my hands in the correct computer to check this atm.
Loving this plugin. Is there anyway to get a shadow from the VolumeRay material once its being rendered in the S_Box_insideout? I’d like to use these as clouds in a stylized environment.
Hey,
Is there a way I can add velocity (not using VR) to a volume I’ve imported (from Houdini)? I want to create the volumes in Houdini but add velocity to them in Unreal?
Any pointers would be appreciated.
The only way is to write a light function taking into account several samples from the volume texture to make the shadow an approximation of the cloud shape.
If you study the material and the blueprints which handle the VR portion, you will see that the velocity is written into a Render Target which is later sampled in the Material and the handled in HLSL node to add that velocity to the initial volume texture. Disregarding the VR portion, all you need to do is to author a static texture or create one in runtime containing the velocities, and each change in the velocities you just update the Render Target… This is the only thing you will need to address and the material pretty much is the same.
Thank you, i’ll take a look seems doable. Also how would I go about manipulating the velocity say with a mouse? I’m rendering the results to a movie for the time being in stead of runtime as well.
Inside this project there is the fluid simulation which you mouse click/drag on a plane and it disturbs the fluid being simulated. You can use the same approach.
@
I hope this a good place to ask, and You would not mind sharing thoughts about a rather specific question:
I am using 2D fluid sim to drive evolving wind field, that is used for foliage animation. This wind field covers certain area around the player.
Center position of this field is snapped to player’s position with set snap size,expressed in render target texels, in a pretty much the same manner, as shadow cascade snapping works.
When shift occurs, I am also shifting contents in all render targets, associated with the sim, by a corresponding number of texels.
After the shift, simulation border is shifted, exposing texels, where simulation was running not running before, and those texels are populated with initial values( zero pressure zero velocity).
Now, the problem is, that such shift eventually affects all simulation after some time. I can’t say that is exceptionally noticeable, but it is definitely there.
Seeding new texels with a data by padding to previous border does help, but it is still noticeable unfortunately.
Maybe You could kindly share some ideas, how this can be handled?
What you are describing is the open boundary problem.
Typically in fluid sim, the domain is periodic due to the nature of sine waves. There are various other ways of handling the boundary, called boundary conditions.
The most commonly discussed boundary conditions for graphics are actually methods for solid obstacles, which generally call under the Free-slip and No-slip boundary conditions. In those cases what you basically make sure the texels near obstacles have no velocity aligned with the normal of the obstacle.
Open boundaries are a bit more complicated. One trick is to clamp UVs to texel centers at every stage of the simulation (ie, including during pressure iterations). This does lead to a problem where inflows can blow up though.
This became a big issue for me doing the 3d fluid sims for the fortnite launch trailer. Any kind of edge masking, including with a nice soft falloff function, was causing huge ripples and distortions that were ruining the subtlety of the sims.
Note that for 2D, this is not quite as much the case, since you can afford to make your RTs bigger and use a really wide soft falloff to 0 function. In many cases that will be good enough for 2d if you can afford the larger area. But in 3d you can’t afford to increase your volume size.
I handled it by first clamping to texel centers, but limiting inflows during the advection stage by doing a directional mask dot product with the normal of each open boundary. Then you have a parameter for the inflow dampening.
The reason that appears to work is because you always want outflows to be able to leave the volume, but since inflow vectors can be generated at boundary texels, if those keep on sampling at the texel centers, the inflow may never go away and thus might ‘blow up’. Directional dampening pretends to assume something about the frequency of amplitude of inflows. Definitely not a perfect solution but worked for me.
The ‘real’ solutions for this open boundary problem are more complex and expensive. Look up the conjugate gradient method. It’s an iterative approach similar to jacobi or newton iterations where you would take some samples to increase the accuracy of the guess for what texels sampled outside of the domain would be. I am told this is what most of the film level solvers use, but I have not actually seen an implementation, and I have never actually seen a paper written describing that particular application. It just requires a good understanding of the mathematics.
There is a method called “Perfectly Matched Layers” for this which basically use a fourier series to predict the values outside the domain using frequency decomposition.
Here is one paper on open boundary conditions. Maybe this will give you an idea of why I went with the simple inflow dampening approach.
Thanks for your response.
I’ve looked up a paper, named An Introduction to the Conjugate Gradient Method Without the Agonizing Pain to realize that some of the pain is still there.
I’ve experimented with soft edge dampening. It definitely improves the situation, but on cascade shifts, the shockwave travelling through the sim is still there. I’ve evolved that into expanding simulation area to include area beyond cascade dimensions, equal to the size of the shift and slowly blending border from previous position to new position, but this is not very practical, since I can’t predict when or how frequent the shift will occur, as it depends on player movement speed, and I will need to prevent shift from happening, until the fade had been completed. Gets a bit bulky at this point.
I think I will have to go with wrap boundary instead of free slip boundary, and do not shift the sim at all. I will have to ensure, that the particles/objects, I am using to inject the velocity with, exist only one frame, then the shift of the render target, that stores captured velocities, to be injected into the sim, will not reveal the shift at all.
It gets me into another problem, that is obviously exploding sim with wrap boundary. Without sufficient dampening, it will inevitably explode. I can’t reliably measure velocity inflow, because it varies from nothing to N objects of any size injecting any velocity. I guess I will have to just eyeball dampening large enough, for sim not to explode in worst case game condition plus margin of safety.
Another thing that I cannot get right, is making the sim more or less framerate-independent. Using frame delta time straight up causes hilarious shockwaves. Averaging delta time does help, but I had to smooth it out over past 20 seconds at least to get a stable sim.
You need to do custom time accumulation. So you actually need to do a while loop and do substeps any time too much time has passed, and skip frames where not enough has passed. This can lead to a vicious cycles if your sim is not optimized enough for that.
I tried sub-stepping as you suggest, while keeping time delta constant for each step. It indeed solves all the issues, but unfortunaly I can’t afford it. I’d want frame to frame load to be more or less coherent. Plus I am already spreading simulation over 3 frames (advection, vorticity calculation, vorticity+force application, divergence, 11 pressure steps in first frame, 15 pressure steps in second frame, 14 pressure steps and gradient subtraction in third frame). I guess I will have to go with constant delta time in any case.
Also seeding the wind sim(actually injecting velocities every frame, not seeding) for realistic appearance is a bit harder than I thought.
On a side note, I wanted to share a bit of a trick with vorticity, that seems to help me greatly. When calculation vorticity force and applying this force, instead of sampling nearest pixels in a cross, increase the stride to 2-4 pixels, depending on sim resolution. Doing so generates quite stable and large vortices, even at low pressure iteration counts.