[1.8.x-1.10.x] SmokeScreen 2.8.14 - Extended FX plugin (18 April 2020)

[eggrobin]

The reflection plugin does not use a geometry shader afaik. And it's not the first plugin to import a shader. Kethane does it, I did it for MJ and I'm sure other did too.

But there are limits to what we can do from inside KSP and importing a geometry shader is one of those limits AFAIK. I'll have a look at the Reflection plugin code but I doubt it uses anything different from what I use now.

I'm completely clueless as far as graphics are concerned so I don't know how relevant this is, but rbray89 seems to use shaders he writes in GLSL, which none of the aforementioned mods do (actually, most of his code is GLSL).

[skykooler]

Aren't the reentry effects geometry shaders?

[Proot]

I'm becoming mad trying to achieve realistic FX. Not only with smoke (the parallel hitting behaviour of my particles is simply absurd, It seems like the smoke go on skate) but also with the growth of the %&$# flames...

Moments when you realize how limited you are.

[Jovzin]

nothke? And what about this

I am really looking forward to this mod. My KSP gamedata folder will be complete with this

[Motokid600]

Still getting ugly, flashing reentry effects. Is there a fix I can perform before I remove the plugin?

[NoMrBond]

nothke? And what about this http://i.imgur.com/40bGScU.gif

I am really looking forward to this mod. My KSP gamedata folder will be complete with this

Stubbles put something similar in the 1.2 release of the HA Zenit-3SLB

[NoMrBond]

Actually, another request (on top of being able to apply SmokeScreen to part explosions)

The ability to add particle trails to Wheels

[Proot]

I achieve those effects, but the behaviour of my grounded particles comes out much more quickly and in a star shape (ignoring the launch pad in some points) . I can't avoid that, as much I try. (And I've tried A LOT)

The particles grow and aspect in my configs is very cool, but when my grounded particles hit on other objects in horizontal direction (as the tank at a side of the launch pad) they come out bounced very quick in 45º angle, ruining the effect .

Neither I'm able to fit the flame and the start of the smoke trail and at the same size. I wish my flames would end bigger than the emisor and at the same size at smoke starts. Similar to this nothke's magnificent:

Another little-big thing that I hate: the damn separated ball effect of my trails at high speeds.

[stubbles]

my grounded particles comes out much more quickly and in a star shape

That's because of the actual particle system itself. I believe Nazari is using ellipsoid emitters with zeroed out forces on the particles. For my launch smoke I have a point emitter that has a force on one direction axis, which aligns with the launch pad. If you rotate my rocket 90º, the smoke won't look right at all. It will hit the pad and spray out everywhere.

I was trying to imitate the effect that Nothke did with his pad smoke, but I don't know how he did it. His particle system is doing things I don't know how to do. It's moving extremely fast at first, then slowing down, then moving upwards. The particles themselves have a slight jittery animation to them, which again, no idea how he does that. The KSP emitter settings are super limited, so I'm looking forward to hearing how he's doing that.

[sarbian]

I achieve those effects, but the behaviour of my grounded particles comes out much more quickly and in a star shape (ignoring the launch pad in some points) . I can't avoid that, as much I try. (And I've tried A LOT)

The particles grow and aspect in my configs is very cool, but when my grounded particles hit on other objects in horizontal direction (as the tank at a side of the launch pad) they come out bounced very quick in 45º angle, ruining the effect .

I don't really know how to make the smoke moving in a more realistic way.

Another little-big thing that I hate: the damn separated ball effect of my trails at high speeds.

For now try increasing emission with mach. I'll add more parameter to change it with velocity (since at some point I'll have to stop cheating and build mach speed from the actual speed of sound).

stubbles : ahah, so many people wondering. He explained it to me but I'll keep it secret for now

You won't be able to make something that look like what he did and looks nice for all case and camera position.

[Proot]

That's because of the actual particle system itself. I believe Nazari is using ellipsoid emitters with zeroed out forces on the particles. For my launch smoke I have a point emitter that has a force on one direction axis, which aligns with the launch pad. If you rotate my rocket 90º, the smoke won't look right at all. It will hit the pad and spray out everywhere.

I was trying to imitate the effect that Nothke did with his pad smoke, but I don't know how he did it. His particle system is doing things I don't know how to do. It's moving extremely fast at first, then slowing down, then moving upwards. The particles themselves have a slight jittery animation to them, which again, no idea how he does that. The KSP emitter settings are super limited, so I'm looking forward to hearing how he's doing that.

I see... Thanks stubbles. It was driving me crazy trying to avoid that star shape... Is not completely ugly, but its very weird see the smoke coming out from launchpad's concrete...

