For how "simple" it is, that looks really good 😮 Could you use LODs to go from the top to the bottom to A) improve the vertex count and B) make the top thicker and break up more gradually?
Hmm, LODs, no I don't think so. You can't force an LOD switch, it's based on components bounds screen size, period. And since all instances are initially stacked on top of each other, even hierarchical instances would all switch LOD at the same time, so controlling vertex count is out the question. Making the top thicker and breaking up more gradually, yeah sure, using techniques demonstrated in the video: shapekey, normal offset and so on (to the limits of what dithered opacity can do though)
I was looking into how to do something like this because we have elevators with rope/chain that runs up/down. And I did not like the BP solutions I could come up with. I'm happy you did a deep dive on this!! I appreciate it a lot! I had been thinking of basically panning the meshes on the z axis. But I was hoping there'd be some cool magical way to draw the object infinitely and then clip to some bounds. I've learned since that you can do basically just that with raymarching so now I'm totally overengineering this idea. But it.. should be possible using that.
Hi, does checking off "World Position Offset Writes Velocity" setting on the InstancedStaticMesh component help with that velocity glitch? Didn't have opportunity to check it myself yet.
Very impressive, but very difficult to replicate. Also do you unwrap UVs in a particular way on the Blender cylinder before exporting? I get different UVs than yours, way different. What are the scalar values you're putting into your Inputs on the MF_BallisticOffset we create around 3 minutes? I'm getting errors for that MF in the material. Up until minute 5, very much enjoying myself otherwise! :)
What makes you think your UVs are way different than mine? I don't think I show the UVmap in the video. Also, no, no unwrap, UVs are actually not required here. MF_BallisticOffset have 2 scalar inputs and 1 vector3 input. Gravity is by default -981 but is later connected to a scalar value in the material anyway, 13:06, just like the Flow, 4:39, and Time, 5:02. Everything is shown in the video :)
@@ghislaingirardot Ah I see, I meant gravity scalar at 4:28. I see the material continues to evolve many times over as you go on. You're a UE genius man, that's obvious. As someone less practiced in material development who is following along trying to replicate, my humble feedback would be that although the steps you took to solve issues and show us the evolutions are insightful, they can be tough to follow for the leigh person. For instance, I wouldn't know that an issue I'm getting hung up on at minute 5 (not knowing the scalar value of gravity input at this point) would become moot in minute 13. Does one trust and keep watching? I don't know, well done though
I remember seeing a technique that used a simulation of liquids to generate the meshes. I once tried to do it Blender (original authors used Houdini) but it was pretty painful, your technique looks much simpler (the mesh generation looks simple, the animation is complex) and yields very nice looking results. Great job :)
Thanks! You're probably talking about Simon Trümpler's VFX :) Mine is definitely simpler, but if you're able to use a splash simulation, it'll look better :) It's painful to create tho, especially in Blender, I agree.
Absolutely fantastic amount of knowledge being imparted here, too much for my smooth brain to catch onto at speed, but I will be dissecting this! Thanks again Ghislain, incredible work.
Hi there Mr. Girardot, I nearly have your full setup recreated, but all of my mist particles are spawning at 0 0 0 in the local space of the NS--they get the right velocity data from the curve, but aren't spawning in the form of the waterfall. Velocity is correct but spawn position isn't. I've triple checked the custom module setup and it's identical. Thoughts?
Hello there! This is incredible amazing, really good job! Wanted to mention that there's an issue with the bounds not being translated properly that makes the FX cull hidden when the location of the waterfall is not in the center of the map being the actual bounds out of the camera fustrum whilst directly looking at them, one solution might well be to adjust the niagara bounds to where the bounds really are or there will be another better solution? Looking forward on your next stunt! Keep the good work
@@JAMbosco Hello! My bad, you're totally right, there's a tiny oopsie. The issue is in the SpawnFX function, when calling the SetSystemFixedBounds. Getting the InstancedStaticMesh's Origin via the GetComponentBounds returns a world space origin, so it just needs to be converted to local space. Use an 'Inverse Transform Location', plug a 'GetActorTransform' & the 'Origin' in it and use the Return Value instead of the Origin for both the Subtract & Add operation just before the 'MakeBox' function. That fixes it and is less expensive than recomputing the BallisticLocalBounds! Cheers
@@ghislaingirardot Thank you! Great stuff will do! Instead of recomputing the Ballistic bounds did end up exposing those min/max variables but my solution was causing a weird flickering when playing on PIE that required to finally recompute those bounds at begin play x) Thanks for sharing the optimum fix indeed is better the inverse transform, keep the great work and keep them coming
Thanks! Absolutely, yes. You could use an RGB curve to create a 3D path, and sample the curve using the normalized height instead of using it to compute the ballistic trajectory :)
@@AK-trud Hmm, no, nothing comes to mind but it should be pretty straightforward. Use the normalized time in a curve sampler and have your RGB curve depict XYZ positions and that's it.
![Your Triplanar is wrong. Here's how to make one that works. [UE5]](http://i.ytimg.com/vi/Cq5H59G-DHI/mqdefault.jpg)
wake up babe new Ghislain video :)
Every video from G-san is a new tool on my backpack that I will never take out even if I never use it.
G-san 😂
@@ghislaingirardot Ohh-G-Sama ^- ^
I usually do a mesh with a moving texture and some particles for these liquid drops, but I want to try this its looks great, cheers!
A very cool workflow for most VFXs! It's usually how it's done, yep :)
For how "simple" it is, that looks really good 😮 Could you use LODs to go from the top to the bottom to A) improve the vertex count and B) make the top thicker and break up more gradually?
Hmm, LODs, no I don't think so. You can't force an LOD switch, it's based on components bounds screen size, period. And since all instances are initially stacked on top of each other, even hierarchical instances would all switch LOD at the same time, so controlling vertex count is out the question. Making the top thicker and breaking up more gradually, yeah sure, using techniques demonstrated in the video: shapekey, normal offset and so on (to the limits of what dithered opacity can do though)
Is this gonna run on mobile? And how "cheap" is it actually (like would you do this for actualy games)? I really like this idea tbh
how you deform the mesh at 24:18,I'm dying to know!
just move vertices with soft selection
I was looking into how to do something like this because we have elevators with rope/chain that runs up/down. And I did not like the BP solutions I could come up with. I'm happy you did a deep dive on this!! I appreciate it a lot!
I had been thinking of basically panning the meshes on the z axis. But I was hoping there'd be some cool magical way to draw the object infinitely and then clip to some bounds. I've learned since that you can do basically just that with raymarching so now I'm totally overengineering this idea. But it.. should be possible using that.
Hi, does checking off "World Position Offset Writes Velocity" setting on the InstancedStaticMesh component help with that velocity glitch? Didn't have opportunity to check it myself yet.
FYI there is a typo at 13:22 :)
It will but you need to write velocity for TAA & MoBlur. It's just too important to completely skip for such an effect.
Very impressive, but very difficult to replicate. Also do you unwrap UVs in a particular way on the Blender cylinder before exporting? I get different UVs than yours, way different. What are the scalar values you're putting into your Inputs on the MF_BallisticOffset we create around 3 minutes? I'm getting errors for that MF in the material.
Up until minute 5, very much enjoying myself otherwise! :)
What makes you think your UVs are way different than mine? I don't think I show the UVmap in the video. Also, no, no unwrap, UVs are actually not required here. MF_BallisticOffset have 2 scalar inputs and 1 vector3 input. Gravity is by default -981 but is later connected to a scalar value in the material anyway, 13:06, just like the Flow, 4:39, and Time, 5:02. Everything is shown in the video :)
@@ghislaingirardot Ah I see, I meant gravity scalar at 4:28. I see the material continues to evolve many times over as you go on.
You're a UE genius man, that's obvious. As someone less practiced in material development who is following along trying to replicate, my humble feedback would be that although the steps you took to solve issues and show us the evolutions are insightful, they can be tough to follow for the leigh person. For instance, I wouldn't know that an issue I'm getting hung up on at minute 5 (not knowing the scalar value of gravity input at this point) would become moot in minute 13. Does one trust and keep watching? I don't know, well done though
@@ninomancuso7021 Noted, thanks for your feedback :)
Really amazing, is there any possible to make the tutorial for waves and foam for sailing boat, thanks in advance 🐱
I remember seeing a technique that used a simulation of liquids to generate the meshes. I once tried to do it Blender (original authors used Houdini) but it was pretty painful, your technique looks much simpler (the mesh generation looks simple, the animation is complex) and yields very nice looking results. Great job :)
Thanks! You're probably talking about Simon Trümpler's VFX :) Mine is definitely simpler, but if you're able to use a splash simulation, it'll look better :) It's painful to create tho, especially in Blender, I agree.
Your videos are awesome, You're so awesome, thanks for teaching.
Thanks for watching! 😊
Absolutely fantastic amount of knowledge being imparted here, too much for my smooth brain to catch onto at speed, but I will be dissecting this! Thanks again Ghislain, incredible work.
Thanks, appreciated!
Hi there Mr. Girardot, I nearly have your full setup recreated, but all of my mist particles are spawning at 0 0 0 in the local space of the NS--they get the right velocity data from the curve, but aren't spawning in the form of the waterfall. Velocity is correct but spawn position isn't. I've triple checked the custom module setup and it's identical. Thoughts?
Hi! Make sure the position set in your custom module isn't overriden by the 'InitializeParticle' module. (try using UnSet on the position)
@@ghislaingirardot Thanks, I'll try that out as soon as I get back to the lab!
Hello there! This is incredible amazing, really good job! Wanted to mention that there's an issue with the bounds not being translated properly that makes the FX cull hidden when the location of the waterfall is not in the center of the map being the actual bounds out of the camera fustrum whilst directly looking at them, one solution might well be to adjust the niagara bounds to where the bounds really are or there will be another better solution?
Looking forward on your next stunt! Keep the good work
Alright fixed it! Just passed the GetBallisticLocalBounds Min and Max directly to the Niagara SetSystemFixedBounds!
@@JAMbosco Hello! My bad, you're totally right, there's a tiny oopsie. The issue is in the SpawnFX function, when calling the SetSystemFixedBounds. Getting the InstancedStaticMesh's Origin via the GetComponentBounds returns a world space origin, so it just needs to be converted to local space. Use an 'Inverse Transform Location', plug a 'GetActorTransform' & the 'Origin' in it and use the Return Value instead of the Origin for both the Subtract & Add operation just before the 'MakeBox' function. That fixes it and is less expensive than recomputing the BallisticLocalBounds! Cheers
@@ghislaingirardot Thank you! Great stuff will do!
Instead of recomputing the Ballistic bounds did end up exposing those min/max variables but my solution was causing a weird flickering when playing on PIE that required to finally recompute those bounds at begin play x)
Thanks for sharing the optimum fix indeed is better the inverse transform, keep the great work and keep them coming
Beautiful thanks for sharing this technique
Dude, this is so cool! I love it
Das some sick shit bro
Best!
Amazing technique! Is it possible to follow a path other than ballistic projection?
Thanks! Absolutely, yes. You could use an RGB curve to create a 3D path, and sample the curve using the normalized height instead of using it to compute the ballistic trajectory :)
@@ghislaingirardot Hi. Additional question: anything on your channel that perhaps showcases how to sample a curve in a material as position?
@@AK-trud Hmm, no, nothing comes to mind but it should be pretty straightforward. Use the normalized time in a curve sampler and have your RGB curve depict XYZ positions and that's it.
make some obstacle flow river effect next time