Refactoring Rendering

Refactoring day.

A few things I wanted to work on, getting the terrain map showing up on (Snow Map) snowm.app, fixing the lighting, fixing the normals and attempt again at rendering a large map.

First I had to refactor the custom Three JS implementation into something I could share between two projects. The way the project is set up is there’s a monolithic repo containing all my development data tools (snow-data) and another repo that contains the Snow Map site (snow-map). Previously I wanted to share code between the two sites but not been able to. I wasn’t really sure how to set this up. Both projects are now using ESM across all the code (import * from x) rather than the old Node JS CommonJS style (require()).

I’ll try to split the sharable things into a separate repo. The less repos the better, but I’ve still ended up with four:

  1. Base repo containing all parsing, calculation and data manipulation (snow-base)
  2. Mountain renderer containing all the Three JS code to render the scene. (snow-mt)
  3. Vue component for the Mountain render. (snow-mt-vue)

I’m not confident this is the right set up, having less repos would be better in my mind, but I wanted to separate out some Vue dependencies so that if I needed to run snow-mt code outside of Vue, I could still do that.

To install local dependencies using npm, I use:

npm install ../snow-mt

This results in symlinks in node_modules/, and this seems to work fine but I can feel that VSCode is starting to get confused, especially when I search the code base.. I’m not sure how others handle sharing and development. It is more simple when there is a single mono repo. Nice thing is that I can edit everything now in one editor but if there are changes that span across the dependencies and the web UI itself, I need to make multiple commits.

I tried again to render the large multi-mountain map. It is getting very slow when I try to render the single map with just 20 mountains. I’ve run into a data issue already because the same mountain gets rendered multiple times (Niseko) due to there being multiple resorts on that. I need to go back and clean up the data so that when the resort is nearby/connected, we render the single mountain rather than multiple.

Finally, I attempted to fix the lighting on my renders. I thought I could shortcut this by playing with this in Blender rather than in code. My idea was to bring the models into Blender by exporting them in GLTF with Three JS. However, turns out the way I’m using vertex shaders to deform the plane can’t really be exported using GLTFExporter. At one point I had custom vertex mesh generator that happened outside of the vertex shader, but that just created too many vertices and ground Three JS to a halt. I might have to bring that back again.

@liquidx $