I need your help with graphics!

edited May 2020 in General
We have almost no graphic effects: atmosphere, sun blur, etc. The main hold up is my ignorance about graphics and lack of time to learn.

What we do have are data/code systems for implementing these effects. So, for example, if someone told me parameters (on a material or whatever) need to be set to give Titan a thick atmosphere, or to have icy Enceladus sparkle, or how to make the Sun's light blur or overexpose the camera, I could have it implemented quickly...

I, Voyager builds everything from csv text tables in ivoyager/data/solar_system/. In here you can find models.csv with keys that describe "model type", e.g., rocky, continental, thick atmosphere (e.g., Venus, Titan), desert, gas giant, ice giant, etc. Each star, planet and moon (and eventually asteroid, comet and spacecraft) is assigned a model_type.

Right now, models.csv defines only a few parameters (metallic, roughness, rim, etc.), and even these are just my ignorant default values. I would like to expand this table. This is where I need your help! What material settings do we need for different world types? How do I make an atmospheric effect? And so on...

There are two other tables, environments.csv and lights.csv, that are only placeholders now, but are intended to have parameters for the Environment and the Sun's OmniLight, respectively. This is where we would add parameters giving sun glare, camera overexposure, etc. However, I need some guidance on how to do this.

The aesthetic I want for I, Voyager is a sort of "hard realism" (what comes to mind are videos of Elon Musk's roadster in space). Of course, the reason I'm doing this via text data tables is so you (or possibly your future game modders) can change it to whatever style you need for your own project!  


  • edited April 2020
    Good tips here! This is all on my reading list now...

    croxis said:
    The goal is to recreate the effects of atmospheres during daytime and at the terminators. Earth is blue sky during the day, red at the terminator. Mars is reddish pink during the day, and blue skys during sunset/rise. Its a combenation of light scattering based on the composition of the atmosphere as well as rayleigh and mia scattering from particulates. This also colorizes and fuzzies surface textures when viewed from lower orbits.

    The two major families of atmospheric rendering is Sean O'Neil's work, which is older and simpler, and Bruneton's more complex method that involves calculated lookup tables. I also found this very large tutorial on the implementation and math.

    The best premade resource I found is this one. There is a shadertoy to play with the parameters. The only gotcha is that I do not know where to look up the reyleigh and mia parameters for different planets. How far into the spectrum light gets scattered is based on the polarization of the gases (or so my quick research shows). The ideal solution is that the parameters can be generated based on atmospheric composition, which makes it easier for procedural planets.

  • edited April 2020
    I have some code that converts star surface temperature to RGB color space to simulate blackbody emissions: https://github.com/croxis/SpaceDrive/blob/master/spacedrive/utils/blackbody.py

  • (distract while typing, sorry about grammar) A better solution for rendering different surface types are texture maps. Earth is the best example as we have the most diverse surface: Ice, liquid, continents, and glowing city lights at night. Most of this could be done by a reflection (specularity [sp]), glow maps (city lights). This could be done with a second texture with these values assigned to R, G, B, and A channels, or four separate grey scale images.

    Going with pbm the four properties can be assigned to textures, shaders, or in the case of simpler worlds a single value from a cvs can be passed. Glow map would be needed for city lights at night, or lava pits on io.
  • edited April 2020
    To get to your last point (before I've read everything else) I've always anticipated having multiple textures per world. So in ivoyager_assets/globe_wraps/ you'll see that all texture names are of the form: "<file_prefix>.albedo.<other_info>.jpg" (e.g., Earth.albedo.nasa.land_ocean_ice_cloud_4k.jpg). These file resources are "discovered" during solar system build based on the file_prefix (there is a fallback if not found) and "albedo", and applied by the Model object (tree_nodes/model.gd).

    So yes, we could add Earth city lights. Maybe multiple cloud maps that change. Normal maps for bumpy worlds. And so on...

    I'm working hard to get all the infrastructure in place so that it is easy to add this stuff. 
  • I addressed the city lights and cloud maps issue in my post under the "Future Ideas" thread. But I figured to mention here that, for my add-on, I am planning to make a half-dozen generic asteroid meshes with some equally generic textures, one or two per asteroid type. These would be semi-fictitious, of course, but maybe they could be useful for I, Voyager in the same vein as Celestia's limit of knowledge vs. interpretive (artist's rendition) textures.
  • "Interpretive" assets probably works best as an addon (if you plan to share it). They can be in a directory anywhere. Based on my latest updates, I'm thinking of a fall-through array in Global (a settable project var) that tells ModelBuilder where to search for a body's model in order of priority. It already does this to some extent. It looks for "Earth" in the models directory; not finding it there, it builds a generic ellipsoid model and tries to find a map in world_maps (if it didn't find that, it would get the generic grey grid pattern). 
  • edited May 2020
    I can't figure out why we don't have shadows! OK, setting the sun's OmniLight.shadow_enabled = true was probably a good start. The latest master branch has that.

    All of our GeometryInstances (worlds and Saturn's rings) have default cast_shadow = 1.
    All of our SpatialMaterials (world & ring textures) have default flags_do_not_receive_shadows = false.

    I played around with Light.shadow_bias. According to the tutorial, I ought to be able to create "self-shadow" artifacts by setting that too low. But no, I can't even create shadow artifacts...

    What am I missing?

    Edit: I opened this as a Bug Report in our issue tracker.
Sign In or Register to comment.