Video

TAA is on, default settings. You may tweak the material's translucency pass settign to render it after motion blur. Helps with ghosting.

Thanks!

I'm currently rebuilding it from scratch. Lots of new features to be expected :)

Yup, utility widgets are cool and I agree with you. Using a game mode to build tools is not the greatest experience and certainly has its limits, features wise, especially if you stick with blueprints. I prefer Scriptable Tools to Uility Widgets though. Anyway, I just wanted to show that it's still possible to create tools in-game :)

@@ghislaingirardot yes, actually play mode do give some more options and is easier to check mouse position, editor mode have to make all the offset of screen calculation. Is very limited working with teams. I enjoy your videos, please keep making them!

There seems to be a bug in engine, at least in 5.3.2. The spline component bounds do work in-game but are not updated in engine (construction script etc.) when tweaking the spline, so it's a bit annoying to work with.

Totally. You may for instance use a NavMesh to find a path to a target, create spline points from it and create a vfx that indicates the path to follow

​@@ghislaingirardot Thanks! I thought nav mesh was used for AI. It's hard to imagine but I'll give it a try! I found the breadcrumb trail in Hogwarts legacy really impressive, did they use C++?

@@RV-bc9yi navmesh is used for AI to find paths and move actors through the world. But you can use navmesh to just generate a path and do what you want with that data; like build a literal path to draw a vfx along

@@ghislaingirardot Ok thanks that gives me some leads !

Thanks Tom, much appreciated!

A good solution indeed! Geometry Scripting is sick. Thanks for pointing it out :)

I guess you can handle a very large amount of splines at runtime, I remember once doing a simple test spawning a very large amount. Also Niagara is handled through the GPU, so it can handle a very large amount of particles, think of all the effects people do, rain, snow... you actually have millions of particles with ease

@@3jsjeosn Some truth to that, but lots of inacurracies as well. Niagara isn't necessarily handled on the GPU. 1) An emitter can run on CPU or GPU 2) The emitter update function is always run on the CPU, regardless of the system using CPU or GPU!. So, yes, a GPU Niagara system can handle millions of particles. But a Niagara system comes with lots of overhead and using many many smaller particle systems to sample one spline at a time may cause severe issues. That's why Epic's working on lightweight Niagara systems that has a much more restricted set of features but a way cheaper tick cost. To answer @michaelpiper8198 : it's hard to tell. A spline component comes with the usual component class overhead so there's that. A spline is merely just data though, except when drawn in the viewport, so it should be a negligible memory cost. Sampling a spline shouldn't be too costly either, the math behind it doesn't rely on complex operations. My answer is as usual: do a bruteforce test and see how it performs in worst case scenario. Splines can be efficiently baked into textures though, so you could store many many splines in a small texture, sample each spline using a simple integer ID system so each particle is assigned its own spline, and thus bypass all the spline components and do everything in one unified particle system. If that makes sense. Regarding visibility/function, this is mostly related to occlusion and setting up the emitter's bounds so the CPU can guess if the GPU system should be rendered or not. But I'm almost certain particles are no longer ticked as soon as the system is occluded. This may be an unecessary optimization though. You can may try expanding the bounds by a large amount so particles are always ticked. Unvisible particles will just waste vertex processing afaik, which may or may not be a big deal.

please read the video description.

Gotta be curious & willing to learn. Things start to snowball at one point, if you keep pushing.

@@ghislaingirardot i got really impressed with the strand-based foliage simulation video, I also share the dream goal of realistic foliage interaction, I hope to get there someday

No, shader tricks are not specific to any game engine. There is actually *nothing* specific to UE here, as long as you can read in-between the lines. Most game engines offer a graph editor to write shaders, so a similar shader and similar tricks can be applied in Unity, Godot etc. Just got to be willing to do the hard-work and think on your own to recreate a similar effect in another engine. But then your comment makes me think that you have pretty much zero experience in the video-game industry. Most of us are software agnostic, as you should learn to be. Each engine has its pros and cons. UE isn't the greatest but most definitely not the worst.

