The setup
Last month I wanted a shadow study of Boston Common without downloading LiDAR, learning a full GIS stack, or asking anyone for a license. I ended up with a rough but useful model built from one rectangle on a map. This is the workflow I used, including the parts that broke.
Step 1: Write the question first
My first instinct was to make a model of the park. That is not a question. The useful version was narrower: which surrounding blocks put shade on the southwest lawn at 3 pm in December? Once I wrote that down, the bounding box, the level of detail, and the output all became obvious. A vague question produces a model nobody can check.
Step 2: Choose a box with context
I framed the Common plus two blocks in every direction. Too tight, and the buildings that cast the shadow fall outside the model. Too wide, and the model spends its detail on streets that do not matter. GenAnywhere takes the rectangle and builds a textured 3D model of what is inside. The selection is the scope statement, so draw it carefully.
The box also sets the scale. A rectangle that covers half the city will produce a model that looks like a diagram, not a place. Mine covered about eight blocks, which was enough to see the shadow and still recognize the park.
Step 3: Get the massing right, then stop
The first pass had the tall towers and the street wall, but the park was a flat green rectangle. That was fine for a massing test. I compared it with a satellite image, added screenshots of the park edge, and regenerated. The second pass picked up the pond, the paths, and most of the tree line. I stopped there. Chasing window frames would not change a shadow at 3 pm.
Scale is the quiet failure. I checked the length of the park boundary against a map before trusting anything. When the model was 10 percent off, a shadow that looked harmless landed on a path. The error was invisible ## ## until I measured something I knew.
Step 4: Fix the camera and the sun
A shadow study is useless if the viewpoint moves. I kept one elevated camera for every scenario and compared 9 am, noon, and 3 pm on three dates: June 21, September 21, and December 21. The tool does not give me a solar calculator, so I checked the light in the model against a real photo of the park at the same hour and kept only the runs that matched. Close enough for a sketch, not for a permit.
Step 5: Score the shadow, not the render
I divided the park into rough zones: open lawn, path, playground, pond edge. For each scenario I marked sun or shade at each time. That is all. The result was a small grid of observations, not a beautiful image. It also made the comparison honest, because I was reading the same zones every time instead of admiring a new camera angle.
The zones are crude on purpose. A finer mesh would look more scientific and would not change the decision I was trying to support: whether a mass belongs on that corner at all.
My grid had five zones and three hours. The result was fifteen marks per date. In December, four of the five zones were shaded by late afternoon. In June, none were. That is a crude result, but it is easy to explain and hard to misread.
Where the workflow fails
Trees, terrain, reflections, and rules. The model turns a canopy into a block or deletes it. It treats the ground as flat. It cannot show light bouncing off glass. And it knows nothing about the city's shadow standards. If the question is legal or financial, this workflow is the wrong tool.
What I would change next time
I would annotate the site before generating anything, so the first rectangle already includes the streets I care about. I would also keep every version, because the second model was better in some places and worse in others. And I would write the date and hour in the file name, not ## in my head.
Total time was about ninety minutes. The model is rough, but it answered the question I actually asked, which is more than most renders do. If I needed more, I would move to a real GIS shadow tool and a survey. For a first pass, the rectangle was enough.
Top comments (0)