Weather and Effects Spawning

[TheDuckCow]

This is a feature request and progress tracker for a general purpose effects spawner. The user goals of this are to:

• Enable the user to more quickly add common special effects
• Complement the existing MCprep features without duplication or overlap (e.g. not a rebranding of meshswap spawning or mob spawning)
• Be flexible enough for individuals to customize the individual effects within the same "family type".

Currently, the idea of the categories of effects fall into these buckets:

• Persistent weather/environment effects
  • Goal: Auto create particle systems which should be consistently enabled throughout a scene. At the moment, these are all thought of as particle systems. When added to a scene, they should be placed initially respecting the camera position (if rain), or the objects selected (e.g to drip off the top or spawn from the top of selected mesh objects)
  • Examples: Rain, lava effects, dripping effects, rising bubbles, sifting sand
• Point in time non-particle effects
  • Goal: Create effects that are not particles and are point in time. Thus, they would be added to the scene in a way where they are keyframed to appear on a frame, and either naturally disappear or be keyframed to disappear sometime later.
  • Example: Randomized lightning strikes, TNT which explodes some amount of time later, block or glass shattering (could take in a single object as an input and create the effects/modifiers), sword sweep (ideally with input on start/end frame for swoop based on selected point)
• Point in time particle effects
  • Goal: Create short-term particle effects that are added at the cursors location and last a short period of time. These are ideally leveraging the active resource pack's textures for things like animated actions of sword sweeps, bubbles, etc. Could be implemented to auto detect the family of particle effects in the active resource pack and spawn those as single or multiple particles of 2D planes (reuse materials where feasible).
  • Examples: Water splashes, spark/flint lighting, animated smoke puffs, animated vanilla explosion particle (2d), vanilla sword swoop (2d), short "dust clouds" (e.g. to place under foot steps), some presets like post-jump ground impact (possibly based on initially selected blocks to use as input).

[TheDuckCow]

On the issue of how to initially place large-area effects like rain/snow, consider having the operator have a modal placement similar to default primitive objects, or a redo last option for size and location.

[lil-cristal]

Do you mean that you will add weather effects like snaow, rait etc to mcprep pls do it will be very helpful

[TheDuckCow]

Yes this is correct! Snow and rain are in scope for this feature. Just an FYI, this is in feature request mode only, development has started and I don't have a specific ETA.

[lil-cristal]

The most useful part of it is the rain and snow effect maybe i think that's particle system and not everyone knows about pparticle system maybe u can just make it a premade .blend file with rain and snow particles.

[Kabinet0]

So It works kind of just like meshswap, but spawns a rain emitter?

[lil-cristal]

yes thats ow it should work, i know how to do it, but for other people who dont know

[th3pooka]

Here is a potential weather system using geometry nodes. Download and try this out.
https://drive.google.com/file/d/1y6XFeeK-VHTHFaKYrz_8MMt0XIpOpi8P/view?usp=sharing
There are 2 nodes set up to work with each other. The first is a single area snow node that can move its instanced points along a chaotic path to move like snow. This can be tweaked to work with all sorts of particle systems like rain, smoke, leafy wind, smoke, and fire flies.
the second node set up takes the first one and copies it across any size area on the x-y directions (z would be determined by how far the "snow" falls in the first) by coping the first node in a grid pattern of the exact same size as the first, we can tell this grid to move IN a grid pattern so there is no perception that the weather is even moving.
I realize that i'm not the best a explaining this part, that you have 4 cubes in a row that are exatly the same. if you can only see the middle 2, but then moved the whole row the length of 1 cube either direction, you would see no movement in the cubes. I take that concept and can create a weather system that can move without it perceiving that it is moved.

So i can work off several paramotors. the size of the single weather system can be adjusted. This size will determine the scaling of the second grid system. The second grid system can be adjusted to any size on the x-y. This second grid system can be attached to an active camera or an empty in front of the camera. but then the particals need to make sure they face to the camera, but that can be set up in the first node system to have the rotation of the instanced object to always follow the camera's view.

