Day/Night/Weather-System with im.ColorMatrix-Shaders?

[gamedriver]

Hello everybody,

at the moment I am exploring the im.MatrixColor-manipulators. It seems to be quite easy to construct a kind of lighting system which reflects the hour of the day, the month and also the weather situation graphically. So I need only one .png for each image (plus a handful for the correct weather sky for all the game), and depending on the actual situation the shaders will give the correct impression for the scene (darker at night, during winter, and at bad weather etc.).

I am aware of some of the potential problems. For example the shadow prints drawn in the picture would not be correct without sunlight etc. Nevertheless I guess this could work well.

My questions:

1) Has anybody tried this before? I have´nt found anythin in the forum, only this nice tutorial of TWO AND A HALF STUDIOS:
https://www.twoandahalfstudios.com/2019 ... with-renpy

2) Are there any potential drawbacks or dangers connected with the extensive usage of these manipulators which I am not aware of (memory usage or such?). I have very limited experience up to now and don´t want to create something which will cause problems later on and has to be reworked completely.

Here some snippets of the code for illustration:

Code: Select all

init python:
    name_weather   = ["storm","rain","overcast","cloudy","clear","sunny","Bright"]       ## loads the correct sky pic
    bright_weather = [-0.30, -0.20, -0.10, -0.05, -0.00, -0.00, +0.05, +0.15]                   ## changes in brightness
    ...
    ## same for the addable brightness changes for the hours of the day and for the months of the year - and additionally for the tints, contrast, saturation values)


screen Show_All:
    fixed:
        add im.MatrixColor(
            ("work/ls_test_sky_" + name_weather[weather] + ".png"),
            im.matrix.tint(1 + tintr_hour[hour] + tintr_month[month] + tintr_weather[weather], 1 + tintg_hour[hour] + tintr_month[month] + tintr_weather[weather], 1 + tintb_hour[hour]  + tintr_month[month] + tintr_weather[weather])
            * im.matrix.brightness(0 + bright_hour[hour] + bright_month[month] + bright_weather[weather])
            * im.matrix.saturation(1 + saturat_hour[hour] + saturat_month[month] + saturat_weather[weather])
            * im.matrix.contrast(1 + contrast_hour[hour] + contrast_month[month] + contrast_weather[weather]))
       ...
       ## same for all displayables of the screen, i.e. background landscape, foreground buildings, character sprites etc.)


label Show_It:
    ...
    show screen Show_All
    ...

Thanks a lot!

[Andredron]

Hello everybody,

at the moment I am exploring the im.MatrixColor-manipulators. It seems to be quite easy to construct a kind of lighting system which reflects the hour of the day, the month and also the weather situation graphically. So I need only one .png for each image (plus a handful for the correct weather sky for all the game), and depending on the actual situation the shaders will give the correct impression for the scene (darker at night, during winter, and at bad weather etc.).

I am aware of some of the potential problems. For example the shadow prints drawn in the picture would not be correct without sunlight etc. Nevertheless I guess this could work well.

My questions:

1) Has anybody tried this before? I have´nt found anythin in the forum, only this nice tutorial of TWO AND A HALF STUDIOS:
https://www.twoandahalfstudios.com/2019 ... with-renpy

2) Are there any potential drawbacks or dangers connected with the extensive usage of these manipulators which I am not aware of (memory usage or such?). I have very limited experience up to now and don´t want to create something which will cause problems later on and has to be reworked completely.

Here some snippets of the code for illustration:

Code: Select all

init python:
    name_weather   = ["storm","rain","overcast","cloudy","clear","sunny","Bright"]       ## loads the correct sky pic
    bright_weather = [-0.30, -0.20, -0.10, -0.05, -0.00, -0.00, +0.05, +0.15]                   ## changes in brightness
    ...
    ## same for the addable brightness changes for the hours of the day and for the months of the year - and additionally for the tints, contrast, saturation values)


screen Show_All:
    fixed:
        add im.MatrixColor(
            ("work/ls_test_sky_" + name_weather[weather] + ".png"),
            im.matrix.tint(1 + tintr_hour[hour] + tintr_month[month] + tintr_weather[weather], 1 + tintg_hour[hour] + tintr_month[month] + tintr_weather[weather], 1 + tintb_hour[hour]  + tintr_month[month] + tintr_weather[weather])
            * im.matrix.brightness(0 + bright_hour[hour] + bright_month[month] + bright_weather[weather])
            * im.matrix.saturation(1 + saturat_hour[hour] + saturat_month[month] + saturat_weather[weather])
            * im.matrix.contrast(1 + contrast_hour[hour] + contrast_month[month] + contrast_weather[weather]))
       ...
       ## same for all displayables of the screen, i.e. background landscape, foreground buildings, character sprites etc.)


