Forem: Charles Zhang

Observation 20251110: Cities: Skylines II

Charles Zhang — Mon, 10 Nov 2025 13:26:10 +0000

Commercial game: costs lots of money, no doc, hard to mod, no data transparency, no user guide, learning is hard, takes lots of effort to make things, end result is not mine.

Open source (if available): well documented, source available, data transparent and easily edited externally, do whatever you want.

Observation 20251109: Genie 3

Charles Zhang — Sun, 09 Nov 2025 18:37:40 +0000

Here is a simple way to understand Google's Genie 3 - it's Image-to-Video at real time with automatic directional prompts.

It will become useful when retention span is 1 hour - at which time human operators will be able to extract meaningful information from the generated result.

A simpler approach though, would be to allow existing image generators to perform such spatial manipulations on images directly.

DevLog 20250921 HD World Base Map

Charles Zhang — Sun, 21 Sep 2025 14:25:55 +0000

Overview

High resolution base map workflow with Fantasy Planet Painter:

Base (edit) map
High-res export

Results

A significant improvement is the sense of scale - previously at low resolution it seemed a pixel represents a single mountain, while now it's clear a single pixel represents a mountain range.

Remarks

From here we can speculate that for the purpose of having accurate sense of scale, we should generate maps at such resolution that it's clear from the variation of the height the final pixel represent corresponding geographical features at corresponding scale.

DevLog 20250917: Godot Limitations and Rendering Challenges

Charles Zhang — Thu, 18 Sep 2025 18:48:25 +0000

Overview

Today I had a simple idea: to recreate a CryEngine-era starter template island (it's strange that all those CryEngine goodies have vanished - otherwise I'd just link a YouTube video) in Godot, as a kind of inspirational playground.

A modern equivalent would be something like this open-world landscape environment.

The idea itself is straightforward:

A 2 km x 2 km island
Millions of trees (tall, short, and shrubs)
An ocean
A sky

The Challenge