[th3pooka]

Upgraded the weather system to now include an "all in one weather system" this save will have an area from minecraft imported so there can be a comparison to how much area you'll need for the weather to cover. https://drive.google.com/file/d/1cp8SbwlIsbqx2WqwliU0mpDId7zs98xZ/view?usp=sharing
also here is a video to watch that will explain things that are going on.
https://drive.google.com/file/d/10zDZ27-dQxlaup3I_GhyEd0Ps-aXU3AP/view?usp=sharing
Also with the new all in one system, if a Realize instances is added at the end, a normal boolian can be added after the geo nodes and remove weather inside a building.

[TheDuckCow]

Thanks a million, and very nice and thorough video! Having watched through the whole thing, I have some questions:

1. Really loved the fast boolean use case - but as you mention, losing UV layouts is a toughie. Is this something that just isn't possible, or is there a way that would just require more node work to bring back UV data? (maybe if we can assume UVs are setup in a standard sort of way).
2. Between the "old" and the "new" system, does one have better performance than the other?
3. Sorry if I missed this, but are there other specific quicks in one vs the other that would make one more useable than the other? (other than there being potentially some solvable way to make booleans work on the old system)
4. Do you think adding automatic vertical tiling is a solvable problem?
5. Not a question, I just loooove the snow fluttering in the air at 8:40, so nice!

My goal in these questions is to see which single node group we can go with. It's already going to be a power feature, and so I want to simplify it as much as possible and not having the user decide what variant of node groups to go with.

Remember that MCprep will be designed to do most of the heavy lifting for users - regardless of the node group type used, a user will be pressing a button like "Add rain" or "Add snow". It would then set up the according node group (whether we go with old or new) and default the settings to something fitting for that weather type. In practice, I don't see it being a common need to cycle from one weather type to the next, it would be faster for the user to just press add new weather type for the one they want. I also see the old setup makes it easy for someone to plug in a custom shape if they want (if I understood that right), which would be a big value add for [semi] power users.

Let me know your thoughts on this! Truly brilliant work making it here. For anyone else reading, Pooka has overcome a huge number of challenges to make this work so stable and without flickering during camera movement.

[th3pooka]

I think I got some answers for you.

1. To get the Boolean to work I have to send it threw the "Realize Instance" node. This node works like the 'apply' function on the modifies. And after you hit 'apply' the UV for the object is changed. So instead instancing a bunch of objects that h have their own UV's, the nodes try to take on those materials in the new objects UV.
   so in short, I'm not sure Boolean'ed weather and UV weather will work. luckily single color rain drops (even if its a different color per rain drop) will work. Luckily I got the Boolean to work with the old node set up too!

2. In terms of performance, no difference. One option will have all the controls in one GeoNode, its a tad difficult to add in new weather for anyone that doesn't know what they are doing. The other option the weather can save settings between types of weather, and is a little easier to set up a new weather type for new users. But to change the settings of the weather to move faster, slower, larger, you have to jump between the objects that working together.

3. Woops, i think i already answered these in the previous questions. but the differences between the two are primarily in answer 2. There is now no difference in the ability to work with Booleans now too.

4. AUTO Vertical is something that not easily solvable. I'm sure there is a solution, but i found the easiest solution is to litteraly add an Array modifier after the geonodes, and have them over lap a little. So i set the Z to be 0.8 or -0.8 and that got me the easiest Z for the weather. OR you can adjust the spread of weather in the Z direction and adjust the time to work with the new height, but this method was more complicated than the Array modifier.

5. Thank you <3

In a bit i'll add another comment to address the other thing in this Issue, the Explotions. I have something you might want for that. there is an explotion of i'm using from GeoNodes that might work with what you want. I'll go more into detail later, but the Explotion GeoNode is in this save some were. I'll make a specific save for it later. https://drive.google.com/file/d/1N-Yh_frMmyHEVwi0RZc6Y_t4tzom6L4g/view

[th3pooka]