This is a custom system I'm describing. The built-in water/buoyancy system is something else entirely.

Props for replicating the setup! It's a complicated one and I know the breakdown format doesn't make it easy to follow along. I did my best :D Geonodes is great!

@@ghislaingirardot the only thing that I didn't implement is your wind/gusts simulation technique from another tutorial. I've decided to settle with a custom wind map from Designer. Though I struggle to understand how to rotate the wind direction properly. Should the coordinates be rotated, or the output of the panning texture?

@mopozuJIko it's precisely something I explained in my wind simulation video. It's not as straightforward as it sounds and my system solves this technical challenge efficiently and effectively

@@ghislaingirardot but isn't your system quite expensive? You mentioned that the capture component costs several ms which is not acceptable in many cases. But then you show an improved solution where you calculate the tiling texture based on the position of particles - is it cheaper?🤔

Thanks!

just move vertices with soft selection

uh. I didn't think of spline mesh components :D Yes, likely troublesome. Also, not sure Geometry Scripting supports spline mesh component when copying a primitive component. Hm. I'll have to try.

@@ghislaingirardot Wouldn't that be a general usecase? Like 'painting' flowmaps onto some splinemash that is supposed to act like a river? So you have a flowing river. I would really like to see this working tbh ^^

@@swrcPATCH afaik, no, using spline meshes is not the general use case. They come with extra cost, have limited support when it comes to Nanite etc (afaik) and you need an annoying setup to create one component for each spline segment, which results in one draw call per segment. You may use spline meshes in editor to create a river mesh but it should eventually be converted to a static mesh. Or, better, rely on geometry scripting etc to dynamically generate a mesh based on a spline. You shouldn't work with spline meshes imho.

@@ghislaingirardot hm good to know. What if I made a river using a splinemesh and lets assume I knew how to convert it to a static mesh, would your tool be able to paint flowmaps onto it or would I have some UV or other kind of issues? Creating rivers using spline meshes is just very fast and flexable. I do not know a better workflow, its not like I really need the splinemesh but I need the flexability

@@swrcPATCH Yes my tool works on static mesh, as demonstrated in the video. No issue to expect, unless your mesh's UVs are messed up to begin with. Consider using geometry scripting to generate geometry along a spline instead of using spline meshes. Same benefit but you have much more control and it's easy to convert to a static mesh. Plus, my tool *should* allow you to paint directly onto the dynamically generated mesh, I think...

Ty! Everything's available to download on my Patreon

@@ghislaingirardot awesome! I'll check it out right away!

Yep, absolutely! Or if you're lazy and don't mind a far-from perfect solution, just use an arbitrary max UV travel distance for the brush. If it exceeds it, assume brush has jumped across an UV seam and cancel paint that tick.

Glad you found it useful! Where have I been? Meaning? I used to work primilarly as an Environment Artist. I also did a few gigs on character modeling, handpainted texturing, rigging & animation (way back in the days).

@@ghislaingirardot I just meant that I was missing you making your content back in a days :)

@@andreik8885 Ah, oops :p

That's likely unrelated to the bones/physics bodies. I'm sure it has to do with your skeletal component's collision settings

@ghislaingirardot ok thanks

No reasons. Just showcasing different ways to do things. Pick the solution you prefer. DF sampling has a cost, but it's probably not measurable for a few dozens particles

DF sampling is also not as reliable as prebaked positions from complex line traced for reasons I explained (poor DF resolution, DF samples the ceiling surface at first so you need to reject false positive). It's just two different ways of doing things and pros & cons are not just about performance here. Plus, got to think outside the box and see what kind of things you could do with prebaked data. Water drips isn't the most exciting choice.

yup, that's another limitation with DF and the pros of prebaking data. DF is view dependent and breaks at a distance. I don't think I mentionned it in the video though, I should have.

Ty for your feedback! The sky's the limit 😁

I will revisit this and make a breakdown at some point.

Not sure what you mean, sorry

Ty! RTS-like FoW most often don't support obstacle. It's doable though