I don't really know how to make the smoke moving in a more realistic way.

I was assuming this is completely my fault, you give us an awesome tool here! Thank you!

This is what I was trying to reach (excuse a so quick sketch):

For now try increasing emission with mach. I'll add more parameter to change it with velocity (since at some point I'll have to stop cheating and build mach speed from the actual speed of sound).

Great tip, very appreciated, thank you very much!

[Jovzin]

Stubbles put something similar in the 1.2 release of the HA Zenit-3SLB

https://dl.dropboxusercontent.com/u/1482056/horizon71.gif

Thank it looks nice.

I will try it.

[sarbian]

Proot : To have the launchpad smoke look better you can experiment with the damping parameter in unity. 1 means particles don't slow down and 0.7 means they loose 30% of their speed per second.

[eggrobin]

I achieve those effects, but the behaviour of my grounded particles comes out much more quickly and in a star shape (ignoring the launch pad in some points) .

I have submitted a pull request that alleviates this (by changing the behaviour on collision).

It also includes other highly experimental stuff (buoyancy/weight, and some kind of handwavy drag for the particles), so caveat compilator.

The highly experimental stuff can be turned off by setting physical = false.

I have no experience with Unity, so the screenshot looks really ugly (as explained in the pull request, I needed to make my own .mu with no damping for the experimental features).

[Proot]

Proot : To have the launchpad smoke look better you can experiment with the damping parameter in unity. 1 means particles don't slow down and 0.7 means they loose 30% of their speed per second.

Pure gold information, my incapacity is so evident... Thank you Sarbian!!

I have submitted a pull request that alleviates this (by changing the behaviour on collision).

It also includes other highly experimental stuff (buoyancy/weight, and some kind of handwavy drag for the particles), so caveat compilator.

The highly experimental stuff can be turned off by setting physical = false.

I have no experience with Unity, so the screenshot looks really ugly (as explained in the pull request, I needed to make my own .mu with no damping for the experimental features).

Sounds well! I'm gonna try it if I have a little of time.

[nothke]

For now try increasing emission with mach

Particle birth is bound to fps, (or something like that, performance related), which is why they combine into a single point if you put more than they generate. So for example lets say they generate 60 times a second, and you put emission to 120, then, 2 particles will generate at the same place. If you are running really fast, this is quite obvious. Increasing generation with mach won't help as you will just be generating more particles at the same point.

The trick to avoid this is creating them with a different shape, if you use line, then the 2 particles will not generate at the same spot, but will generate at 2 different points along the line. But even if you put a line/sphere/ellipsoid whatever, you will still see "clumps" at very high speed. There are a few more inherent problems to this technique too, like weird linear generation when going sideways.

Another way to alleviate this is to add random velocity or force so that particles get separated.

On one side generation with fps is awful, but on the other hand, making shock diamonds is quite easy cause of this, cause they will always generate at same distance.

Edited March 13, 2014 by nothke

[eggrobin]

I've managed to get some nicer results out of buoyant smoke (more on the pull request page).

I think this could also be used (with high initialDensity) for cryogenic condensation.

[K3-Chris]

The images in this thread look sweet, but I'm a bit concerned about my already glacial fps, I guess if you can dispatch with most of the physics it should be ok, could "cheat" and make the smoke move a certain way during launch, since we know the shape of the pad, making the smoke go down the grate and then to the side doesn't need physics, just a pre-defined movement path, only real problem with that solution is the variable of how high the nozzle is from the pad, if it's very high up and the system doesn't compensate you get smoke turning 90 degrees above the pad, and the second problem is how far from the center the nozzle is, if it's past the grate the smoke wouldn't enter it etc.

Just thinking out loud here.

[Camacha]

Personally I would not like to resort to what are effectively hacks, because some people on the edge of performance might not be able to use it - causing all sorts of other problems in the process. We have a wonderful way of doing it properly and it would be a waste not to use it

At the risk of sounding harsh, adding visual enhancements might not be the best choice if your system is already struggling.

[K3-Chris]

I got a high-end gaming PC, it's not my system at fault here, it's CPU only single-threaded Physx.

[NathanKell]

(Crossposted from HotRockets thread)

So, I'm finally back(ish) and actually looking through stuff now.

I have a request for Nazari, Nothke, and anyone else writing ModuleEnginesFX conversions: please, please, instead of nuking the old ModuleEngines node and rewriting it, use this form. We'll take the Skipper as the example.