label Show_It:
    ...
    show screen Show_All
    ...

Thanks a lot!

Code: Select all

init:
   image man = "man.png"
   image bg = "bg.jpg"
   $ dt = "morning"
screen daytime:
   if dt == "morning":
     add "# 8404"
   if dt == "evening":
     add "# 0484"
   if dt == "night":
     add "# 000b"
label start:
   show screen daytime
   scene bg
   show man
   "Now is [dt]."
   $ dt = "day"
   "Now is [dt]."
   $ dt = "evening"
   "Now is [dt]."
   $ dt = "night"
   "Now is [dt]."
   return
  
  

[gamedriver]

Maybe I have to explain my question more in detail.

Here are two screenshots taken from a running testgame, showing the same background image files. The first one shows a February night at cloudy weather, the second one noon in July, in bright sunlight. The difference is created only with the shaders. (Not yet really tweaked realistically, it´s just about the principle for the moment).

https://imgur.com/QRDGSLU

https://imgur.com/Lhlu9bi

My impression is that these shaders are not used commonly within the community. Is this correct, and if yes, are there specific reasons to avoid this method?

Thanks and happy coding to all

[philat]

Eh. Image manipulators aren't very commonly used because they only take images, not displayables, and because they're considered relatively expensive (although what that actually means in concrete numbers is beyond me). That said, there's no other feature for what you want currently, afaik.

[rames44]

I used this technique to create “night” versions of images for a project I worked on. Worked fine, as you show in your example. As to performance, we didn’t notice any issues, but this was mostly done for background images, so it wasn’t like we had dozens of them on a single screen. Obviously, there is a runtime cost, because the image has to be processed in addition to being loaded. I don’t know how often Ren’py might repeat that. Could be it’s done before the image is cached. If so, the impact is probably small, since it would (hopefully) be done in the background as part of the image prediction logic.

[gas]

The method is avoided as is quite more convenient to pre-process images than to process them at runtime if the light is static.
I mean: a matrix recolor shader got any sense only if you change colors at an interaction, using GPU shaders, like for interactive lighting in a 3d setting (or some palette recolor for indicized palettes, see old Sega Genesis games).
If the condition is static, is byfar more covenient in ANY possible sense to own 2 pictures.

That's probably a feature of the next Renpy major release.
In the meanwhile, you can try for some external implementation of shaders:
https://github.com/bitsawer/renpy-shader

[rames44]

@gas you are absolutely correct that this approach CAN be avoided by preprocessing the image to create multiple images. No question about it. And that approach almost certainly is more run-time efficient, since images just have to be loaded, not loaded and the processed. Of course, whether the change in processing required is actually significant or not is an open question, and almost certainly depends on multiple factors. (Also, depending on exactly how you manage those images, you may actually be making things harder for Renpy’s image predictor)

However, I’m going to disagree that it’s ALWAYS more “convenient” to do it that way. To me, whether something is “convenient” or not depends a lot on the context of the surrounding software and its design philosophy. In the case I cited, for example, the “night images” feature was added in after the project was well along, and had a significant number of pre-existing images involved. In this particular case, it was a lot more “convenient” to add a runtime post processing step into the project than to go back, rename all the images to conform to a “time of day” convention, update every use of those images to conform to the new convention, etc. So, “convenience,” to me, is very much in the eye of the beholder.

In addition, there’s another trade off, which is space. Having 2 or 3 or 4 versions of an image costs you space. Classic “space-vs-time” trade off. Do I preprocess everything, saving execution time later at the cost of space? Or do I save space and pay for it with extra processing at runtime? If the number of images is small, maybe the extra space cost isn’t significant. But if the number of images is large, this can potentially have a measurable effect on downloadability (“convenience” to THEM) for people who don’t have high-speed internet.

Not trying to start a flame war over this - quite the opposite. Just trying to point out that there are trade offs to almost any choice like this, and what’s right for one developer may not be for another. Thus, IMHO, there’s no single categorically “right” answer to this.

My $0.02, nothing more.

[gamedriver]

Hey, thanks for these insights, very interesting.

My (maybe naive) perspective is that time isn´t that important for a VN, so the process time for the shaders shouldn´t be critical. On the other hand I am working on a system where every screenview is constructed by 30 - 100 sprites, so this may get too hefty nevertheless.

I will try this route and report later on about the results.