I got a save up for the explosion. This guy is just a place anywhere, rotate, and move the key frames to get your explosion. Here is a video showing what it can do. What i would like to know is what else should i attempt to make this set up do? the only thing I can think of is adding a tnt block in that blinks and then the explosion happens.
Save - Explotion Blender Save
Video - Explanation video

[TheDuckCow]

I've started thinking through the code structure for this feature. The branch is here, though nothing pushed yet.

Some initial thoughts and options around UI layout and user flow for these features (these are all just mockups, no code actually written yet, and very open for feedback):

1. Have one overall UI list of all effects available
   • One UI list, perhaps with different icons for the “kind” of effect, added as another "Effects Spawner" subpanel in the spawner area of MCprep.
   • There could also be a category dropdown so you can easy filter for "wide area particle effects" (ie these geonodes that the3pooka has been working on) vs texture particles (populated from the resource pack particles folder)
   • Pros: Searchable list, consistent user experience with the other spawners. Fast to spawn the same effect multiple times (e.g. if you want a number of "footfall" effects) as you just press one button "spawn".
   • Con: Most users won’t get the nuance of the different “types” of effects, though filtering can help. Also, unclear how best to support point effect from texture files (do we flood the UI list with all loaded possible textures? Or is there another button below for spawning from file, so it lives outside the typical UI list anyways?)

2. Have one button for each type of effect, and then a popup to decide which to specific variant to spawn
   • The different buttons would be: "Weather/wide area", "Non-particle/Collection-animated" (what's a better name?), "Particle texture/Splash-footstep" (ie the one where it reads from a texture, creates a few subplanes and then spawns the planes at a moment in time such as a foot-fall)
   • Pros: More intent-driven, as you are first thinking of the kind of effect you want to spawn
   • Cons: You can't search for effects across all of them, and it takes an extra click (popup + confirm which effect), making it slow to add many instances of the same effect.

[Roni-Raihan]

I'm new to this topic and I'm not an expert. In my personal opinion, I liked the first UI idea. But, I don't understand what is meant by point effect from texture file (maybe because I mistranslated it, I'm not very proficient in English)

But if my understanding is correct, I thought it might be good to flood the UI with possible point effect textures loaded, but complete the category dropdown by adding a "point effect" option to make filtering easier

[StandingPadAnimations]

I think option 2 is the best. It's simple but explicit, and avoids tons of confusion.

[StandingPadAnimations]

However, we could make it a boolean property, and when checked it brings up a larger panel. That's how the advanced options work in the main panel

[TheDuckCow]

Hmm, I want to avoid having multiple different ways of displaying the UI as I'd rather focus on a good singular user experience, otherwise the overall MCprep UI would turn into a hodgepodge of configurable UI layouts.

Currently I am leaning towards the option which is based on "intent". I suppose another option is "both", where the expanded UI list itself is underneath in the "advanced settings" section? I don't actually even have plans for what would be in the advanced settings panel, other than the quick selection of a resource pack.

@Roni-Raihan thanks for sharing that the "point effect" is not clear, that is very helpful - if it's not clear for you, then others would likely experience the same. What I meant to write is actually "Plane particles", the idea being you can a particle system similar to when you run on land, or landing on the ground after a tall jump, or even when you break a block and some cut up pieces of the texture you just break momentarily appear and fall down and disappear. The idea is that you would select this "Particle Plane from Image" button, and then enter into a filebrowser where you pick or filter for the specific particle image you want to use for the effect. Maybe it performs a shortcut where if you have a block selected, it defaults to selecting the diffuse image of the first material of the object you have selected (so if you select a sand block, it would initially be assigned to the sand texture, but you could still select another texture if you wanted).

Let me know if that's clear - and generally any other thoughts you both have in terms of features and functionality that is commonly time consuming in this area!

[th3pooka]

I like option 2 as well, I feel like the separation of how each system works will intuitively tell how to manipulate the effect.

[th3pooka]

