refactorings

[davidson16807]

Bunch of stuff happened in my random wanderings across code, now I have to make sense of it all

[astrographer]

A lot of good clarifying refactors, more stuff that I’m sure is terribly useful, but is well outside of my wheelhouse, but that 16 bit depth rendering is what jumped out at me. 32 bit float may be better, but 16 bit makes these elevations directly usable for 3D rendering and maps. Huzzah! And also: thank you, thank you, thank you!!!

On Apr 6, 2018, at 2:44 PM, Carl Davidson notifications@github.com wrote:

Merged #25.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[davidson16807]

Major improvements, as I see them:

• Crust objects are used as deltas There's a few processes that occur every timestep, like erosion or metamorphosis. Each process may affect one or more rasters, like rock quantity or sediment quantity. For each raster, a raster delta would be stored to encapsulate the effect of that process as a series of additions and subtractions. The logic used to apply these deltas was convoluted and repetitive. Adding new processes required custom-made logic to apply the deltas. The change here takes a more general approach: each process stores a crust delta that encapsulates the effect the process has on every raster in the crust. If a process has no effect on a raster, it's simply represented as zeros within the crust object. It's less performant and it consumes more memory, but it greatly simplifies the architecture.

• Abandoning object inheritance in favor of object composition World and Plate objects previously inherited from Crust objects. They no longer do so. Now they store crust information within in a single attribute, .crust. It's often difficult to see the full implications of inheritance hierarchies when they are drafted. This change is meant to reduce mental overhead from working with inheritance hierarchies, and move towards a state where Crust objects play a larger role as simple algebraic structures. This will come in handy, because eventually World objects will no longer be defined solely by their crusts. They will also have information representing the state of their oceans, atmospheres, and biospheres, and rather than store this using multiple inheritance, each subcomponent will have its own object class that will be treated as a simple algebraic object, as with crust.

• simpler, smarter, but less efficient save files We used to care about the size of save files, but we don't anymore. This, combined with fact we're storing Crust objects in contiguous blocks of memory, means we can save the entire state of a crust object using a single line of code that's invariant to adding rasters within Crust objects.

• faster, smarter, but less generic VoronoiSphere lookups VoronoiSphere lookups are at the heart of the model. The model easily does millions of lookups per second. The change here makes lookups faster by assuming that all inputs represent points on a unit sphere.

• RasterStackBuffer It's costly to initialize new raster objects because the interpreter has to free up new memory for it. It's much faster if you have a pool of memory that's already free, however it requires attention to memory management issues. This is what RasterStackBuffer attends to. You can easily create new raster objects from a pre-existing pool of memory, and as long as you make sure to mark the start and end of your functions, you are not likely to encounter problems with memory leaks or collisions. It's basically reimplementing c-style memory management with TypedArrays and ArrayBuffers.

[davidson16807]

16 bit depth rendering is probably not what you think it does. It allows you to create ScalarDisplays using functions that return Uint16Rasters. Uint16Rasters are used to track cell ids within a grid. It previously generated an error when you tried to do this, which was hindering development efforts.

What do you have in mind for 16 bit rendering? I think that might be something we could add in the issue tracker.

[astrographer]

What I’m looking for with 16 bit depth rendering is to return a grayscale raster I can use for bumpmapping. 8 bit bumpmaps tend to produce steps or terraces that aren’t always desirable(there are particular places where terracing is desirable and realistic, but not everywhere). This is because we’re limiting elevations in a roughly 0 to 8-9000 meter interval to 256 discrete steps. With 65,536 steps, any terracing effects tend to be imperceptible. This would allow use of elevation rasters directly in more precise or artistic renderings. The actual slope details might still be on too gross of a spatial resolution due to limitations of computer power. I suspect a global sim with even a 7-km cell size would set my computer on fire and probably even bog down a high end gaming machine. Seven kilometers is a bit of a magic number as that’s what Carl at ME-dem measured as a typical extent for individual mountain peaks. I haven’t measured that myself, so consider that third-person hearsay from memory, but it seems sane.

I already have a workflow that works, but the details generated are entirely imaginary. It’s also slow, but that could just be me. I’m a slow child. An oooolllllldddd slow child…🤪🦆

On Apr 9, 2018, at 9:58 AM, Carl Davidson notifications@github.com wrote:

16 bit depth rendering is probably not what you think it does. It allows you to create ScalarDisplays using functions that return Uint16Rasters. It previously generated an error when you tried to do this, which was hindering development efforts.

What do you have in mind for 16 bit rendering? I think that might be something we could add in the issue tracker.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[davidson16807]

As I understand it, bump maps are color maps where RGB encodes the xyz coordinates of a unit vector representing a surface normal.

Correct?

Sounds like something we could do easy.

Do you know the math required to implement bump mapping? After proper atmospheric models are implemented, I've wanted to improve the shaders used by the model. Specifically, I want to contact the people behind this KSP mod and import the ones they've created: https://github.com/WazWaz/EnvironmentalVisualEnhancements. But if you're a good point of contact then I figure that's a great place to start.

[astrographer]

That’s normal maps. A bump map does essentially the same thing, but the normal vectors are calculated based on elevations.

On Apr 16, 2018, at 3:35 PM, Carl Davidson notifications@github.com wrote:

As I understand it, bump maps are color maps where RGB encodes the xyz coordinates of a unit vector representing a surface normal.

Correct?

Sounds like something we could do easy.

Do you know the math required to implement bump mapping? After proper atmospheric models are implemented, I've wanted to improve the shaders used by the model. Specifically, I want to contact the people behind this KSP mod and import the ones they've created: https://github.com/WazWaz/EnvironmentalVisualEnhancements. But if you're a good point of contact then I figure that's a great place to start.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[davidson16807]

OK, just read up on the distinction. Wouldn't normal maps be easier to work with though, assuming they're pre-generated by the model? We could easily generate tangent space normal maps from local changes in elevation