@PART[engineLargeSkipper]:Final //Rockomax "Skipper"
{
    !fx_exhaustFlame_blue
    !fx_exhaustLight_blue
    !fx_smokeTrail_light
    !fx_exhaustSparks_flameout
    !sound_vent_medium
    !sound_rocket_hard
    !sound_vent_soft
    !sound_explosion_low

    // snip EFFECTS node

    // DO NOT DO THIS - !MODULE[ModuleEngines]{}

    @MODULE[ModuleEngines] // do THIS instead
    {
        @name = ModuleEnginesFX // and this
        runningEffectName = powersmoke
        directThrottleEffectName = powerflame
        !fxOffset // you should include this, if you want to be sure it doesn't exist.

        // you don't need the rest, since you're modifying the original node, not replacing it
    }
}

This will make it compatible with DRE, and with other things that change the engine's stats.

Let me explain. Since ModuleEngines and ModuleEnginesFX take almost the same parameters, instead of replacing the whole module, you just change the name line to refer to the new module, and add the lines that the old module lacks (and do a remove for fxOffset, in case it exists and you want to clear it out). Further, this will occur on the :Final pass, which means it will occur *after* all other changes are made (like DRE's change to heatProduction).

[eggrobin]

The images in this thread look sweet, but I'm a bit concerned about my already glacial fps, I guess if you can dispatch with most of the physics it should be ok, could "cheat" and make the smoke move a certain way during launch, since we know the shape of the pad, making the smoke go down the grate and then to the side doesn't need physics, just a pre-defined movement path, only real problem with that solution is the variable of how high the nozzle is from the pad, if it's very high up and the system doesn't compensate you get smoke turning 90 degrees above the pad, and the second problem is how far from the center the nozzle is, if it's past the grate the smoke wouldn't enter it etc.

Just thinking out loud here.

Note that the costly thing here is collision: buoyancy etc. should not slow things down significantly. Trying to hack collision-like behaviour for the pad would be complicated, would probably lead to a lot of troublesome edge cases, and would only look good when launching (smoke would still disappear into the ground during powered landings, etc.).

I got a high-end gaming PC, it's not my system at fault here, it's CPU only single-threaded Physx.

Sadly we can't easily run collision detection on another thread (that would require writing our own raycast). Perhaps we could run the raycast every x frames though (and apply buoyancy etc. every x frames, otherwise things will behave weirdly). We could even make x a setting.

Edited March 13, 2014 by eggrobin

[Korn Sarum]

Has anybody been able to figure out how to add these effects to KSP Interstellar? Adding the according to the instructions seems to break the engines.

[sarbian]

FYI : my server is dead and I am working on bringing it back in the next 24H

[eggrobin]

Particle birth is bound to fps, (or something like that, performance related), which is why they combine into a single point if you put more than they generate. So for example lets say they generate 60 times a second, and you put emission to 120, then, 2 particles will generate at the same place. If you are running really fast, this is quite obvious. Increasing generation with mach won't help as you will just be generating more particles at the same point.

I have just pushed a commit that fixes this issue to my pull request.

The issue is fixed by distributing the newly emitted particles uniformly at random along the emitter's trajectory during the frame. Bear in mind that you still have to make the emission high enough, otherwise there just aren't enough particles to make a continuous plume.

I would recommend against using this bug for shock diamonds, as their appearance would then depend on the performance of the machine displaying them.

Other features introduced include better collision, buoyancy and logarithmic growth (which I would strongly recommend instead of exponential growth, as it looks more natural and removes the need for clamping). Avoid using damping with physical=true, it looks awkward. Set the dragCoefficient instead. The new options are as follows:

    // Initial density of the particle seen as sphere of radius size of perfect 
    // gas. We then assume (only true for ideally expanded exhaust) that the 
    // expansion is isobaric (by mixing with the atmosphere) in order to compute
    // the density afterwards. Units (SI): kg / m^3.
    [Persistent]
    public double initialDensity = .6;

    // Whether to apply Archimedes' force, gravity and other things to the particle.
    [Persistent]
    public bool physical = false;

    // How much the particles stick to objects they collide with.
    [Persistent]
    public double stickiness = 0.9;

    [Persistent]
    public double dragCoefficient = 0.1;

    // Logarithmic growth applied to to the particle.
    // The size at time t after emission will be approximately
    // (Log(logarithmicGrowth * t + 1) + 1) * initialSize, assuming growth = 0.
    // TODO(sarbian): make this a cfg-configurable curve (as a function of density).
    [Persistent]
    public double logarithmicGrowth = 0.0;

Here are a few illustrative screenshots a before/after for dotted smoke, and two launch pictures. I didn't do anything fancy in Unity (just an emitter with one of the HotRockets! SRB textures) so the particles themselves are ugly.

Javascript is disabled. View full album

Edited March 14, 2014 by eggrobin