Enchanced output methods

[smcameron]

Enchanced output methods

[smcameron]

I don't really understand what you mean. FWIW, the PNG files that are produced do not have any less information in them than what is used internally to store the colors so far as I know, so if what you're asking for could be produced by gaseous-giganticus, it could probably also be produced by processing the PNG files it produces. Or, if it can't be done from the images, gaseous-giganticus probably can't do it either. But I don't really understand what you're asking for, so I might be wrong.

[WASasquatch]

I guess it's more a two part request, to input/output 32bit float data. Lossless data, and thus also controlling the amplitude of particales. Say a albedo of 25 for whites not 1.

I wanted to feed some alternate cubemaps, which act as the radiance of a "semi-ignited" gas giant without all the node work to extract masks within the 0.001 range of fiddling because the data is clamped between 0-1.

[smcameron]

Your going to have to formulate a better request, I still have no idea what you're talking about. :)

The colors of the particles are stored as floats, however, they are arrived at by sampling an RGB image, and R, G, B are given integer values 0 - 255, then divided by 255.0, yielding a 256 values between 0 and 1. Yeah they're floats, but they might as well be bytes because there are still only 256 values.

The impressions the particles leave on the 6 cubemap images are never stored as anything but bytes.

So, I think the data already is lossless, it's just that it never stored what you're asking for to begin with. (unless I misunderstand).

Are you wanting an emittance layer, but encoded into HDR color?

[smcameron]

If you just want to scale all the colors down to 0... 0.25 range, and store the image in some higher precision format, that feels like something ImageMagick could do (though I am not expert enough with ImageMagick to know how to do it.) But maybe that's insufficient for whatever reason. Still don't have a firm grasp of the problem you're trying to solve. Are you trying to use a tool designed for game assets as if it were a tool designed for cinema assets?

[WASasquatch]

ImageMagick supposedly can do both 32bit float TIFF, and possibly 32bit EXR (though maybe still only half float at 16bit; there is a help topic from 2013 that said it may still only be half-float for EXR but he wasn't sure). Update: Actually yes, it appears to just still be half-float, but TIFF strangely can go well beyond 32bit. Source: https://imagemagick.org/script/high-dynamic-range.php

I'm not sure how else to phrase it. Think of a half ignited gas giant, glow coming from the "low" (or dark) areas of the cloud forms peaking through. I want to take a inverted cubemap, edited to the areas I'd like, and ranged from up to a higher amplitude above 1, say 25.

Then I was hoping particles could be derived which are exported at the same pixel amplitude it was fed, say 25. So when the image is stored, those pixels are (yes HDR you could just say) are at 25, not below or at 1. That way that new cubemap can be used as a luminosity of the planet and glow other glows more naturally within the voxel simulation (terragen software).

[smcameron]

This feels like something better done in the shader, using say some black body radiation model, attenuated by, say, the inverse brightness of the texture. Regardless, because it is "emitting light", it would require shader support of some kind. As long as that's the case, why not do it all in the shader?

[smcameron]

As a sort of proof-of-concept, the following shader change in SNIS:

diff --git a/share/snis/shader/textured-cubemap-and-lit-with-annulus-shadow-per-pixel.shader b/share/snis/shader/textured-cubemap-and-lit-with-annulus-shadow-per-pixel.shader
index c8fb021..72d6307 100644
--- a/share/snis/shader/textured-cubemap-and-lit-with-annulus-shadow-per-pixel.shader
+++ b/share/snis/shader/textured-cubemap-and-lit-with-annulus-shadow-per-pixel.shader
@@ -198,6 +198,14 @@
 
 
                gl_FragColor = textureCube(u_AlbedoTex, v_TexCoord);
+               float bbr_attenuation = gl_FragColor.r + gl_FragColor.g + gl_FragColor.b;
+               bbr_attenuation *= bbr_attenuation;
+               bbr_attenuation *= bbr_attenuation / (27.0 * 9.0);
+               vec3 bbr;
+               bbr.r = 0.3;
+               bbr.g = 0.05;
+               bbr.b = 0.0;
+               bbr *= bbr_attenuation;
 #if defined(USE_SPECULAR)
                vec3 white = vec3(1.0, 1.0, 1.0);
                float not_clouds = 1.0 - smoothstep(0.8, 1.0, dot(gl_FragColor.rgb, white));
@@ -205,6 +213,7 @@
                gl_FragColor.rgb += specular_color * mostly_blue * not_clouds;
 #endif
                gl_FragColor.rgb *= diffuse;
+               gl_FragColor.rgb += bbr;
 
                /* tint with alpha pre multiply */
                gl_FragColor.rgb *= u_TintColor.rgb;

yields this:

Is that what you're trying to do? Make a brown dwarf, that's kind of glowing in the dark? Definitely will need shader support, you cannot do it with an albedo texture alone. But you seem intent on encoding the emittance into the texture, perhaps you've already got a shader that expects the emittance encoded some way? (Not too keen on adding features to accommodate somebody's weirdo custom shader.) Am I correct in guessing that the above image is close to what you're trying to do?

