Atomic Systems

I have noticed over the last few days that at high speed the smoke/steam from steam loco's has become displaced slightly so that it eminates from behind the chimney. Take a look at these pics from the screenshot forum, particularly the side on shot of the 8F. Not as obvious as I'm seeing on my system but I'm sure it can be seen. Also take a look at some of the pics of the 4MT on DT's website, particularly the last one.

http://forums.uktrainsim.com/viewtopic. ... &start=195

http://www.digitaltraction.net/mainsite ... &Itemid=88

Too be clear, the emitters are correctly placed in the centre of the chimney and when stationary and at low speed the smoke looks fine. But as speed increases the smoke just seems to not accelarate quite fast enough and starts to lag behind. By 40mph the smoke is quite visibly not coming out of the chimney anymore.

This is definitely a problem on my system, is it on yours?

Stuart

The smoke just slightly behind the chimneys has been around for quite awhile, just seems to be a thing which happens as you gather speed in the particle generation of smoke, I think this is a limitation of the graphical system combined with coding for the time being. I suppose its to stimulate the higher speeds where the smoke is being blasted back by the wind resistance which hits the chimney but it can look wierd on some locomotives. Just something we have to deal with, rest of the time you can ignore it really.

scefhwil wrote:I have noticed over the last few days that at high speed the smoke/steam from steam loco's has become displaced slightly so that it eminates from behind the chimney.

<snip>

Too be clear, the emitters are correctly placed in the centre of the chimney and when stationary and at low speed the smoke looks fine. But as speed increases the smoke just seems to not accelarate quite fast enough and starts to lag behind. By 40mph the smoke is quite visibly not coming out of the chimney anymore.

This is definitely a problem on my system, is it on yours?

Confirmed: same here for me, Stuart and I'm pretty sure it wasn't like that before but it's one of those things that I wasn't 100% sure about.

It was most noticeable when I was driving Sly's super 9F a week or so ago, particularly on the safeties; I'm positive that it wasn't like this when the model first came out.

Rgds, Rik.

I have noticed the same thing happening of late.
Not sure whether there is a connection but I also find that if I follow the engine in view 2 and move the camera into the smoke the sound starts to break up and the train valve gear/wheels become jerky.
Once I move the camers out of the smoke things return to normal.
I can't say I have noticed this before update to 110.8b

Dave

detectorman wrote:I have noticed the same thing happening of late.
Not sure whether there is a connection but I also find that if I follow the engine in view 2 and move the camera into the smoke the sound starts to break up and the train valve gear/wheels become jerky.
Once I move the camers out of the smoke things return to normal.
I can't say I have noticed this before update to 110.8b

Dave

Ever since I first got RW I have noticed a slight drop in performance whenever the camera gets in a smoke cloud. The reason is that everybody tunes their graphics settings to be nice and smooth under normal conditions, not the small amount of time you spend with the camera going through smoke. Different locos (diesel as well as steam) affect it in different ways based on how good the smoke effects are. The lovely smoke on the A4, Light Pacific and 9F is in a completely different league to the speech bubble effect of Kuju's 7F and Black 5 but unfortunately this means the graphics performance penalty when the camera comes into the cloud is so much worse on the better engines.

transadelaide wrote:

detectorman wrote:I have noticed the same thing happening of late.
Not sure whether there is a connection but I also find that if I follow the engine in view 2 and move the camera into the smoke the sound starts to break up and the train valve gear/wheels become jerky.
Once I move the camers out of the smoke things return to normal.
I can't say I have noticed this before update to 110.8b

Dave

Ever since I first got RW I have noticed a slight drop in performance whenever the camera gets in a smoke cloud. The reason is that everybody tunes their graphics settings to be nice and smooth under normal conditions, not the small amount of time you spend with the camera going through smoke. Different locos (diesel as well as steam) affect it in different ways based on how good the smoke effects are. The lovely smoke on the A4, Light Pacific and 9F is in a completely different league to the speech bubble effect of Kuju's 7F and Black 5 but unfortunately this means the graphics performance penalty when the camera comes into the cloud is so much worse on the better engines.

Exactly and this is why Sly drifted the smoke down on the Bigboy. Anyone whos driven the Challenger knows if you get caught in the hurrichimneycane of smoke that thing produces your machine starts crawling.

