Isn't this just a bug with the water shader? I'm pretty sure the same thing happens to metal icons and maybe even unit icons (not 100% sure about unit icons though) EDIT: Actually, what type of effect are you trying to get in the first place?
A mesh particle with additive blending that isn't rendered on top of everything else? Not all particles suffer the same consequences. I think what i am after is something with additive blending, but that doesn't have the transparent flag set.
Well I mean what are you using a spherical mesh for? Also there might be a way to add more shaders but particle.json is cryptic to me.
The water is not guaranteed to render over other transparent effects, even if something is underwater or on the other side of the planet, those effects can render over the water. Effects on other planets may render behind water, but not guaranteed either. Sorting transparencies in real time rendering is hard (ie: either grossly inaccurate or really, really slow). Unit icons and metal spots are different, they get rendered in a completely separate pass that has no knowledge of what's in the scene. It'll happy render icons on the backside of the planet by editing particle_common.vs and making isIconOccluded() always return true; it's just getting the default planet size and faking occlusion if the planet was a perfect sphere.
Alright, I understand the transparency issue, I actually expected that to be the reason why I was having trouble. So the next question is, is there a non-transparent mesh particle effect that offers additive blending or at least allows me to make it really bright?
meshParticle_color You do need a "materialParameters": { "DiffuseTexture": "something.papa" } for it to work though. I suggest flat.papa. It is an opaque mesh that will sort properly and you can make really bright. Additive blending is, by definition, a transparent effect.
Thank you! Trying this now. EDIT: It works, but you need to put the color values up way higher than normal to get the same glowy effect xD.
Yeap. With transparent or additive blending, 10.0 or so is enough to make it glowy. For the meshParticle_color though I had to put it up to 10000.0 xD
It's actually because meshParticle_color is lit. On the day side of a planet that effect is going to be super bright, and on the dark side you have to crank it up a bunch to get it to match a transparent effect since that isn't lit. Basically there's no good effect that is both solid and takes a color.
Ahh okay that makes sense now. Just to confirm, it should be possible for me to make my own entries in the particle.json and have my own shades right?
Yes, though the way mods work (ie: overwrite rather than append) could cause issues with other mods or updates.
AKA As long as I am the only one who does it it's fine?? xD In any-case, I use json-patches to define my mods, so I don't have to worry about any updates at least
Hello! So I've been looking at some of the new effects, and it seems like there are indeed some new keys! Two I have found so far: emitters[].spec.rgb emitters[].spec.rotationRateMult rgb, seems to involve colors, [a, b, [values]], where values are actual 0-255 color values. I still haven't worked out what a and b are supposed to be. EDIT: WAIT A MINUTE, is this for defining a distribution for randomly choosing the color????? ? EDIT2: Okay no that doesn't seem right. Is it maybe the colors for each corner or something? rotationRateMult, not sure what it does, but seems to be a plain time-curve here. Question, is the new entry in rgb a new specific format for rgb data, or is it a new way to specify time curve data?
Particle colors, red, green, blue, and alpha, are defined in linear float space. Artists are used to dealing with 24 bit gamma space colors. These are 0-255 numbers you'll see in every art program ever. The rgb key allows defining colors in this format. These gamma space colors are converted into 0.0 - 1.0 linear space curves for the user. The first number is the time, just like other curves, the second is a multiplier so that you can still do brightness values greater than just one. "rgb": [ [time, mult, [R, G, B, A]], [time, mult, [R, G, B, A]] ] Alternatively if you just want a single color you can do a single key with out time and with out the outer brackets. "rgb": [mult, [R, G, B, A]] Another alternative is you can leave out the alpha from the rgb curve and define it separately in the old style. I do this frequently when I want the color to be constant. "rgb": [1.5, [255, 97, 12]], "alpha": [[0.0, 1.0], [1.0, 0.0]] If an rgb curve exists the red, green, and blue curves are ignored, and the alpha curve is ignored if it's defined in the rgb curve. Internally these are just being translated into the same color curves that've always existed, but it's doing the color conversion for the user. RotationRateMult lets you slow down (or speed up) the rotation rate in particle time. Most common use is to make particles spin more slowly over time rather than at the rate they spawn at. I believe there are 3~4 other new features (most kind of minor) you haven't noticed yet.
New particle settings: rgb - Discussed in the above post. Alternative to setting red, green, blue and optionally alpha independently and using a more artist friendly color format. useRandomDir - Ignore velocity and axial settings for directional particle effects and instead assign a random direction on spawn. rotationRateMult - Multiply per tick particle rotationRate. New emitter settings: type - Additional shapes: torus (which you've already noticed), box_x, box_y, box_z, mesh. The box_ shapes act like cylinder_ but are rectangular instead of round. The mesh shape allows you to use a mesh to define the spawn shape. papa - Mesh file to use if using type: mesh. meshUniform - Calculate uniform distribution for particle spawning. By default the polygon that particles spawn from is chosen by random, so if the mesh has a non uniform density (small polygons and big polygons) the particle spawns will be clustered more in the areas of small polygons. This ensures equal spawn chance across the mesh. rgb - Discussed in the above post. Alternative to setting red, green, blue and optionally alpha independently and using a more artist friendly color format. emissionBursts - Added new key, chance, to bursts. 0.0 - 1.0 range. Also a new simple format (both of these are already documented in the file). sizeRandomFlip, sizeRandomFlipX, sizeRandomFlipY - Randomly flip the x and/or y size of the particle. Helps prevent particle "twinning". useShapeVelocityDir - Like useRadialVelocityDir, but is purely the direction from the shape unscaled and not offset. inheritedVelocity - Fraction of velocity to inherit from the parent emitter. 1.0 will add 100% of the velocity from the movement of the emitter to the particles' initial velocity.
Just wanted to get this in a sticky thread: As far as I can tell, this only works for core files, mod shadows are not watched.
Is there any ways to stop particle at surface? For example, I have some debris from explosion, can I make them not fly through planet surface?
