Molten planets glowing?

[shadmar]

I'm currently testing molten, volcanic planets, I've done some shader changes, and I wonder if this is being covered elsewhere or if this is something I could do ?

Here are some shots from this thread : http://spacesimcentral.com/forum/topic/3149-volcanic-glow-viewable-from-space/

[Ae-2222]

These look great:)

I'm currently testing molten, volcanic planets, I've done some shader changes, and I wonder if this is being covered elsewhere or if this is something I could do ?

It depends on what you are doing exactly. I take it you are modifying the geosphere-terrain shader for volcanoes?

Current shaders support an emission colour for the whole planet. The scene ambient is also added on with some dimming due to atmosphere particles. Just changing the emission/making specific coloured terrain emit in the fragment shader (e.g. emit if col.r>0.8) will work pretty well. Are these the types of things you are tweaking, or something more advanced?

It might help to define on what exactly volcanic glow-y effects are. There are probably two components to it:

• a shimmering effect at close range
  • Best done through a post processing shader?
• Light emitted from lava - light is emitted and a portion of it hits a low layer of particles. This scatters light in different directions making the air glow. The particles also reduces the intensity of light travelling from the surface directly to the camera. If the vertex data included per vertex emission, a scattering implementation could simulate the dimming part. This would be based on a fragments emission value but would not take into account neighbouring fragments emission and their contribution to glow. The neighbouring fragments' emission would require a screen space post processing shader to do properly, and that shader would need access to emission colour data.

The old post-processing code was got taken out with a faulty HDR, so a post processing solution will take a bit of work.

The WiP scattering will probably support 4 layers of particles (no guarantees as it's still WiP). It will also have some realistic scattering which could be used for the dimming and particle layer data generated in C++.

Adding per vertex emission colours is doable, but will require some work in geosphere as well as writing colour fractal code to create emission values (something like this will probably need to be done eventually to enable fractal city lights at night). It may not be necessary in the short term, if emitting terrain is identified by colour type.

So, as for being covered elsewhere, it's not as far as I'm aware. C++ code used to create a volcanic glow would probably be valid for the new scattering too, and any shader glow effects you make could be redone in the new scattering shaders easily.

[shadmar]

My shader change is pretty simple for now (as you guessed), however I think I need to check if current planet is volcanic in GeoSphereSurfaceMaterial::CreateProgram or even Jupiter will glow. Not sure how I can do that?

My intention was to pass a preprocessor directive like this (I like those, then you don't need huge amounts uniforms to maintain)

ss << "#define MOLTENGLOW\n";

Then add this to the shader geosphere_terrain.frag (for both atmospheric and non atmospheric planets)

..
//copy vertexcolor uniform and enhance a little
vec4 vc=vertexColor*1.3;
.. 
#ifdef MOLTENGLOW
//Lava for volcanic planets
if (vc.r > 0.25 && vc.g < 0.2 && vc.b < 0.2)
{
           //overwirte diff to avoid lighting.
        diff=vc*pow(vc.r,2.0)*4.0;
}
#endif

As for postprocessing glow I didn't find any existing class covering postprocessing, however I found in Alpha_19 there was one before covering HDR which were later removed as you said.

[Ae-2222]

My shader change is pretty simple for now (as you guessed), however I think I need to check if current planet is volcanic in GeoSphereSurfaceMaterial::CreateProgram or even Jupiter will glow. Not sure how I can do that?

The best way might be to add a new lava terrain property and a way of checking if a terrain has lava. Then it's a matter of creating a new descriptor for terrain with lava in GeoSphereSurfaceMaterial::CreateProgram and sending a define to the shader, as you said. Selecting the new surface based on checking the terrain to see if it has lava should be done in GeoSphere::SetUpMaterials().

I can create a way of interrogating terrain for lava and sending a #define for the shader (not all volcanic terrains should have active lava), and upload it to github. It's just a matter of merging it to your branch to use it:)

---

As for postprocessing glow I didn't find any existing class covering postprocessing, however I found in Alpha_19 there was one before covering HDR which were later removed as you said.

It would be useful to restore some of the functionality..Some general post-processing interfaces, including the ability to mask certain objects, would be useful too. The graphics people, mainly Luomu, are the ones to speak about that.

[shadmar]

I can create a way of interrogating terrain for lava and sending a #define for the shader (not all volcanic terrains should have active lava), and upload it to github. It's just a matter of merging it to your branch to use it:)

That would be really great if you already have an idea on how you want it. This could also be reused for water shading, ice spacular shading etc.. it would be of great value.

It would be useful to restore some of the functionality..Some general post-processing interfaces, including the ability to mask certain objects, would be useful too. The graphics people, mainly Luomu, are the ones to speak about that.

Yes I was looking to maybe add an optional crepuscular ray shader (like in godrays) for suns, expensive to render yes, but very nice effect. Also maybe HDR should be revisited at some point?

[Luomu]

Pre-emptive warning that I don't like the idea of having dozens of terrain shader variations, especially on one planet, it hurts performance and portability. That said, volcanic glows, totally doable!

Here's what I recommend: use vertex color alpha as the generic effects channel, on volcanic planets it would control self-illumination intensity and on earthlike planets it could control specular intensity for water. Write color fractals and shader ifdefs that take advantage of this. These effects will not be combined so on one planet you have either self-illumination or selective specular shading.

[Ae-2222]

Pre-emptive warning that I don't like the idea of having dozens of terrain shader variations, especially on one planet it hurts performance and portability

Usually it's me being concerned about handing variation over to the GPU:) What was being discussed just adds in #defines/#ifdefs so there will be a different shader per planet (1 shader for that terrain class). There are a bunch of these types of terrain classes with special materials. As for branches in shader code, any single planet is likely to only have a couple of types of special materials at most or a max amount could be set. This would be a trivial performance hit.

Here's what I recommend: use vertex color alpha as the generic effects channel, on volcanic planets it would control self-illumination intensity and on earthlike planets it could control specular intensity for water.

It's a good idea, more involved than this simple colour level based glow, as it requires getting GetColor to emit more data. Eventually, we might end up with a couple of more vertex attributes available to act as parameters for effects, as a result of doing pretty city light fractals visible from a distance at night (CPU-memory wise using floats will halve it as tested in one of my branches..)

---

That would be really great if you already have an idea on how you want it.

Ae-2222/volcanic-terrain-identification :). It can be extended to add in other types of special terrain. Github has a compare view which shows what's been changed which should help (People's branch pages can be browsed, and the compare view selected..). You can merge this onto your branch or checkout this branch and add a commit applying your shader code.

