next »

[JobLeonard]

Dang, you really nailed that snow shader - I can practically feel it melt on my skin when I see it build up

Thanks! I spent a bit of time on it, I think what sells it most is the fake subsurface scattering on the snow.
I used a modified version of this algorithm which uses a 'thickness map' to determine how much scattering of light there should be.



Instead of generating the thickness map manually, the thickness is actually just the snow height!

I also tried a version which used textures but it ended up looking bad with the art style.
So the snow is entirely without any textures and is lighting and shaders only.

Welcome back, and happy new year! Looks fantastic. I'm heavily biased in favour of snow in games—I really find it lovely. The new fog/distance effect looks great as well, but I think it was very cool before too. Each has its own charm.

You'll still see the harsher gamma lighting fog in some areas of the game. I can actually reproduce that effect pretty easily with the new linear lighting fog.
Primarily the advantage of the linear lighting is that it gives me more artistic control over the scene.

The snow shader is lovely and this whole devlog seems amazing. I'm looking forward to reading it entirely with a cup of coffee.

Outside of keeping certain critical elements like the fog/distance art style, puzzles about black holes (in some shape or form), and an emphasis on interconnected level design, the game has changed radically.   

Everything prior to about 2018 was mostly prototype and exploratory work. There wasn't even gothic architecture in the game until late 2017, and the game didn't have the alternate universe idea until mid 2016, yet this DevLog dates all the way back to 2014!   
Definitely be prepared for a big cup of coffee and a winding road, ha.

> Instead of generating the thickness map manually, the thickness is actually just the snow height!

Aaaah, good old "we can simplify our problem (and therefore solution) for this use-case"-based approximations. Love it!

[Schrompf]

I love the technicality in this devlog. And that it's void of PR speech. Subsurface Scattering was on my ToDo-List for ages, yet I never got around to do it. Yours is well done!

[Mark Mayers]

Aaaah, good old "we can simplify our problem (and therefore solution) for this use-case"-based approximations. Love it!

Yea, I was pleased with how it turned out. Took a bit of getting the 'magic numbers' right in the shader but I think it looks decent.

I love the technicality in this devlog. And that it's void of PR speech. Subsurface Scattering was on my ToDo-List for ages, yet I never got around to do it. Yours is well done!

 

[Mark Mayers]

Update 160: 02/05/2021

STORM SYSTEM



Recently, I created a storm system for Desolus. These chaotic storms happen periodically throughout the game.
I imagined an apocalyptic feel, as if nature is lashing out. Sometimes the lightning will even destroy buildings!

---

CREATING LIGHTNING



Did you know there are several different types of lightning?

Originally, the lightning was generated randomly. However it didn't look as convincing this way.
Instead, I did some research on how lightning works in real life.

From a simulation perspective, I divided up lightning into 'Leaders' and 'Cloud to Ground' and made the system generate lightning with a probabilistic model.

The logic behind the thunderstorm code itself is fairly simple.

• Leaders: Have the chance to spawn additional leaders in a similar position and direction. Also, every leader has a chance to spawn Cloud to Ground lightning
• Cloud To Ground: Created when there is an object beneath a leader. Its strike point is determined by a raycast.

For the wind, clouds, and snow, I was able to leverage all of my previous work on the sky system.

---

[Mark Mayers]

Update 161: 02/25/2021

DESTRUCTION SYSTEM



I've been working more on my destruction simulation script, which I created last May.
This is the primary script I use for level design in Desolus, as it pre-fractures meshes so they can be used with the game's black holes.
As I mentioned previously, all of the meshes are procedurally generated from within the destruction script, and then reassembled accordingly.

This script was very robust, and turned out to be a great level design tool. However it was very slow running in editor due to the sheer volume of computations required.

In a short explanation, the script is looping through 2,000 meshes which comprise that cathedral, and 30,000 meshes which are the fractured “chunks” of those 2000 meshes.
To determine which chunks are within the boundaries of the green boxes, an algorithm computes the bounds and compares them to each chunk’s vertices.
It deletes the chunks which are in bounds and then reassembles the meshes back together with the remaining chunks.

Given the amount of meshes and vertices, this used to be pretty slow running on a single C# thread.

I decided it was in need of a speedup!

---

UNITY JOBS SYSTEM



I've been glancing at Unity's Jobs System for quite some time, but haven't had the chance to use it until now.
After spending some time the last several days, I ported my destruction simulation to the Jobs System.

It was fairly complex to port. The Jobs System only takes non-managed types, so you can’t give it a native array of arrays or anything.
Only non-managed types, like structures comprised of primitives, or simply primitives, are supported.

I had to redo all the internal logic for iterating over the meshes, to ensure they are done all at once, rather than one by one.

This was tricky because I had to take ALL mesh’s vertices, and plop them into the jobs system into a single native array.
Vertices had to be indexed by a value which determines which vertices belonged to which meshes.
After the bounds computations are done, the data needed to be reassembled back together using a complex loop.

Additionally, I had to reprogram all of the script's methods to be Editor Coroutines, because the Jobs System runs on an asynchronous thread.
The coroutine approach was necessary so the Jobs System could finish computing data, before the script performs Monobehaviour tasks. Previously, all of the methods were done on the main thread.

The results of all of this effort was fantastic!
 
The script running through a combined total of 16.3 million vertices, and 32.7 thousand meshes, in FOUR SECONDS!
This used to take TWENTY MINUTES.
 
