jannisx11 / snowstorm Goto Github PK
View Code? Open in Web Editor NEWMinecraft Bedrock Particle Generator
Home Page: https://snowstorm.app
License: GNU General Public License v3.0
Minecraft Bedrock Particle Generator
Home Page: https://snowstorm.app
License: GNU General Public License v3.0
Like Blockbench is it possible to make Snowstorm accessible offline
Before opening snowstorm:
{
"format_version": "1.10.0",
"particle_effect": {
"description": {
"identifier": "sirlich:tile",
"basic_render_parameters": {
"material": "particles_opaque",
"texture": "textures/particles/tile"
}
},
"components": {
"minecraft:emitter_rate_instant": {
"num_particles": 1
},
"minecraft:emitter_lifetime_once": {
"active_time": 1
},
"minecraft:emitter_shape_point": {},
"minecraft:particle_lifetime_expression": {
"max_lifetime": 1
},
"minecraft:particle_initial_speed": 2,
"minecraft:particle_appearance_billboard": {
"size": [0.2, 0.2],
"facing_camera_mode": "direction_y",
"direction": {
"mode": "custom",
"custom_direction": [1, 0, 0]
},
"uv": {
"texture_width": 2,
"texture_height": 1,
"uv": [0, 0],
"uv_size": [1, 1]
}
},
"minecraft:particle_appearance_tinting": {
"color": [1, 1, 1, 1]
}
}
}
}
After opening snowstorm:
{
"format_version": "1.10.0",
"particle_effect": {
"description": {
"identifier": "sirlich:tile",
"basic_render_parameters": {
"material": "particles_opaque",
"texture": "textures/particles/tile"
}
},
"components": {
"minecraft:emitter_rate_instant": {
"num_particles": 1
},
"minecraft:emitter_lifetime_once": {
"active_time": 1
},
"minecraft:emitter_shape_point": {},
"minecraft:particle_lifetime_expression": {
"max_lifetime": 1
},
"minecraft:particle_initial_speed": 2,
"minecraft:particle_appearance_billboard": {
"size": [0.2, 0.2],
"facing_camera_mode": "direction_y",
"direction": {
"mode": "custom",
"custom_direction": [1, 0, 0]
},
"uv": {
"texture_width": 2,
"texture_height": 1,
"uv": [0, 0],
"uv_size": [1, 1]
}
},
"minecraft:particle_appearance_tinting": {
"color": [1, 1, 1, 1]
}
}
}
}
While working with the Spawn Shape "Box" it would be useful to have a toggle to display/hide the actual Box Shape/Square in the preview.
Snowstor variant: VS Code
Description:
Parametric functions on the rotation aren't saved in Snowstor VS code. The rotation mode in the saved file is brounght automatically to Dynamic.
Snowstorm cannot recognize texture .tga
Notifies about issues with the particle effect in real time. Shows small warning icon in bottom bar that extends into dialog
The Import feature does not work. You click import, and navigate to the particle file. Upon opening it, nothing changes and nothing is imported.
Particle JSON:
{
"format_version": "1.10.0",
"particle_effect": {
"description": {
"identifier": "hf:jet_ski_jet",
"basic_render_parameters": {
"material": "particles_alpha",
"texture": "textures/particle/particles"
}
},
"components": {
"minecraft:emitter_local_space": {
"position": true,
"rotation": true
},
"minecraft:emitter_rate_steady": {
"spawn_rate": 100,
"max_particles": 500
},
"minecraft:emitter_lifetime_looping": {
"active_time": 1
},
"minecraft:emitter_shape_point": {},
"minecraft:particle_lifetime_expression": {
"max_lifetime": 2
},
"minecraft:particle_initial_speed": 0.5,
"minecraft:particle_motion_dynamic": {
"linear_acceleration": [
"query.log(query.modified_move_speed)",
"50*query.modified_move_speed*Math.sin(150+(variable.particle_age*70))",
3
]
},
"minecraft:particle_appearance_billboard": {
"size": [
0.1,
0.1
],
"facing_camera_mode": "lookat_xyz",
"uv": {
"texture_width": 128,
"texture_height": 128,
"uv": [
0,
16
],
"uv_size": [
8,
8
]
}
}
}
}
}
Snowstorm is a great tool that I use to preview the particles, however I prefer to write them as code. I usually have a spit screen with code on the one side and Snowstorm on the other side. A shortcut that lets hide Snowstorm's sidebar would greatly improve my workflow by making the preview bigger and removing the part of the screen that I don't use anyway.
An additional config option to make the .particle.json
files open in code editor by default would also be very helpful for people, whose primary interaction with these files is in the code editor.
EDIT:
I found an option in VS Code that lets you change the default editor."workbench.editorAssociations": { "*.particle.json": "default" // Overwrite x11.snowstorm },
You can still open Snowstorm editor by using
CTRL+P
->>View: Toggle Editor Type
option while having*.particle.json
file open. So adding this feature to Snowstrom configuration would be redundant.
Addition of these features would enable following workflow:
That would be useful for particles making use of queries.
To give an example, currently when a particle uses "!q.is_sneaking" in its Kill Expression, it will return true and immediately kill the particle, forcing you to temporarily change out the kill expression to preview the particle system.
Snowstor variant: VS Code
Description:
Clicking on the View Code button, VS code will split the screen opening a new instance of the same particle without showing you the actual code
As much as I love this plugin on VS Code, whenever I try to make particles and edit the input fields or modify the particle, it always interrupts and goes to the end of the text or makes actions on its own. It's greatly affecting user experience.
This video footage shows how quite frustrating it is to modify the Color & Light
appearance of the particle. You would have to be quick about your actions otherwise the plugin would just interrupt and try to correct your mistakes even though you haven't finished inputting your stuff yet:
You can perhaps make a toggle that would control the rate of these "auto-actions" - or perhaps even disable it completely and return errors for the particles like you would normally do as "warnings" (as displayed on the image below), instead of interrupting the user's input forcefully.
Please reply to this post should you seek or have further information.
Snowstor variant: VS Code
Description:
If a particle is renamed removing the .particle
(or just the in between dot) to the name of the particle it will make that particle file unreadable for the plugin even if .particle
is readded.
eg.
If the particle rain.particle.json
is renamed in the following order
rain.particle.json>rain.json>rain.particle.json
the particle won't be opened with the snowstorm plugin.
This also affects renaming older particles with names not ending for .particle.json
Repro steps:
Expected result: The mode stays on Expression
Actual result: The mode switches back to Time
Note: This only happens if Time is set to anything non-zero.
Related: If both time and expression are 0, next time the file is opened it defaults to Time 1
The horizontal range is being taken into account when a curve is in Bezier Chain mode. This is however not the case in-game, and it's mentioned in the documentation. It also mentions that the range field is deprecated.
https://bedrock.dev/docs/stable/Particles#Curves
In a molang expression 0.5f
should be allowed. See the endrod particle
I like this software very much. Can we provide I18N interface for community members to translate into their own language? I think it's very helpful for the promotion of this app.
When using builtin particle variables, such as variable.particle_age
, Snowstorm will not properly evaluate the variable unless it is entered using the full name, variable.particle_age
. The standard shorthand v.particle_age
is not properly evaluated.
variable.<builtin>
into any field that would produce a visual change, such as directionv.<builtin>
Tested in both the web version and VSCode extension
Platform: Android
Browser: Chrome for Android (Version 84.0.4147.89)
I experience a great frame rate drop when the 'Grid View' is enabled. However, the grid view is pretty useful to be disabled in my use case. I thought that this may be a bug as I've been using it lately on Android.
It only does it on Android, since I have tested the Grid View on a Chrome running on Windows 10 and I have found no issues at all.
Thank you for reading, and hope this to be fixed!
(Also, I would like to suggest a mobile-friendly view and a proper UV mapper for convenience similar to Blockbench.)
When using look at direction, the specified custom direction does not end up in the exported JSON file.
Whenever a particle is saved with Expression mode for color, it wraps the expression with Math.clamp(, 0, 1)
, even if that expression is made up of several expressions and a return statement, causing a syntax error. It should only wrap the return value, not the entire field.
Example (in the Red field of the color expression):
v.index = Math.mod((v.index ?? -1) + 1, 10); return v.index / 10;
After saving:
Math.clamp(v.index = Math.mod((v.index ?? -1) + 1, 10); return v.index / 10;, 0, 1)
Expected:
v.index = Math.mod((v.index ?? -1) + 1, 10); return Math.clamp(v.index / 10, 0, 1);
(or no change at all)
I have made an uv based upon a random value.
but snowstorm keeps adding 0.5 * (2 *
to the value.
"minecraft:particle_appearance_billboard": {
"size": ["0.05*variable.size", "0.1*variable.size"],
"facing_camera_mode": "lookat_y",
"uv": {
"texture_width": 8,
"texture_height": 8,
"uv": [
"0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (0.5 * (2 * (math.floor(variable.particle_random_1 * 2) * 4))))))))))))))))))",
0
],
"uv_size": [4, 8]
}
},
I spend 2 hours trying to run it but you cant put * into files for some reason and .particle.json dosent work
The community currently has no great accessible options for visual particle editors for Java edition; this is probably an expected and inevitable suggestion, but support for particles in a Minecraft Java Edition-readable format would be immensely appreciated. The incredible work done on Snowstorm (as well as 1.19 Java animation compatibility in Blockbench via plugin) gives me hope that this is possible. Thanks a bunch!
When you try typing anything into the expression bar while any of the tick variables or start variables are being edited, all of the variables from the same category (if you edit a variable from tick variables, all Tick variables will be removed, and same with Start variables) will be wiped out.
It can be reproduced by creating one or more variables in tick or start variables, input anything in there, then focus to expression bar and input any character. After that all variables in the same category will be removed.
P.S.: I saw the message in #bb-feedback, so I thought I would report here as well.
The minecraft:particle_lifetime_expression
component can be left empty to make a particle live indefinitely
https://bedrock.dev/docs/stable/Particles#Particle%20Lifetime%20Expression%20component
But when opening a particle system with no "max_lifetime" in Snowstorm, this component is automatically filled with max_lifetime": 1
(in the Snowstorm UI, it's "Max Age", under "Lifetime")
Putting "0" for the "Max Age" of the particle currently works to leave minecraft:particle_lifetime_expression
empty, having that instead of 1 would work to fix this issue. Something more explicit could be nice, since a lifetime of 0 is unintuitive for beginners
I don't know whether you're actively support mobile version, but I noticed a couple of bugs regarding mobile and math expression fields, so here is my report:
Whenever you do an autocomplete, when you click on the suggestion it will have an extra character in the beginning. So if you've typed v.em
and then I click on emitter_age
, it would insert v.eemitter_age
.
When field's math expression becomes longer than its width, it starts bugging out in sense of:
math.sin(v.emitter_age) * (v.part|icle_random_1 * 0.5 + 0.5)
where |
is the cursor.overflow: hidden;
.These bugs occurred to me on iOS 16.3.1.
I can't find any documentation on how this extension works. When I open a particles.json file, it just opens in VScode. When I open the extension from the Extensions panel, it just shows me basic readme information, which has led me here, but I don't see any info how this extension is activated.
Hello ๐ I'm from the VS Code team.
Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.
We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace. Custom editors are special in that if they cannot at least render in an untrusted state then they will be replaced by a lightweight message telling the user to enable trust. This means that users of your extension will not be able to see their editors and there may even be cases of data loss.
You can enable the feature with the following setting security.workspace.trust.enabled
. Once enabled, you will see the following dialog when opening folders in VS Code.
This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt
.
You can follow the development of Workspace Trust and provide feedback in issue #106488.
First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.
The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.
You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces
capability in package.json
.
The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.
"capabilities": {
"untrustedWorkspaces": {
"supported": true
}
}
The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.
"capabilities": {
"untrustedWorkspaces": {
"supported": false
}
}
The third option is to declared limited
support. There are three tools provided to you when you select the limited
option.
First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations
array property in untrustedWorkspaces
object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.
The following example declares the settings that are restricted in untrusted workspaces.
"capabilities": {
"untrustedWorkspaces": {
"supported": "limited",
"restrictedConfigurations": [
"markdown.styles"
]
}
}
Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:
export namespace workspace {
/**
* When true, the user has explicitly trusted the contents of the workspace.
*/
export const isTrusted: boolean;
/**
* Event that fires when the current workspace has been trusted.
*/
export const onDidGrantWorkspaceTrust: Event<void>;
}
Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted
context key in your when clauses.
A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.
We are planning on enabling this by default in the near future (most likely next release). To prepare for that day, we want to work with you to allow your editor to work seamlessly alongside the trusted workspace experience
The main features that should work for custom editors in an untrusted folder is rendering, viewing, and saving (if applicable). After reviewing your codebase, I believe that your extension doesn't rely on user contents in a way that could be taken advantage of if the files were malicious. My initial assessment would be to adopt supported:true
and allow your extension to operate in untrusted workspaces.
Please let me know if you have any question or would like to meet up via voice chat as I would be happy to assist you in getting your extension ready for workspace trust!
I'm on windows 10, the most recent chrome browser, and no extensions applied. I cannot select or copy any of the code, no matter what I try!
If you open up a particle with vscode, all of snowstorm's option fields are set to default values.
I tested the following expressions and some variations, I assume all alternative molang expressions behave the same
v.curve * molang expression
returns 0
molang expression * v.curve
works correctly
molang expression * v.curve * v.curve
returns 0
molang expression * v.curve * molang expression
returns 0
Minimal JSON to reproduce:
The particle should flash between square and rectangular every half second, but it stays square.
{
"format_version": "1.10.0",
"particle_effect": {
"description": {
"identifier": "test:operator_equals",
"basic_render_parameters": {
"material": "particles_alpha",
"texture": "textures/blocks/wool_colored_white"
}
},
"components": {
"minecraft:emitter_rate_steady": {
"spawn_rate": 1,
"max_particles": 100
},
"minecraft:emitter_lifetime_looping": {
"active_time": 1
},
"minecraft:emitter_shape_point": {},
"minecraft:particle_lifetime_expression": {
"max_lifetime": 1
},
"minecraft:particle_initial_speed": 0,
"minecraft:particle_motion_dynamic": {},
"minecraft:particle_appearance_billboard": {
"size": ["v.particle_age >= 0.5 ? 2 : 1", 0.2],
"facing_camera_mode": "rotate_xyz",
"uv": {
"texture_width": 16,
"texture_height": 16,
"uv": [0, 0],
"uv_size": [1, 1]
}
}
}
}
}
It would be nice to have some default values for curves and gradients.
For curves: it would be nice to have variable.
filled into name, variable.particle_age
into Input, and variable.particle_lifetime
into Range.
For gradients: it would be nice to have variable.particle_age / variable.particle_lifetime
as default Interpolant, and 1
for Range.
That's my personal suggestion (as in not objective), I don't know about how other people use curves and gradients, but for me, whenever I use them, I always base off my particle effects off these values. Anyways, it's just a minor suggestion. Thank you for attention!
When making a particle and setting facing_camera_mode: "direction_z"
, it renders Y direction incorrectly.
For particle with those components:
"minecraft:particle_motion_parametric": {
"direction": [0, 1, 0]
},
"minecraft:particle_appearance_billboard": {
"size": [0.5, 0.5],
"facing_camera_mode": "direction_z",
"uv": {
"texture_width": 128,
"texture_height": 128,
"uv": [0, 0],
"uv_size": [128, 128]
}
}
The particles are visible when looking from the top, but when the same particle is created in Minecraft, it's visible only from the bottom. This causes me to always have to negate Y direction before using particles in Minecraft.
Sidenote: It may be very well Minecraft bug, because the way snowstorm renders it feels more correct, but it's like that in 1.16 and 1.17, so I don't see it fixed any time soon.
Not exactly sure how to describe this accurately, so I will just provide steps to reproduce the bug:
other possible results are:
inserting the name of an existing variable or molang querey / function
inserting a seemingly random character
This appears to be an autocomplete problem
A suggestion here: the ability to preview multiple particle effects at once would be an incredible addition, and could be helpful in allowing users to create some elaborate multi-part effects.
After importing knockback_roar.json
vanilla particle, I noticed, that it uses minecraft:particle_initial_speed
component with an array as a value to define separate speeds for each axis. Snowstorm completely ignored that and instead treated those values as a direction.
Example from knockback_roar.json
"minecraft:particle_initial_speed": [ "15 * Math.random(-1.0, 1.0)", "15 * Math.random(-1.0, 1.0)", "15 * Math.random(-1.0, 1.0)" ],
For some reason, Snowstorm can't open JSON particle files that has some any form of comments inside it.
Steps to reproduce:
//
on any existing or new line.At first I thought maybe there was just a delay importing it but I believe this is what's causing the issue. I hope to get this fixed! Unless otherwise if this is intended, then please change it.
Cheers!
where should I put textures in project? the extension does not load textures I put in project
According to the documentation, there are the components
minecraft:particle_lifetime_events
minecraft:emitter_lifetime_events
as well as the option "events" in the "minecraft:particle_motion_collision".
As far as I can tell, these are not implemented in snowstorm so far, but are an extremely powerful tool to make more complex or timed particles, as they can fire sounds or other particles.
There are two options on how to include them:
Minimal Version: Give the user the option to input the respective parameters without displaying them
Best Version: execute particle events in snowstorm if the respective files exist in VSCode (not going to work for the web version)
Greetings,
Chris
window.screen.orientation && window.screen.orientation.type.includes('portrait') not working in safari ios => portrait_view not working.
-> Recommend using screen width or window.outerWidth
ios safari error: css hover not working -> menu not working
sample issue :https://stackoverflow.com/questions/35187970/css-hover-not-working-on-ios-safari-and-chrome
-> Recommend add @click="" to <li v-for="menu in Menu" :key="menu.id">
-> <li v-for="menu in Menu" :key="menu.id" @click="">
@JannisX11
When using material particles_alpha, snowstorm still renders semi-transparency, when it should be either opaque or transparent completely. Due to this, I often forget to change the material before checking it in Minecraft, and wonder why particles don't show up.
Version: 2.3.2 in VSCode
Having an emitter with zero particles can be useful, for example a particle whose only purpose is to run a timeline of events that spawn other particles.
However, when "amount" is set to 0 in snowstorm, the num_particles
field is left out instead of being saved as 0. If the file initially had this field when being loaded, it gets deleted.
This causes a content log error in-game:
[Effects][error]-particles/test.particle.json | ParticleEffect::_extractComponents | minecraft:emitter_rate_instant | EmitterRateInstantComponent | num_particles | required field does not exist
Here is my reference particle:
{
"format_version": "1.10.0",
"particle_effect": {
"description": {
"identifier": "test:particle",
"basic_render_parameters": {
"material": "particles_alpha",
"texture": "textures/items/apple"
}
},
"events": {
"event": {
"particle_effect": {
"effect": "minecraft:endrod",
"type": "particle"
}
}
},
"components": {
"minecraft:emitter_rate_instant": {
"num_particles": 0
},
"minecraft:emitter_lifetime_once": {
"active_time": 2
},
"minecraft:emitter_lifetime_events": {
"timeline": {
"0.00": "event",
"0.50": "event",
"1.00": "event",
"1.50": "event",
"2.00": "event",
"2.50": "event",
"3.00": "event",
"3.50": "event"
}
},
"minecraft:emitter_shape_point": {
"direction": [0, 0, 1]
},
"minecraft:particle_lifetime_expression": {
"max_lifetime": 1
},
"minecraft:particle_appearance_billboard": {
"size": [0.25, 0.25],
"facing_camera_mode": "lookat_xyz",
"uv": {
"texture_width": 16,
"texture_height": 16,
"uv": [0, 0],
"uv_size": [16, 16]
}
}
}
}
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.