In the branch volcano terrain will have exposed lava 50% of the time (Io will not have lava based on its seed). Whether or not a terrain colour class has certain effects enabled is determined by setting the relevant surface composition in the colour class constructor.

One issue is how the effect looks on planets with bright surfaces at daytime. Jupiter's moon Io is probably a good test, but the lava isn't active there unless the random selection in the colour constructor is overridden. The solution to this issue might be to create a separate darker volcanic terrain colour class.

This doesn't solve the issue of whether a particular point on the terrain is lava (landing should damage your ship). Solving that involves making GetColor(point) emit the properties of the terrain at that point, as I said at the end of issue 1744 (I can alter that, but it's a little more involved).

[Luomu]

Okay, the idea is welcome but this is too discussiony for the issue tracker.

Want to discuss something? pioneer-dev@pioneerspacesim.net Got a contribution? Make a pull request.

[Ae-2222]

this is too discussiony for the issue tracker.

The discussion-y bit mostly started after your general observations about shaders and performance issues due to branch proliferation:)

This was originally about an actionable task, which would result in code.

Got a contribution? Make a pull request.

If you read up, this is effectively a Pull Request collaboration, i.e. about code which exists and contributions to that code. Issues that do the same thing as pull requests will have the same result:) It would be better done if it was in Pull Request form where people could see the changes in the diff and make line comments.

@shadmar, you should Pull Request your branch (by merging my branch into yours or starting with my branch and adding your shader code - unless you have everything you need to proceed)

[shadmar]

Thanks Ae_2222, merged your code ok and it works great from my initial test. I can move this to the mailing list for further discussion or do a pull request.

Sorry for the issue tracker spam.

Thanks Shad

[Ae-2222]

I can move this to the mailing list for further discussion or do a pull request.

Discussion related to things being implemented really should be a PR, as it allows others to follow progress and test and add things.

[Luomu]

The discussion-y bit mostly started after your general observations about shaders and performance issues due to branch proliferation:)

No, it turned into a discussion as soon as you replied. You should know better by now. I should have directed this to the ML immediately, but I fell into the same old trap at first.

[Ae-2222]

The discussion-y bit mostly started after your general observations

No, it turned into a discussion as soon as you replied

Same meaning:)

There's no particular harm done by replying to offtopic topics/questions, as long as the new topic doesn't last more than one reply or so, but I should have added a reminder at the end that it belongs elsewhere. Especially if it's a quick question and the contributors are not on IRC or are new.I'll remind next time:)

There's only so much point in being legalistic about it as long as there's no loss suffered.. given the processes are there to serve the people and not the other way around. Though in this case the topic was perhaps relevant to others and belongs elsewhere (and is worth expanding on by determining some profiling goals, sometime in the future).

(Something to be kept in mind is almost all non-extremely-specific technical discussion that has happened, even after the ML, has happened even less visibly than on the issue tracker (i.e. on IRC), and almost never on the ML - perhaps as people prefer a private/informal medium and also are reluctant to spam other peoples email by using the ML every time they have a minor technical thought.. it's something for further thought via IRC or the ML).

[Luomu]

Sigh, it was not a call to debate. Continued in private.