Combined with the burst compiler, the jobs system parallelized it and made it super speedy.
I'm extremely excited because the time spent on this optimization will pay back itself several times over!

If you're looking to get started with the Jobs System I would recommend:

• The Jobs System Tutorial from Jackson Dunstan
• The Jobs System Tutorial from Catlike Coding
• The Bust User Guide from Unity

---

[oahda]

That's amazing! The cathedral is really pretty too, don't think I've commented on that before. Thanks for the writeup and the links! This devlog just keeps on giving.

[Mark Mayers]

That's amazing! The cathedral is really pretty too, don't think I've commented on that before. Thanks for the writeup and the links! This devlog just keeps on giving.

 

[Mark Mayers]

Update 162: 03/08/2021



I recently retuned the fog in Desolus to be more appealing and realistic.
The game now has a simple atmospheric scattering model, which nicely blends the fog with the skybox.

This gives a more realistic look for the skybox, but also will blur objects with high fog density.
You can see how the fog will blur the environment as a storm approaches and the density increases.

This is created in a post-processing shader, by applying a scattering blur relative the the camera's fog amount and depth buffer.

The effect is fairly convincing, and it improves the game's overall art style.  

---

COMPARISIONS



September 2020: Oldest sky rendering with Gamma space colors.



February 2021: Linear space colors. Notice how the color doesn't blend properly with the sky and there is no blur.



March 2021: The skybox is now blends with the fog, with subtle scattering and blur based on fog accumulation.

---



Zoomed in comparison of the three fog systems for distant objects. Object silhouettes are vastly improved!

---

[Schrompf]

The comparison images are really telling. Thanks!

[JobLeonard]

The middle one also has a charm of its own, I have to say. It implies things that are distant are glowing

[Mark Mayers]

The comparison images are really telling. Thanks!

The middle one also has a charm of its own, I have to say. It implies things that are distant are glowing

Fortunately this is easily configurable by adjusting the skybox's fog blending.
Currently it's set to an arbitrary value (like 1.3x the fog) but I can set it to a lower value so the sky is darker than the fog.

However, I can't think of any circumstances where the fog would be lighter than the sky in real life?
This is why the game always looked a bit off perhaps. However this approach still maintains the art style.

I may make future areas of the game have darker sky but brighter fog like before, for that surreal effect.

[JobLeonard]

> However, I can't think of any circumstances where the fog would be lighter than the sky in real life?

Light sources on the ground might do it.

Also, you're making a surreal puzzle game, you're free to bend physics to fit whatever aesthetics you're going for, no?

[Mark Mayers]

Also, you're making a surreal puzzle game, you're free to bend physics to fit whatever aesthetics you're going for, no?

Absolutely, I think it's important to master the fundamentals but not hesitate to bend reality to your artistic vision.

[Mark Mayers]

Update 163: 04/23/2021

Some new screenshots to show all of the art improvements over the last few months.

[JobLeonard]

They're all amazing, but something tells me the third and fourth screenshot will look absolutely mindblowing in motion

[Mark Mayers]

Update 164: 05/25/2021

GAME DIRECTION AND PORTALS

Since 2018, I have revised most aspects of design in Desolus. As I explained in my DevLog about revising black holes in the game, I took a similar approach when redesigning portals.

One criticism I received is that Desolus was too abstract, too alien, devoid of narrative context. After receiving this constructive criticism, I pivoted my game’s design and themeing to something less abstract, while still retaining its unique elements.

As the game’s narrative and vision solidified around ‘Explore a city of Gothic architecture, which is torn between universes’ at the end of 2018, I had to revisit a lot of the game’s mechanics. My vision for the game is you are exploring a city which has gone through a dimensional cataclysm. The black holes, the portals, the alternate universes, these are all natural occurrences. I wanted these elements to feel like hurricanes, tornadoes, earthquakes, etc, but on a cosmic scale.



The Great Day of His Wrath, John Martin 1851–1853

---

REVISING PORTALS

Previously, portals between universes in Desolus were only triangles. I chose this shape during my original prototype back in late 2016, I think largely because having a primitive shape felt bold and alien, something like the black monolith from 2001 A Space Odessey.



However, since I strayed away from the pure science fiction genre of the original design, I realized portals could no longer be a primitive shape, and had to feel more organic.

Additionally, only having a single shape for the portals was constraining from a puzzle design perspective. I looked towards various inspirations in art and cinema.

---

NEW DESIGN

I wanted portals to feel tears in the fabric of space and time, something unstable and cataclysmic. Instead of simply a flat surface, portals needed to look like three-dimensional holes which can open and close.

I believe this version of portals accomplishes this goal! However there is always more work to do.



---

[JobLeonard]

Looking good!

I do miss the "window into a completely different landscape" aspect from the first portal, but I think that's just a coincidence due to which two scenes the portal happens to connect, right?

[Mark Mayers]

Looking good!

I do miss the "window into a completely different landscape" aspect from the first portal, but I think that's just a coincidence due to which two scenes the portal happens to connect, right?

I find it funny you say that, because in the first version of the portal it’s exactly the same objects and terrain but a different color.
In the second portal gif all of the buildings are destroyed. The trees and terrain are also different but it’s hard to see from that gif.

However the two universes are meant to look similar through that particular portal, to establish “you’re visiting an alternate version of the same place.”

[JobLeonard]

Ah, I see now! I think it's the glowing trees that threw me off. I didn't see their non-glowing counterparts, making the contrast much bigger

[oahda]

That's so pretty. Looks like an ink blot spreading out.