Creating the island itself was easy. The problem came when I tried instancing around 10,000 trees. Each tree mesh had about 240K faces, and even in Blender, instancing them with linked copies slowed the editor to a crawl (not surprising, though I had forgotten how slow Blender can get - that's why I once experimented with Clarisse).

Importing that into Godot proved impossible: the .blend file was only 6 Mb, and the editor just hung.

When comparing 5,000 MeshInstance3D objects with 5,000 instances in a MultiMeshInstance3D, the performance gain was minimal. This reminded me of a fundamental problem I'd almost forgotten: even if you reduce draw calls, fragment shading still happens, and rendering all those meshes at once causes severe overdraw.

So, does this mean densely populated environments are not trivial in Godot? I do miss Unreal's shadow quality, but when it comes to large worlds, its automatic HLOD optimizations start to look tempting again.

Then I remembered all the headaches with Nanite, Lumen, and other Unreal frustrations.

Am I doomed?

Future Work

As it turns out, Godot does support HLOD, along with plenty of optimization options.

Ultimately, everything depends on the purpose and final effect. There's no free lunch. This also highlights how little raw GPU processing power has advanced for single workloads - despite the massive petaflops of modern DGX systems, most of that is geared toward distributed or server-scale computing.

If the goal is a stylized, large-scale world with detailed models but limited materials, Godot can probably handle it just fine.

DevLog 20250916: [Issue] Binary Design Project Version Control

Charles Zhang — Tue, 16 Sep 2025 23:30:36 +0000

Overview

Not having a way to back up and "go back to any time" has the issue of:

Not having a sense of security of "completely restore" something
Not having point-in-time reference, and thus needing to make manual "progress records"
Generally hurdle iteration since we need to worry about "keeping old stuff" for latter use

Existing "Strategy" (Not Working)

We could pack everything in VHDX and archive the whole thing on cloud store (like our backup strategy) or HHD, but it's not efficient, especially since design projects can easily become very big - that creates the issue of having to carefully plan "revision points".

The Verdict

We don't want to waste time expanding cv and develop our own - it seemed Perforce is a must have. On the other hand, it's time to try git + LFS again, if we use it carefully, it's certainly better than having no version control at all for design projects.

On the other hand, Fossil is a great single-user alternative that neatly stores everything in a single SQLite file. Fossil doesn’t attempt to diff or merge binaries; it just versions them, with history, commit notes and tags. Its main limitations in:

SQLite BLOB Size Limit: SQLite, and therefore Fossil, has a practical limit on the size of individual BLOBs, which is around 2GB. This means individual binary files larger than this limit cannot be directly stored within Fossil.
Performance with Numerous Large Binaries: While Fossil can handle binary files, a large number of very large binary files can impact performance, especially during operations like cloning, syncing, and committing, due to the single-file repository structure and the need to manage large BLOBs.

Compromised Strategy

Strategies for Managing Large Binary Files:

Unversioned Files: If historical versions of certain large binary assets are not critical, they can be managed outside of Fossil as unversioned files.
Repository Segmentation: For projects with a substantial amount of large binary data alongside source code, consider separating the project into multiple Fossil repositories. One repository could manage the source code and smaller assets, while another could handle the large binaries, potentially with scripting to maintain alignment.

Repository segmentation is slightly easier to do with Fossil, but still doable with Git (just ignore and don't commit things as submodules).

The Experimental Proposal

Since most of my game projects already use Git, and it's a bit confusing to add LFS, I decide to give fossil another try, specifically for overall (non-code) binary version control.

So the final toolset looks like this:

Git: text sources, as usual
cv: Quick version changelog of everything
Fossil: Single-file binary versioning
Manual whole-disk cloud background: last-resort contingency plan

DevLog 20250912: Issues with Azure DevOp

Charles Zhang — Fri, 12 Sep 2025 20:58:56 +0000

Even Before Everything Else

In the very early days, our load taking system is highly scattered in scattered file system files It works well on Linux but doesn't work on Windows Later we used YNote, which had serious migration problems.

After that we had KMD.

Two modern variations are dated notes and also simple flat lists of to-do items (both of which are in Markdown) which we will not provide examples here.

The Old System

Based on previous experience at BBI, I devised a costume ticket-based task management system. It works very well but requires a bit more manual bookkeeping.

After using it for a while, I decided to merge everything into a single markdown file and eventually decided to try ADO for small scale personal projects, as long as other larger scale collaborative production projects, for easier and more contextual linking between tasks/tickets.

The New System (Now Depreciated)

Azure DevOp is a very useful sophisticated task management system suited for agile project management and for team work I honestly think there is no better alternative, despite poor integration with git (and I doubt many would use its own repo management system).

For personal projects, there are may serious issues:

Complicated project setup, impossible to change project type after creation, unclear conventions (e.g. priority number), impossible to configure enums.
The GUI is too complicated and even for production use, the search functionality is not very predictive. On the other hand, when it comes to have an overview of all the task items, it's not very clear what are the key information.

ADO supports sophisticated APIs, but it's not worth it for custom projects to develop for it.

Travelling Back

Now, we are trying to migrate back to the ticket based custom system for easier version control and oversight, and local file system searchability.

DevLog 20250912: Rapid Creative Priming

Charles Zhang — Fri, 12 Sep 2025 11:13:11 +0000

Overview

As a creative worker and novelist, "getting into the mood" often takes time and effort. In the past, without concrete workflows, inspiration arrived randomly — for example, I used to watch entire movies just hoping to spark ideas. Nowadays, however, I have methods that can quickly "tune my brain," as illustrated in the note below:

(Think along those keywords) "坦克轰隆隆", "old-fashioned physical activities"
(Think along 2015 "Era 1" original dream series)
(Think along those keywords) Medieval villages, gothic towns, historic sites
(Think along artistic styles defined in "20221208 Technology Style Genres")

It feels almost magical — a unique phenomenon.

Concept – Rapid Creative Priming

I’m fairly sure others have identified similar techniques. Since I lack formal systematic training in creative work, I don’t know the technical term for these "short statements" that can instantly shift one into a creative mindset. For now, I’ll call this practice rapid creative priming: small cues that help you slip into the right imaginative state.

Drawing on concepts from psychology, creativity studies, and writing practice, I’ll illustrate how this works:

1. Creative Prompts

In writing communities, these short statements resemble writing prompts — brief cues, images, or scenarios meant to spark imagination.

Traditionally, prompts are designed to kickstart a scene or story, but my examples seem more focused on evoking a mood rather than a plot, which is a subtler use.

2. Priming Cues (Psychology)

In cognitive psychology, this falls under priming: exposing the brain to specific words, images, or ideas that bias it toward certain associations.

In my case, these statements act as creative priming cues — they activate mental schemas (e.g., childhood nostalgia, gothic towns, peaceful rural activities) that "tune" my mind into that aesthetic space.

3. Mood Boards (Textual Form)

Designers and visual artists often use mood boards — curated collections of images or textures that capture a tone. What I have is essentially a verbal/textual mood board: compact textual triggers instead of images, but serving the same role of setting a consistent emotional/creative atmosphere.

Personally, I find this form more inspirational than visual cues for novel work, since images can feel "too much" and become distracting.

4. Incantatory Triggers

Some novelists and poets describe repeated creative cues as charms or incantations. It’s not a technical term, but it captures the ritualistic aspect: by revisiting a phrase ("坦克轰隆隆," "old-fashioned physical activities"), you summon an entire sensory-emotional world — almost like casting a spell.

5. Heuristics or Creative Constraints

Another way to frame these is as heuristics — rules of thumb that guide thinking — or as creative constraints. By narrowing attention ("think rural, tactile, peaceful"), we reduce the paralysis of a blank page and channel ourselves into a fertile imaginative corridor.

This may be why I intuitively wanted to call them "directives."

Summary

The Creative Priming Statements or Mood Cues are short, textual triggers designed to align the brain with a productive imaginative mode.

As for visual cues, a commonly used tool in the concept design community is PureRef. It’s excellent, but I’ll give one warning: it requires carefully tuned workflows; otherwise, it can become a severe distraction.

DevLog 20250720: Solar System Simulation

Charles Zhang — Sun, 20 Jul 2025 22:09:40 +0000

Simulation 20250720172759

Video: YouTube

DevLog 20250719: GIS, Geographic & WGS84

Charles Zhang — Sat, 19 Jul 2025 13:51:12 +0000

Geographical Patch Workflow

Local Area WGS84 Workflow

DevLog 20250716: Note Taking and Precision Requirements

Charles Zhang — Wed, 16 Jul 2025 11:39:10 +0000

Earlier (2023) my notes are mostly fragmented conversations, settings, dialogues, plots - they were content related.

Nowadays my notes are mostly world background, timeline, events, entity definitions - "fact"-based.

The problem with fragmented ideas were hard to consolidate; The problem with designs are, there is no story. It would be ideal to just focus on writing coherent single-flowing stories.

On the other hand, world building is putting demands on scale, and scale requires precision - like making a proper world map, or clearly understand the relationship between people.

DevLog 20250713: Development Speeds

Charles Zhang — Mon, 14 Jul 2025 01:14:31 +0000

Incrementals (per iteration):

1-3 hr: rough layout, 1/3 of paper sketches, some collision and navigable environment, maybe plants and nature setup as well. An entire afternoon/day will give better sense. Original content: ~4-5Mb.

I suppose one week (half time) can emit usable scale environment, without functional scripting.

DevLog 20250713: Perspectives of MWS

Charles Zhang — Mon, 14 Jul 2025 00:34:01 +0000

There is a perspective shock and big difference seeing things in MWS than in Blender - even though precise measures already result in predictable sizes.

It's more straightforward to appreciate how much empty space we have, what placements could have been arranged - how tall things really are.

It seems when we start to add more color and textures, the perspectives will only get better.