Animated the thrust flame

[jeffmd]

The thrust flame is now animated by randomly expanding/contracting the flame and by making small changes in the flames diffuse color and alpha each frame. Its simplistic but for now adds some life to the ship when viewed externally.

[bszlrd]

Nice idea. Could you post a video?
I've recorded a gif of it:

[fluffyfreak]

The effect looks quite nice, but I've got a couple of comments.

I'm sure @impaktor can advise on fixing it but the merge of master is something I always trip over and do as well, and the commits can be squashed into a single one.

I'll make other comments inline with the review but it looks good 👍

[jeffmd]

Agreed, and I don't like using rand() (twice) or magic numbers either. It was just a quick trial to see if a cheap trick would work and to see if something like this would be of interest. Eventually I would like to do this in a shader but need to learn more of the Pioneer render engine first.

I found through trial and error that a thrust_flicker value between 0.9 and 1.0 worked for varying the diffuse and alpha each frame without it being too annoying. Its definitely subjective though.

For the thrust_scale range its also a matter of taste. A range of 0.85 to 1.0 seem to work ok for most views and frame rates. If the range is too large and frame rate is low, and the view to close, then the effect does not look that good. Modifying the transform is not the best way to do this but it was simple for now. Doing it in a vertex shader before the transform is applied would be better. The shader could just jitter the UVs or the vertices directly to have more control over which way the flame distorts based on engine power setting.

[impaktor]

Eventually I would like to do this in a shader but need to learn more of the Pioneer render engine first.

A simple (sort of) description of Pioneers rendering

[jeffmd]

Thanks. I've been going through the dev forum but hadn't found that post yet.

The source code is well laid out and so far has been easy to read and understand.

[impaktor]

I've been going through the dev forum but hadn't found that post yet.

Pinned at top ;)

[bszlrd]

Recorded a gif to showcase it:

Looks nice! Not sure about the amount, it might benefit from being a bit more subtle. Especially for large ships:

How complex it would be to make it configurable in the ship.jsons?
In the long run I could imagine this flicker getting more and more visible as the engines are degrading.

[jeffmd]

Development for the first working draft of the shader based animated thruster flame (prototype B) went a lot faster than I expected. closing this PR for prototype A.

[jeffmd]

Animating the thruster flame using a shader is now working.

I used the material emissive to pass thruster power setting and flicker value to the shaders. Seemed a waste to create a new uniform and buffer when emissive was free to use.

Thruster power now controls the flame length along with the flame brightness and alpha. Flame length starts at 25% of its full length when thruster power is just above 0. At 100% power the flame is at its full length.

The flicker value is now just a value between 0 and 255 and the shader converts it to 5% to effect flame size, brightness and alpha.

[bszlrd]

I really like that scaling effect. (large gif incoming)

Especially on rotations:

I wonder how a combined transparency and scaling animation would look. Like at 0% power, it could be at 50% transparency for example, and go to 100 from there linearily.

[jeffmd]

bszird: you are looking at it :)

[jeffmd]

The first pull request was supposed to be it for animated thruster flame but adding the shader opened up new possibilities. Dropping into draft mode because there are a bunch more changes/improvements and feature additions to be committed. Would still like feedback as this develops.

[sturnclaw]

General thought, just reading the diff - I'd slightly prefer if we sampled either application time or game time (e.g. via sine/cosine) for shader-based random effects rather than using a random number generator on the C++ side. This has the upside of effects appearing consistent under "pause", especially if we were to apply some sort of visual effect to indicate that the game is paused.

That being said, off the top of my head I don't think we have the application time variables easily available to shaders yet so some under-the-hood work would need to be done first on my part.

[jeffmd]

100% agree.

In my latest iteration the use of rand() is gone. Game::GetTime() is passed through RenderData.tick which I added as a test for now. Thruster.Render() passes RenderData.tick to material emissive.a channel which the vertex shader uses to generate a pseudo random value. So now when I press pause on screen the flame stops animating.

[jeffmd]

I know about the issue of using Pi::game->GetTime() and building the editor. Its a temp solution as I narrow into a better solution. Which is why I am not updating the pull request.

[fluffyfreak]

This is good stuff, I love the improved visual effect. Using the emission value is neat, and the comments are good.
If you can squash the commit history down to a single commit that would be appreciated

[jeffmd]

Update for latest push:

• rand() has been replaced with sin() for generating the random flicker.
• RenderData now has a component called timeStep that is used to communicate change in time to the render methods.
• added a method to Model to set the time step for the next render frame
• Game pause will pause all model shader animations even in cockpit view.

Now the real challenge: doing a git squash to clean up the mess of commits I made :)

[jeffmd]

I did a forced push after rebasing and the github pull request closed. First time doing it so not sure if that is normal for github pull request.

[fluffyfreak]

I like this, doing it in the shader is good and opens up future possibilties

[fluffyfreak]

I pointed out a couple of minor indentation issues visible in the review but the don't affect the work.
Overall I really like change and the effect 👍 excellent first contribution.
I'll wait on @sturnclaw to review/merge as they always have good feedback to add