Suggested Physical units

[Palaxin]

Currently:
As far as I know (I'm still new to the game) physical units are practically not used in the game. Temperature and humidity are values [0..1] (see https://github.com/MovingBlocks/Terasology/wiki/World-Biomes) and there might be other uses.

Proposal:

• implement "real" physical units (define in engine as basic physics or add as module only?)
  • SI base units: meter (m) for length, second (s) for time, kilogram (kg) for mass, kelvin (K) for temperature. Ampere (A) for electric current, mole (mol) for amount of substance and candela (Cd) for luminous itensity are not relevant here at first.
  • SI derived units: e.g. (volumetric mass) density = mass / length^3, velocity = length / time, acceleration = length / time^2, energy = kg * m^2 * s^2, ...
• make a physical units module
  • user can choose from a list of template systems of measurement
    • SI: Système International
    • cgs: centimetre-gram-second
    • "Computer Science": [0..1]
    • country specific unit sets
    • ...
  • user can customize (edit scale and unit name) each unit (or the whole system) and save it
    • again, choose from a template
    • define a custome scale with two fixed values
      e.g. my new temperature unit shall be called "Degree Palaxin" (°P) with 5°P := 273.15 K (0°C) and 15°P := 373.15 K (100°C). Every temperature value is now calculated in °P, so for example 7.6 °P would equal 26 °C. Alternatively you should be able to define the values by specific in-game elements (also from a list) e.g. -10°P := human body temperature and 347.8 °P := dragon fire temperature.
• in game: units aren't visible normally but can be examined with experiments or at specific instruments e.g. workbench, thermometer, scales, ... You could have a book in which all your in-game knowledge is documented. As you discover more and more materials, properties and values, the book will be filled.
• Blocks should have a bunch of units describing their properties, e.g. density, mass, volume, specific heat capacity, burn/melting/evaporation temperature, elastic and shear modulus (for solids), viscosity and pressure (for fluids), ...
  Perhaps also the composition of rocks and ores could be implemented --> useful for sifting in Manual Labor by @Josharias
  

  New mechanism: sifting. Now you can separate out the undesirable substances out of ores using water and a little man power. More polish required still, but it has a fluid display and is "functional".
  View attachment 1586

• Some applications may not be bound to blocks e.g. air pressure as a function of altitude above sea level (would be easier than calculate pressure for each block). Similar for water (but here things get more complex as water boundaries aren't ocean surface in general).
• Internally existing values could be used ([0..1] temperature) and calculated into other units when needed

If someone is keen on implementing my proposal (or parts of it), i could provide the relevant data after some research
I have to get more familiar with the game code and coding in general at the moment...

What do you think?

 

[Cervator]

I think this is a natural fit when we have something to take advantage of it

Currently mostly 0..1 is used since it maps directly to the noise powering all the procedural fun. I'm not actually sure how or if we'd want to move that to SI units. I imagine it is more likely the engine keeps everything in hard technical terms it understands then modules decorate with real terms when needed. I think one of the thermometers somewhere actually displays temperature properly?

As soon as we get more stuff like the kinds of tools you suggest in-game then we can display more stuff in proper units

One thing that's probably more of a decision than a technical piece is finally determining whether or not one block == one cubic meter. That would probably be the most natural connection. However, it again might be a connection to only make in modules, since some contexts might size things differently.

What we need are two probably two things:

• Support for more attributes on blocks. That's likely just adding a new MineralAttributesComponent with a pile of different kinds of data. Unlikely for this to become primitive block attributes - should only be enabled if needed
• A utility module offering conversions and decorations for the sciency stuff, with the option to configure how "big" stuff is in the world, default block size == 1 cubic meter. Then methods like returning formatted distance in meters/kilometers/etc between two positions. This could also be used to turn temp noise from 0..1 into realistic display temperatures. It could even offer an option for the user to prefer display in metric vs imperial, C vs F, and so on.

That way we could start actually putting some of the foundation stuff in-game, making it easier for other modules to build on top. Somebody could add a few debug tools to the utility module to show stats. Existing modules that do their own conversion could have their logic replaced with a dependency on the utility module.

 

[Skaldarnar]

From the technical side, adding attributes to blocks might be a bit tricky currently. As far as I know Delta Updates are not possible for block definitions (*.block) which means you cannot simply add new data to existing blocks.

Thus, the only valid option I see at the moment is to add the physical attributes to Core (if they should be accessible for other modules). Note that a block overwrite will typical loose the data (if not copied by hand).

Until Delta Updates are supported for block definitions we might just assume they are possible and start working on a PhysicalBlockAttributes module, using the delta structure for prefabs as reference.

 

[Cervator]

Well, if we think about the Minerals module specifically, we could just add a prefab for every existing mineral, right? In the same module. With the prefab containing the new attributes in a MineralAttributesComponent. With the right persistence mode they won't get active entities unless interacted with.

If we ultimately favor one giant asset module for minerals we might not need deltas. Any unique new minerals could themselves be defined with a dependency on Minerals, more for its MineralAttributesComponent system/data than the existing minerals. Actually, probably put MAC in a separate module that Minerals itself depends on. Sounds like that could be our "Global Ore Repository" thing that all minerals should be based on.

Yeah we wouldn't want to do actual primitive block attributes, at least not beyond very basic things we still lack (if any)

 

[manu3d]

Hi Palaxin!

Being interested in the educational potential of Terasology I find your proposal very appropriate. Personally I don't think that physical data or even physical simulations should be included in the core. If Immortius says that adding physical attributes to the core is the only way to go, so be it. But I can imagine there are plenty of individuals and eventually server masters who'd be interested in setting up and enjoying a creative setup unimpeded by physics.

For this reason I'd recommend for physics to live as much as possible in modules rather than in the core. Perhaps an exception could be made for pure minecraft-like water behavior (non-mass-conserving), as it is sort of expected out of the box. But more complex behavior and other simulations would be best out of the core, to keep it as lean as possible.

I feel then that physics in Terasology would really arises from two potentially overlapping categories of modules:

1. systemic simulations, i.e. introducing blocks falling in certain circumstances, more realistic water behavior or even geological processes
2. new user-available tools, i.e. tools to measure distances or even complex tools such as a chemistry bench allowing to combine or separate materials to a fine degree

In this context it would be these modules that introduce concepts such as "meters", "kilograms" or even "moles" rather than a generic "physics" module.

Issues could arise for compound units, i.e. forces being measured in kg*m/s^2. If the individual base units are defined across different modules, can the physics emerging by combining the modules be kept reasonably consistent? Or to better put it, how can the core or a "basic physics" module help other modules talk nicely to each other or at least avoid stepping on each other toes?

Perhaps it would be useful if you Palaxin wrote some user scenarios in the form "User wants to do A: he start by doing B, then C and then D". Also consider that in the context of a block world some things might or might not be appropriate. I.e. does it make sense to measure angles if nothing can be rotated in less than 90 degrees? Does it make sense to have a measuring tape if a player can just count the blocks from one tree to the next? So, I think there might be a few more things to think about before any code is laid out.

Still, I think there's plenty of potential and I'd love to see even just conceptual progress in this direction.

 

[Palaxin]

Hi @manu3d,
thank you for your thoughts. To put it in a nutshell: actually my goal is to establish some system that ensures different modules can not interfere negatively. There is no problem with the current 0...1 units (the °C, °F etc. thing in fact should be included in a module). But we should have some standard for scales/units used by core and all modules (even without the physics module). These are not many values. I thought we additionally could give each block type a set of constants describing its properties. It's just important that these properties are expressed in the same scale as used by the world generator for example (temperature 0...1). If we assume 0.5 would be 20 °C (worldGen) but for our blocks we would use 20.0 this would not just be inconstistent but could things make more complicated one day. I know you guys know much more about the game/code architecture than me so if you still think this is no good solution then you are surely right.
I will give more explanations soon. I'm justing writing an exam on Friday and do not have that much time now....

As a start for the physics module: I worked on some maths for the transformation of different scales (this is for the module) and will write some code or pseudocode next... I think I mixed up some terms (in most cases it should be scale and not unit ) Oh LaTeX in the forum would be really nice for that formulae

 

[Cervator]

Nice math, goes beyond what I can parse real quick

I'm pretty sure the noise type values (0..1, -1..1, etc) are here to stay for internal values (basic world gen, data storage, etc). That's a best practice across many, many systems (far beyond Terasology). But higher level world gen could certainly for better human readability say "Desert happens when humidity < 5%" or "Tundra happens when average temp below 0 C". That's sort of half way between the super technical and presentation, and could be defined in prefab-like files meant to be tweaked by human preference. Finally display would surely use proper units.

One thing that's easy to not catch with Terasology I should be sure to explain just in case (you seem unusually on top of all this, but anyway): Our engine is vastly more basic / low level than anything comparable like MC. The goal of the engine is to have effectively no content - not even inventory, world gen, combat, hunger, even the player object. Just frameworks to support implementation for all that. We haven't finished quite tearing everything like that out.

The initial implementation of stuff to get content and usable systems comparable to MC go in a series of modules we expect to always have available, key being they can be overridden, configured, disabled, etc. That series of modules we currently call "Iota" - the minimum viable product, so to say. Something like a physics / units / conversion module would absolutely go in there, and modders in general could expect to have that available, so they could safely write world gen type stuff based on Celsius or other higher level units if they like (for instance if the idea just is to make more granular biomes or add stuff that spawns in certain ranges)

Does that help? Engine stays at noise, Iota can offer units, content modules beyond that can safely expect a single foundational physics/units system is present to depend on