On a slightly different tack I'd really like to see the smoke/steam effect from the chimney travel a bit more vertically before it starts to trail, thereby representing the blast a little better. With the new smoke effects now being implemented I reckon it would look superb at slower speeds, especially on a freight!

Cheers
Ken

Smoke effects is one of those dark arts. I used to mess with locomotives particle effects in the early days but it has got so much more advanced with the emitter stacking. Remember when you'd plop an engine down and see a single smoke emitter? Now minimum is like two per stack and some they're stacked in there like solo cups.

Thanks for the replys. Relieved I'm not the only one seeing this as at least that means it's not down to something I've botched up. Have to say though that I'm sure this has been introduced by one of the core updates released in recent months.

Cheers

Stuart

Hi Guys
just taking a quick break from scenarios, and this is a pet subject of mine too.

The whole problem is that whan a particle is emitted its intial velocity in X and Y is zero and its vertical initial velocity is fixed in the BP.

So the particle is standing still yet the locomotive is moving, hence the highr the speed the more it gets left behind.

On the 9F I put together a series of 12 emitters that covered the speed range 0-12 mph initial velocity (for the safety valve) and up to that speed the SV steam keeps shape and time with the loco via lua.

Once speeds get past 12 mph it gets left behind like all others and results in the string of pearls efffect.

very simply the xyz parameters for initial velocity need to be lua scriptable.........

x would match the spped of the vehicle
z would be the verrtical speed most probably set by steam chest pressure

Its all there just needs the lua calls making available and some stunning effects could be achieved........

check out the SV on the 9F at slow speed and you will see that the stream remains vertical up to the 12 mph cut off point.

Good discussion

Sly

Interesting, a better but probably VERY difficult solution would be to have the emitters lower in the chimney so the smoke already had some flow and a way of adding a `solid` tube to guide the smoke like a real chimney - get that sorted & no smoke through bridges etc. The `solid` material for the tube is the hard bit

Hi Mark

Actually the solid bit and from down inside the chimney would be the easy bit if the particle effect inherited the loco's initial velocity.

It would probably be a separate (chuff linked ) effect that had a very low emitter rate
( this seems the wrong way round but emitter rate appears to be time between release, so a very short 0.0003 etc rate gives a solid stream ) ...
Couple this with a high vertical velocity ( increasing with workload ) and a short life .

The billowing clouds would be a seperate effect sat above the stack again responding to work loads but again needing to inherit the initial velocity.

Sure its possible and have asked the question.

Sly

Sly401 wrote:Actually the solid bit and from down inside the chimney would be the easy bit if the particle effect inherited the loco's initial velocity.

Oh, so you are saying that they don't? Now that would be a pity. I have not dabbled into this field yet, but basically, if you need scripting to give them the natural speed, this sounds a bit of overhead to me.

Says he who plans for lots of "overhead" along the lines you mention.

Hi Andi

Controlable ie responsive smoke can only be done by scripting as I'm sure you know, whether this is in the hard code script or a call is made available .

In simplest terms initial velocity "Y" (I think ) is equal to abolute speed of the parent loco for all effects...... it should be in any case not static .. all the tricks come later.

Just this simple addition would improve even existing smoke FX whatever there size or function.
My tests with a stacked series of sequential emitters showed this to be the case for me.

the control of other functions like visibilty of steam in cold weather linked to winter textures etc can come later.

The Particle system has all the parameters.. I (We) just need the control calls.

Sly

I leave the petitioning in this field to you.

For me as a layman, adding the current parent velocity to the initial velocity sounds like a must.

Making some of the parameters script-accessible is always a good idea, but I cannot make a priority list with my non-experience.

Even making the argument to SetEmitterActive a float instead of a Boolean (rather: binary integer) would help you in your hacks. Then you could at least do some smooth compositing.

As for winter, I guess we better look for alternative solutions. What about having a winter version of the engine, with a different set of particle effects? You could add some ice and some additional blinds/coating to the mesh on that occasion, for some (non-UK!) models. In summer scenarios, you use one version, in winter scenarios the other. No need to change between the two particle emitter sets during a scenario run (unless you simulate a mountain pass climb, but then, we need altitude, too).