[Feature] Language-Based Building Silhouettes (Architectural Archetypes)

[AegisX-dev]

What problem does this solve?

Currently, all buildings in Git City share a uniform boxy geometry, regardless of the developer's tech stack. While the height and window lighting vary based on contributions and stars, the overall architectural identity is identical for every user.

This is a missed opportunity to visually celebrate the diversity of the GitHub ecosystem. By introducing building "Archetypes" based on a user's primary_language, we can make the city feel more organic, personalized, and visually rich without sacrificing the core pixel art aesthetic.

Proposed solution

We propose mapping a developer's primary_language to 4-5 "Architectural Archetypes." This would involve:

1. Defining Archetypes:

   • The "Frontend" Tower (TS, JS, CSS): Modern, "Glass House" aesthetic with wider window grids and glass balconies.
   • The "Backend" Monolith (Go, Rust, C++, Java): Industrial, Brutalist style with external "pipes," vents, and heavy concrete textures.
   • The "Data & AI" Spire (Python, R, Julia): High-tech, "Server Farm" look with glowing data cables and spherical nodes on the roof.
   • The "GameDev" Arcade (C#, GDScript, Lua): Irregular heights, neon signs, and "retro" pixel-art roof decorations.

2. Technical Implementation (Performance-First):

   • Multi-Instance Rendering: Instead of a single InstancedMesh for all buildings, we create one InstancedMesh for each archetype. This maintains the 3D performance benefits of instancing.
   • Mapping Logic: Update src/lib/github.ts to assign a silhouetteId based on the existing primary_language field.
   • Shader Integration: Utilize the building's custom_color attribute to highlight archetype-specific features (e.g., tinting the "Backend" pipes or "Frontend" neon strips).

Alternatives considered

• Procedural Geometry per Building: Too expensive for performance; would break instancing.
• Static Textures Only: Less impactful than physical geometry changes; wouldn't provide the same "skyline" silhouette variety.

Additional context

This feature would significantly enhance the "exploration" aspect of the city, as users could visually identify "Frontend" or "Data Science" districts just by looking at the building shapes.

I'm happy to work on a PR for this if the community is interested!

[nitin-999-code]

This is a really interesting idea! The concept of mapping a developer’s primary_language to architectural archetypes would definitely make Git City feel more diverse and visually expressive.

I’d love to contribute to this feature. A few areas where I could help:

• Exploring how the silhouetteId mapping could be structured for different language groups.
• Prototyping a small implementation for one archetype (for example the Frontend Tower) to test how the rendering behaves with InstancedMesh.
• Helping integrate the mapping logic inside src/lib/github.ts while keeping the performance benefits of instancing.
• Testing how the shader/custom_color attributes could highlight archetype-specific features.

If it sounds good, I can start by drafting a small PR or prototype for one archetype so we can evaluate the visual impact and performance before scaling to the other types.

Let me know how you’d like to coordinate, or if there are any design constraints I should follow. Happy to help!
@AegisX-dev @srizzon

[srizzon]

PR #79 from @gigacat-25 implements this — buildings are now grouped by language archetype (Frontend tower, Backend monolith, Data/AI spire, GameDev arcade) using separate InstancedMesh per group with different geometries. The mapping logic lives in github.ts via a silhouetteId field.

Still need to test performance locally with thousands of buildings since it splits the single InstancedMesh into N groups, but the approach looks solid. Will update here once reviewed.

[nitin-999-code]

Hi ,
I noticed the previous PR for this issue was closed. Since the issue is still open and I had previously expressed interest, I have started working on this feature.

I will raise a PR soon with the implementation. Please let me know if there are any specific requirements or constraints I should consider.

Thank you!