Self vs Other

Blends, Collision Effects, Particle Overrides, and Particle Sets all have control over a multiplier struct called ParticleMultipliers

• float countMultiplier
• float sizeMultiplier

However they are separated into 2 fields:

• ParticleMultipliers selfParticleMultipliers
• ParticleMultipliers otherParticleMultipliers

No matter where you find these fields, they all mean the same thing:

• "Self" -> The object querying/The colliding object
• "Other" -> The object being queried/The object being collided against

The difference is: Self is the object that is sampling the surface types of the other object.

• Collision Effects:
  • If A has a CollisionEffects component and B doesn't, then A is "self"
  • If both have CollisionEffects, then:
    • If A has a higher priority, then A is "self"; if B has a higher priority, then B is "self"
    • If they have the same priority, then it is "random" whether A or B will be "self" within a frame (and the other object being "other")
• Footsteps
  • The object creating footsteps is "self"
• GunShooter
  • GunShooter is "self"

You need to remember that "self" means the object that is testing for SurfaceTypes in the object "other", because you have the 2 multiplier fields in most of the Markers, and intuitively "self" feels like it should represent the object the Marker component is attached to, but it does not. "Other" is always the object being queried. "Self" is the object that is querying.

The object "other" needs to indicate what SurfaceType it represents; it needs a Marker or a valid Material name, otherwise it will just use the default SurfaceType.

Flipping

In ParticleSets and ParticleOverrides, you have control over the enum OriginType. The idea is that damage particles either are:

• Coming from "other".
• Coming from "self"
• Both

And by "damage" particles I mean shrapnel/fragments/smoke/feathers/sparks/etc.

When designing the prefab (using the SurfaceParticles component), the perspective is at the default: "other". You can easily just change the perspective using the rotationOffset if the perspective doesn't fit with "other" (You probably won't notice unless the ParticleSystem's shape module is "asymmetrical", such as a cone).

The ParticleSystem's shape module's rotation and position are controlled by SurfaceParticles, that's so I don't need to move the ParticleSystem's Transform itself.

The perspective matters, sparks are particles created FROM a metal ball striking stone. Stone particles are created FROM the stone being striked.

Giving control over the perspective allows you to properly use assymetrical ParticleSystem shapes if you want. It also means the size and count multipliers are applied only to the particles you want.

Texture Scaling Particles.shader

If you want to use the Texture Scaling Particles shader, you need custom vertex streams like the example particle systems show: Size (TEXCOORD0.z), StableRandom.x (TEXCOORD0.w). The size is used to scale the particles' detail and offset maps so it looks more detailed the bigger the particle. The StableRandom is used to (semi) randomly offset the detail and offset maps, so each particle looks a little different. I would recommend using the shader as an example for getting that sort of effect, and making a better one yourself in ShaderGraph (if you want proper lighting that is, since Surface Shaders don't allow custom uv data).