[pschlik]

A big update to particle emitters is now on unstable. This brings a bunch of changes that should make particle effects look much more interesting and less glitchy without the need to make any changes to engines or wagons, plus a ton of new customization options that can be applied to each emitter for loads more control than was previously available.

I think a quick comparison between the previous and new system does a lot of the talking here...

https://i.imgur.com/Cx4DT7l.jpeg

Hopefully it's clear that particles are now shot out with quite some speed and expand to fill space and make those puffy clouds we expect from steam locomotives. The new/old difference is far less extreme for diesel locomotives because diesel locomotive exhaust is calculated differently. (This change does very little to modify those calculations, so there's still room for improvement in exhaust simulation for both steam and diesel locomotives.)

I also recorded a YouTube video a short while back that does not reflect the current version exactly but still does well to depict how the forceful exhaust of steam looks when going at speed.



As for the new customization options, those can be added inside a special effects block like this:

	Effects (
		FX_TYPE (
			FX_NAME (
				0 4.75 2.0
				0 1 0
				0.15
				
				ORTSPositionVariation ( 0m 0m 0m )
				ORTSInitialVelocityVariation ( 0.1 0.1 0.1 )
				ORTSEmissionSpeedLimit ( 150m/s )
				ORTSFinalVelocity ( 0 1m/s 0 )
				ORTSFinalVelocityVariation ( 0.75m/s 0.75m/s 0.75m/s )

				ORTSLifespanMultiplier ( 1.0 )
				ORTSLifespanVariation ( 0.5 )
				ORTSMomentumMultiplier ( 1.0 )
				ORTSMomentumVariation ( 0.1 )

				ORTSInititalExpansion ( 1.0 )
				ORTSExpansionSpeed ( 4.0 )
				ORTSRotationVariation ( 0.25 )
				ORTSWindMultiplier ( 1.0 )
				
				ORTSPipeArea ( 0.018m^2 )
				ORTSMaxParticles ( 2500 )
				ORTSRateMultiplier ( 1.0 )
				ORTSUseChaoticRandomization ( false )

				ORTSGraphic ( "smokemain.ace" )
				ORTSGraphicAtlasLayout ( 4 4 )
			)
		)
	)

Note how the MSTS numbers giving the position, direction, and size of particle emitter come first; that is required. But, those numbers are confusing and can become disorganized, so it's better to replace those with new ORTS parameters that do the same thing:

	Effects (
		FX_TYPE (
			FX_NAME (
				ORTSPosition ( 0m 4.75m 2.0m )
				ORTSInitialVelocity ( 0 1 0 )
				ORTSParticleDiameter ( 0.15m )
		
				ORTSPositionVariation ( 0m 0m 0m )
				...etc...
			)
		)
	)