[WASasquatch]

Because Gaseous Giganticus is just exporting maps/masks to use within Terragen. When I have a 0-1 range in the image, it's very testy trying to set up the masks when the slider wants to step at 0.1 intervals, leaving you to hard set each mask setting until you find something you like. It's time-consuming. And also because the colour is clamped you get hard bands and mask cut-offs cause there just isn't enough data for smooth transitions. I mean maybe if I went into the 0.00001 range but that's even more area of tweaking to hopefully find something right, which requires test renders in between on a slow Path Tracer renderer.

…

On Mon, Dec 13, 2021 at 5:19 PM smcameron ***@***.***> wrote: As a sort of proof-of-concept, the following shader change in SNIS: diff --git a/share/snis/shader/textured-cubemap-and-lit-with-annulus-shadow-per-pixel.shader b/share/snis/shader/textured-cubemap-and-lit-with-annulus-shadow-per-pixel.shader index c8fb021..72d6307 100644 --- a/share/snis/shader/textured-cubemap-and-lit-with-annulus-shadow-per-pixel.shader +++ b/share/snis/shader/textured-cubemap-and-lit-with-annulus-shadow-per-pixel.shader @@ -198,6 +198,14 @@ gl_FragColor = textureCube(u_AlbedoTex, v_TexCoord); + float bbr_attenuation = gl_FragColor.r + gl_FragColor.g + gl_FragColor.b; + bbr_attenuation *= bbr_attenuation; + bbr_attenuation *= bbr_attenuation / (27.0 * 9.0); + vec3 bbr; + bbr.r = 0.3; + bbr.g = 0.05; + bbr.b = 0.0; + bbr *= bbr_attenuation; #if defined(USE_SPECULAR) vec3 white = vec3(1.0, 1.0, 1.0); float not_clouds = 1.0 - smoothstep(0.8, 1.0, dot(gl_FragColor.rgb, white)); @@ -205,6 +213,7 @@ gl_FragColor.rgb += specular_color * mostly_blue * not_clouds; #endif gl_FragColor.rgb *= diffuse; + gl_FragColor.rgb += bbr; /* tint with alpha pre multiply */ gl_FragColor.rgb *= u_TintColor.rgb; yields this: [image: brown-dwarf] <https://user-images.githubusercontent.com/23912/145914964-787f9353-0243-46f7-91db-1367400e11b0.jpg> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIZEZOFGCY3A5LOCJRIOP3UQ2LQPANCNFSM5J64YRLQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Sincerely, *Jordan S. C. Thompson *

[smcameron]

Alright... I have no experience with terragen, so it's hard for me to follow. But, really, this seems like we're fighting limitations of terragen. The vast majority of images on the internet have the limitation that RGB values are limited to 0-255. Every png or jpg has this limitation. gaseous-giganticus has this limitation internally. If anything, I'd be inclined to embrace this limitation and perform color mixing using fixed point integer arithmetic for a speed boost rather than the current solution of doing color mixing via 32-bit floats. What you're suggesting is, first of all, incoherent. I don't actually know what it is that you are suggesting. But second, it's somewhat clear that you're wanting more precision than can be offered by 3 bytes of RGB. Which means (supposing I could decipher what you're actually requesting) slower performance (probably much slower performance) traded for higher fidelity... fidelity to an arbitrary process that does not actually correspond to a proper physical simulation, I might add.

Why should I pursue this? It's contrary to my own goals (my instincts are: improve performance of color mixing by using fixed point math instead of floating point math to make everything faster). You're like, let's make everything floating point for more precision. Well, why the fuck should I do that? Why?

WHAT PROBLEM ARE YOU TRYING TO SOLVE!?!?'

You need to stop trying to prescribe the solution to the problem you are trying to solve, and instead describe the problem you are trying to solve.

WHAT ARE YOU TRYING TO DO?

Give me another bullshit oblique sideways answer, and I'll fucking ignore you forever.

[WASasquatch]

You don't seem to need to be pursuing community development with your attitude. And maybe you should just look into non-rasterized rendering methods and 32 bit assets...

[smcameron]

Thanks for answering none of my questions and just marking my comment as "disruptive". Fuck off, you big baby.

[WASasquatch]

Well, yeah, for behavior like this. As anyone should. Be respectful, and civil in matters.

There is no way for me to explain a concept you are wilfully ignoring to be condescending about "your" software on GitHub. Look into 32bit assets for colouring, compositing, and displacement in 3D software. Simple as that really. I can't make you understand the benefits of this in production, and it's a shame you're acting as you are. You had good ideas.