Also i've been fiddling with the effects trying to figure out a way to make it easier for you to spawn them in. Is there anything I should focus on to help out while your working on the code-thingy-stuff? One of the things i'm trying to remove is the need to have an outside collection of objects. Instead I'm trying to create the partials shape from just the images them selves. Right now i have the "small smoke" partials all shaping out from a single image, and changing its shape depending on the alpha level of the image.

[Roni-Raihan]

Thanks to @TheDuckCow for the explanation. I can understand very well now. also, being that way, I think option number 2 is better. as it overwhelms with possible loaded textures it might have too many and make it difficult for the user to focus even if filters help

[TheDuckCow]

One of the things i'm trying to remove is the need to have an outside collection of objects. Instead I'm trying to create the partials shape from just the images them selves.

@th3pooka is this generating the images with cutouts using geometry nodes, or using the "Item spawner" feature? If geo nodes... let me know :3 as that could be an extension for that code.

In terms of help right now, main thing I need to do is sit down and really focus on coding the base framework. Once I get to actually importing and parenting the camera to view, I'm sure some new things will crop up. Do let me know if there are ever any updates to the node layouts - and biggest thing, what version of blender did you use to create the most recent weather effects geonodes?

[th3pooka]

@th3pooka is this generating the images with cutouts using geometry nodes, or using the "Item spawner" feature? If geo nodes... let me know :3 as that could be an extension for that code.

It's using the alpha levels of the image to determine which smoke image is next, since that Minecraft smoke can be layered within each other. and that's what it makes the mesh out of threw geometry nodes. I tried doing this with the explosion circles, but they don't stack perfectly. But i did get rid of the need for exterior objects for the explosion to instance from.

i'm not sure what you mean by 'an extention of that code' I will have to talk to you more about that later.

I'm currently using blender 3.1, I will see about updating the weather to use less outside instancing and more internal geonode mesh generation. and making the node set up more universal amongst all the weather nodes.

[StandingPadAnimations]

I think there should be an option for reducing viewport density but keeping render density perfectly fine. I believe starting from 2.93 or 3.0, it's possible to make a node group that does this. I'll send a screenshot of the node group when I get the chance

[TheDuckCow]

Really liking that idea StandingPadAnimations! Will have to think how we can do that, is there a way in geo nodes to detect if it's a viewport vs full render?

In other news, here's the first pass of end to end effects loading:
https://twitter.com/TheDuckCow/status/1529300377086091267

You can see I went with the other UI, but that could change still (or, the list view could be under preferences for instance).

I've tried to make the code generalized, which means it's looking for all node groups inside the new /effects/geonodes/ folder. But this also means I need to find a way a way to generalize certain things:

• Tell MCprep which node groups to skip. When using library loading, we can't actually look at properties of a data entity (like nodegroups) without first importing it, we only have the name. Which means there's no differentiation between scene nodes and geometry nodes as I understand. For this, we reuse the same convention of adding "mcskip" to the nodegroup name if it's not relevant to show in the effects dropdown.
• Define for MCprep what configurations of node settings correspond to which weather effects. This will likely be unique to Pooka's nodegroup, since it has a slider for the different weather types. Again since we can't read the blend file until after it's been loaded, this likely needs to be an adjacent json that describes the replacement names and settings for each of the nodegroups, sort of overriding directly importing and using a group as is.

[StandingPadAnimations]

Really liking that idea StandingPadAnimations! Will have to think how we can do that, is there a way in geo nodes to detect if it's a viewport vs full render?

I believe starting in 2.93 there's the "Is Viewport" node

[TheDuckCow]

Progress is going well! I figure it's worth sharing a few of the demos I've been showing off as development continues:

• Animated collection, example effect
• Image sequence particle spawning
• Particle-based, wide area weather
• Geo-node-based, wide area weather
• Particle planes feature

[TheDuckCow]

While I haven't implemented every possible type of effect, the code is there and we could get community contributions over time to expand it. Pending an optional code review, will merge and close issue soon.

[StandingPadAnimations]

Just finished the code review

[TheDuckCow]

Closing this as the features are all implemented! Perhaps will make a community challenge around creating more effects templates for people to use.