In this case, the order doesn't matter and it's easier to tell which numbers do which things. The description for each of these parameters can be found in the updates to the manual. But for some general notes, a lot of these controls are multipliers rather than absolute settings (so ORTSMomentumMultiplier ( 2 ) doesn't set the momenum to 2 seconds, it sets the momentum to twice whatever value is calculated by the system), so there's not going to be a magic 'correct' value. All the parameters relating to random variation give the amplitude of randomness, as in, ORTSLifespanVariation ( 0.25 ) means the particle lifespan can be anywhere between 25% longer or 25% shorter than normal (for a total magnitude of 50%). Be careful with that. ORTSUseChaoticRandomization ( 1 ) will enable "chaotic" randomization (as opposed to the "smooth" randomization that's been in use for years now) where the random adjustments to particle data will be truly random, instead of deviating only slightly from the previous particle. Chaotic randomization might look more or less natural for your application, it's just down to whatever you want.


While I'm not going to deal with changes to emitter simulation, I did have to change the settings of every emitter type but couldn't check every single one of them, so keep an eye out for any type of particle effect that seems to be too strong or too weak as now is a good time to make those adjustments. And take a look to see if there's anything that would be helpful to customize but is lacking a customization option.

[Weter]

Impressed.
So, it still can be applied for diesel smoke fx too, though changes now would be not so dramatic?

And what about wagon/heating boiler smoke? Hot box fx?

Hm, with position variation it could be possible to simulator narrow-rectangular outlets?

[pschlik]

The changes affect every type of particle effect and the customization options can also be used on anything, but the difference between old and new is most obvious when the emitter is when a tremendous amount of exhaust is being emitted, like the main stack of a steam locomotive.

Position variation is good for rectangular exhaust ports, but then ORTSPipeArea should be used to set the exhaust area to whatever the area of the rectangular exhaust is, since OR assumes it's circular. Wrongly set area will result in less reasonable exhaust speeds.

[Weter]

Quote

Wrongly set area will result in less reasonable exhaust speeds.

So, as before.
Do I understand it right, that setting pipe area equal to minor rectangle's side still won't give an accurate result?
Or actual rectangle's area should be set? Ah, I see: it's exactly for compensation in case of non-square outlets.
Is initial velocity zero now?

Quote

- ORTSInitialVelocity ( x y z ) - defines the right, up, forward components of emission direction (unitless, the particle speed is multiplied by this vector to determine the 3D velocity of particles. Speed can be divided by inserting values less than 1, or multiplied by inserting values greater than 1).

What about negative values?

Phillip, does this code deal with smoke's collision to overhead and other objects along tracks?

Also, what about variable smoke color, depending on combustion's deepness, and permanent color, depending on fuel used?

Quote

ORTSPipeArea ( a ) - Niche parameter, to adjust the area of the exhaust pipe, used by the simulation (default units square feet).

Has it strict sense to set this value in non-metric units, despite of all the rest?

[darwins]

This looks excellent at first sight, but there are some questions.

( 1 ) For steam exhaust is there any change for better or worse in differentiation between the smoke component and the steam component?

( 2 ) Previously very small exhausts, like the "truck tail pipe" exhausts on UK first generation dmu would give very high velocity. Is this now improved?

( 3 ) How does this deal with steam leaks - where small amounts of steam might drift out of small openings at low velocity and volume?

Perhaps ( 2 ) and ( 3 ) can both be influenced by

ORTSInitialVelocity ( 0 1 0 )

This is something that previously seemed effective only in terms of direction and not in terms of velocity.

[Weter]

Hello, Darwin.
But doesn't steam component now go from Cylinders exhaust fx?

Note ORTSEmissionSpeedLimit

[pschlik]

 Weter, on 12 July 2025 - 09:44 PM, said:

Is initial velocity zero now?

No? Initial speed is either calculated from a specified flow rate (speed = flow rate / area) or set directly depending on the type of particle emitter, this speed is adjusted by the speed limit behavior so you don't get particles shooting off to space, then the speed is multiplied by the velocity given in the emitter settings to produce the actual 3D velocity.

 Weter, on 12 July 2025 - 09:44 PM, said:

What about negative values?

Giving a negative value to any of the random variation parameters will give the same results as a positive value, the randomness is bi-directional.

 Weter, on 12 July 2025 - 11:38 PM, said:

Phillip, does this code deal with smoke's collision to overhead and other objects along tracks?

No, that's not going to happen.

 Weter, on 12 July 2025 - 11:38 PM, said:

Also, what about variable smoke color, depending on combustion's deepness, and permanent color, depending on fuel used?

No, not this time. I don't know how that could be calculated and I'm not trying to change any of the particle simulation, just particle behavior.

 Weter, on 12 July 2025 - 11:38 PM, said:

Has it strict sense to set this value in non-metric units, despite of all the rest?

Square feet is only used if no units are given, ORTSPipeArea ( 5 ) would be 5 square feet. Allowed area units are ft^2 or m^2, which is exactly the same as everywhere else areas are used. There is nothing special going on about units here except that a lot of the customization options are actually unitless.

 darwins, on 12 July 2025 - 11:56 PM, said:

( 1 ) For steam exhaust is there any change for better or worse in differentiation between the smoke component and the steam component?

No, not changing that at the moment. That is an entirely different undertaking.

 darwins, on 12 July 2025 - 11:56 PM, said:

( 2 ) Previously very small exhausts, like the "truck tail pipe" exhausts on UK first generation dmu would give very high velocity. Is this now improved?

Some emitter types were improperly telling the emitter to use a certain volume of particles even when the volume wasn't actually simulated (while the flow of steam out of the cylinders is calculated, the flow of steam out of the whistle is not calculated, for example), which would cause the speed of particles to change depending on the size of particles (smaller particles = faster particles at the same volumetric flow rate). Everywhere that doesn't have a calculation for the actual flow rate (like the whistle) now just tells the emitter to use a constant speed, so those won't give crazy velocities regardless of the particle size. Don't know if that is true for the specific emitter type you are thinking of.

 darwins, on 12 July 2025 - 11:56 PM, said:

( 3 ) How does this deal with steam leaks - where small amounts of steam might drift out of small openings at low velocity and volume?

Low velocity/low flow stuff will just lazily spit out a particle every once in a while and it will get blown away by the wind.

 darwins, on 12 July 2025 - 11:56 PM, said:

Perhaps ( 2 ) and ( 3 ) can both be influenced by

ORTSInitialVelocity ( 0 1 0 )

This is something that previously seemed effective only in terms of direction and not in terms of velocity.

Ah but now that actually does control the velocity. Previously, no matter what numbers you entered in (0 1000 0) would get scaled back to a direction vector with length 1 (0 1 0), but with this change you can enter in any length you want to multiply or divide the particle speed. ORTSInitialVelocity ( 0 10 0 ) would set the vertical component of velocity to 10 times the calculated speed, ORTSInitialVelocity ( 0 0.5 0 ) would halve the calculated speed. So, if the speed doesn't seem right, you can multiply it until it does seem right. But still, if there's something that seems too fast or too slow by default, it's better if the default speed is good.

Also, changing the velocity multiplier might cause particles to become spread out or clumped together, which can be changed with ORTSRateMultiplier to multiply the rate of particle emissions.

[Weter]

Thanks for answers.
But I've meant

Quote

- ORTSInitialVelocity ( x y z ) - defines the right, up, forward components of emission direction (unitless, the particle speed is multiplied by this vector to determine the 3D velocity of particles. Speed can be divided by inserting values less than 1, or multiplied by inserting values greater than 1).

What about negative values?

Quote

Giving a negative value to any of the random variation parameters will give the same results as a positive value, the randomness is bi-directional.

How to direct it Left, Down, Backward then?
Long/Lat/Vert maybe?

[pschlik]

 Weter, on 13 July 2025 - 11:14 AM, said:

Thanks for answers.
But I've meant


What about negative values?

How to direct it Left, Down, Backward then?
Long/Lat/Vert maybe?

Randomness is bi-directional, non-random values (initial position, initial velocity, final velocity, and such) are uni-directional where the direction is implied by the sign. ORTSInitialVelocity ( 0 -1 0 ) shoots particles straight down, ORTSInitialVelocity ( 0 1 0 ) shoots particles straight up.

[Weter]

So, for ORTSInitialVelocity ( x y z ) negative values are valid, and with them it will not be only define right, up, forward components of emission direction?

[pschlik]

Yes...this is how MSTS worked, it's nothing novel.

And since it seems like it's not obvious, negative numbers in final velocity can change the direction of the final velocity. Most things will actually accept negative numbers, though the result might not always be useful.

[Traindude]

Just to clarify, does ORTSPipeArea refer to the cross-section of the orifice from which the smoke/steam will be emitted from?

[CrisGer]

will still need to have some focus on good textures ... can toss some to you when that time comes

Chris

Attached thumbnail(s)

• 
• 

[pschlik]

 Traindude, on 13 July 2025 - 05:58 PM, said:

Just to clarify, does ORTSPipeArea refer to the cross-section of the orifice from which the smoke/steam will be emitted from?

Yes the pipe area, as the name implies, is the cross sectional area of whatever thing the particles are coming from. Bigger areas lead to slower particles (unless the particle speed is set directly by the system) as there is 'more room' to fit in all the exhaust.

Anyway, custom particle textures are now a thing. This works with the .ace and .dds formats, but also with common image formats .png, .jpg, .bmp, and .gif (a side effect of what I've done means that some other systems will now also support regular image files, but keep in mind that .ace and .dds are very efficient for the GPU to load). The texture is first checked from the location of the .eng/.wag, if it's not there then GLOBAL\TEXTURES is checked, and if it's still not there then the OR Content folder is used (Erick C. has freely provided a dieselsmoke.dds that could be included with OR directly, but I don't have a smokemain.dds to include so perhaps that's where you come in, Chris). This does mean that any image in the Content folder can be used as a particle.

https://i.imgur.com/C0cD2s3.jpeg

Now I would say, "just" add ORTSGraphic ( "Loading.png" ) to the particle emitter parameters, but anyone who's worked with particle textures will know that each texture is actually 16 different particle sprites in a 4x4 grid, randomly selected by each particle. To handle textures that aren't 4x4 sprite sheets, like the OR logo, ORTSGraphicAtlasLayout ( w h ) can be used to specify the type of sprite layout used. For textures that are a single sprite, ORTSGraphicAtlasLayout ( 1 1 ) would be used. If you had a sprite sheet that was 2 sprites wide and 4 sprites tall, ORTSGraphicAtlasLayout ( 2 4 ) would be used. Try to keep your sprites square as particles themselves are square. Rectangular sprites will be squished/stretched to fit the square particle. If that doesn't make sense, don't touch this parameter as setting it wrong will give nonsensical results.

Oh yeah, and just like other places where textures are defined, you can give a path to a different folder if the texture is not in the same folder as the .eng/.wag such as ORTSGraphic ( "..\\SmokeTexturesFolder\\ExmapleTexture.dds" ).

[Weter]

Hello. Sorry for asking twice yesterday, though, it seems my hint was gone unnoted.
I have quoted description from GitHub's link (Manual change project, I guess), and, for novice's eye, I'm afraid, it would sound, as it was written: only right/forward/up.
I'm not a novice, thanks god, so I have understood You after first answer, but still would like, manual to be clear finally.

And thanks for making textures choice flexible!