Once AI made writing code cheap, the scarce thing moved: from 'can you produce it' to 'is there a vehicle that can hold it'. This article examines three structural reasons tutorial demos never grow (no persistent state, no spatial structure, no extensible boundary), gives four properties a vehicle needs (enterable, comparable, stackable, deliverable), and sets 'write it from scratch' against 'start from a base that already runs' in a cost table. The method for raising a vehicle is one layer a week, with a commit and a screenshot each time. AI's role is limited to reading the codebase, making one change at a time, and running against acceptance scripts. Stated plainly: phone performance has not been fully measured, there are no citable time figures, and the roadmap items are planned, not implemented.
AI coding portfoliowhat to learn after AI writes codebeginner developer portfolio projectsindie developer projectAI coding second development3D virtual world developmentself-hosted projectthree.js project practiceportfolio with nothing to showsource-available
Half a year of self-taught web programming, and the portfolio still holds a calculator and a to-do list. Most people conclude they did not learn the grammar properly. This article takes a different angle: grammar is the easy part to patch, and what consumes the time is feedback — waiting, judging, forgetting. It offers three criteria for filtering practice projects (visibility of result, isolation of change, accrual), runs several classic tutorial projects through them, then gives a six-stage starting path ordered by how fast feedback arrives, and states which part an AI coding tool removes and which part it does not. Stated plainly: phone performance has not been fully measured, there are no citable time figures, and the roadmap items are planned, not implemented.
learn web programming by yourselfwhy programming feels boringbeginner programming project ideasself-taught front-end roadmapAI coding for beginnersJavaScript learned but cannot buildportfolio project ideas3D virtual world developmentthree.js beginner projectsource-available
A kid wants to build a 3D world they can walk into in a browser. Where should they start? This article compares three starting points and where each breaks: block-based coding produces something in lesson one but breaks at the jump to text code; writing three.js from scratch is engineering-correct but piles every concept into the phase where nothing is visible; pure AI generation is fast but hides causality. A fourth path starts from a world that already runs: there is a reference, assignments are verifiable, and failures announce themselves. It gives a six-lesson table of one change per lesson, and argues that what should be graded is not what the AI wrote but whether the student can explain what it changed. Stated plainly: we are not an education company, there is no curriculum or teaching staff, there has been no classroom trial, and no learning outcome is claimed.
3D coding for kidsAI programming for teenagerswhere to start learning programmingthree.js teaching3D virtual world in the classroomwhat to learn after Scratchkids learning AI codingproject-based programming courseschool 3D coursesource-available
What decides whether a system is maintainable two years out is not the feature list but the dependency list. This article lays out the dependencies of this browser 3D virtual world: only two long-running services, a Node-class runtime and one PostgreSQL; no tie to a specific cloud vendor, no GPU server, no long-running middleware cluster, no third-party platform account and no proprietary build chain. It explains what each item buys: you can move it, it can live on an intranet, the server needs no graphics card, the maintenance surface is narrow, and AI coding tools can read it. It also states the six jobs that still need a person, plus two boundaries: no public concurrency load test, and federation not validated at scale.
self-hosted 3D virtual worldwhat server does a 3D virtual world needdoes a 3D scene server need a GPUbrowser 3D tech stackthree.js project deploymentNode and PostgreSQL deploymentself-hosted 3Dintranet 3D scene deploymentportable 3D systemsource-available
Receiving an unfamiliar 3D virtual world codebase, the first question is where to start without breaking it. This article gives five change points ordered by risk (copy, scene and spawn point, models and assets, characters and animation, UI panels), explaining what each pulls in; it then marks point six, the business layer that is actually yours, and its boundary against the base internals; next come four practices that make breaking things cheap (one change at a time, git branches, acceptance scripts, entering before looking good); finally it states three boundaries for AI coding tools plus one concrete way to use them. Stated plainly: phone performance has not been fully measured, there are no citable time figures, and we do not offer custom development services.
secondary development 3D virtual worldbrowser 3D developmenttaking over a three.js project3D virtual world source codeGLB optimizationLOD tiersskeletal animation retargetingself-hosted 3Dcustomizable 3D scenesource-available
Taking several similar showroom jobs a year and subcontracting each time means paying the same capability fee over and over. This article moves the criterion from "which is cheaper" to three things — how many jobs a year, how many edits per project, and who handles it when something breaks — and gives three bands of advice (one a year keeps subcontracting; two or three partitions the work and mixes; three or more with similar forms keeps a set). It points out that what you accumulate is not code but four things (model library, space skeletons, delivery script, acceptance checklist), of which the checklist pays back soonest and the space skeletons are worth most. It closes with a four-column calculation table and four cases where this direction is the wrong fit. Stated plainly: we do not take building projects, no client case is cited, there are no citable time figures, someone still has to handle operations, and phone performance has not been fully measured.
build vs outsource a 3D showroomshowroom design studio online versionbrowser 3D outsourcing costvirtual showroom system selection3D display option comparisonself-hosted 3D showroomshowroom model library reusemanaging multiple showroomsGLB importthree.js3D virtual world base layersource-available
Once form, model and devices are settled, the party taking the job has to choose which path to deliver down. This article compares three: building it yourself (consuming learning and trial-and-error time, with the underestimated cost being walking through the traps), subcontracting to a technical team (consuming margin and management, with the risk sitting in the exit mechanism and data ownership), and adding your own layer on a ready base (consuming one deployment plus operations). It lists the concrete engineering traps the path runs into — draw calls 3064 to 837, a light-count change causing an 8989 ms whole-scene recompile, textures down to roughly a third with geometry untouched, three-tier LOD with the low-detail library at 118/118 within 100 triangles, cross-source skeletal animation at 67/67, weak-network reconnect at 9/9 — names the two blocks that must have an owner, and sets out the stages of Path C before, during and after going live. Stated plainly: we do not take building projects, no client case is cited, there are no citable time figures, and phone performance has not been fully measured.
how to deliver a 3D showroomshowroom design studio online versionvirtual showroom build vs outsourcebrowser 3D development outsourcinghow to build a 3D spacehow to turn a showroom into 3D3D display option comparisonself-hosted 3D showroomGLB importthree.js performance optimisation3D virtual world base layersource-available
Clients increasingly add one sentence after the renderings — could this be made viewable online. This article first splits "viewable online" into three forms (a model you can spin, a space you can walk, something you can click and use), showing that the workload differs by an order of magnitude. It then gives six questions the party taking the job must settle on the spot: the form, who supplies the model and in what format, who views it on what device, how long it must live, who edits it and who pays, and whose server, domain, filing and operations. Each is expanded with the cost of not asking. Three conclusions follow (take it normally; take part of it and write the boundary into the contract; say plainly you cannot), along with the five items an online version should be broken into in a quote. It closes by defining what an AI explainer does and does not do, and four cases where this direction is the wrong fit. Stated plainly: we do not take building projects, no client case is cited, and phone performance has not been fully measured.
browser 3D showroom developmenthow to deliver an online version of a showroom designvirtual showroom build vs outsourcehow to turn a showroom into 3D3D space development costself-hosted 3D showroom3D model to webGLB import3D virtual world base layersource-available
Launch day goes well; three months later the product line has moved on, the numbers on a price card are wrong, a booth needs shifting — and nobody asked how it would be changed later. This article splits change into three kinds: text and position (which looks least important and accounts for most of the changes), a single model, and a whole block, comparing what each touches and where its cost comes from. The surprise is the second kind: it looks like a swap, but almost all of the cost sits in the new model's size — an unprocessed high-detail model can be many times larger, and that bill does not appear on the day of the change; it is spread across every future visitor's wait. "Swap one model" is then taken apart into six steps — get it, confirm the format, handle the size, put it in the library with a real name, swap the scene's reference, confirm on more than one screen — with step three noted as the one most often skipped and the costliest to skip. A three-role account split follows (read-only is not only about slips; it decides whether you can send the showroom to a client to preview), plus two rules to set before the first edit, four cases where self-editing is the wrong choice, and stated limits: no body of long-running client operations, no transferable answer for how long a change takes, and no backups performed for you.
updating 3D showroom contentvirtual showroom maintenancereplacing a 3D modelediting a web 3D showroomvirtual showroom account permissionsshowroom content versioning3D model size optimizationself-hosted showroom maintenance cost
The usual handover scene: the vendor opens a link, spins the camera, says "there it is"; the client thinks it looks fine, senses something is off but cannot name it, signs, and later finds the phone will not open it or that changing one word takes three days. The problem is that neither side has a list to check against — "does it look good" is subjective and cannot be settled in a meeting, while "does it open" is objective and takes one test. This article gives six items a client can verify on the spot without any 3D background: opening it on three devices (the client's own phone and connection, because that is what a visitor has), timing the first screen to actual content rather than to a loading screen, walking the agreed content list, establishing a model's order of magnitude, pointing at one thing and asking what steps a change takes and who does them, and three ownership questions about server, domain accounts, and what happens on expiry. A ready-to-copy checklist follows, with pass criteria agreed on the day, plus three actions to run at handover. It also names four situations where the checklist does not apply and states its limits plainly.
3D showroom acceptance checklistvirtual showroom delivery checklisthow to accept a web 3D showroomshowroom project handover3D display delivery processvirtual showroom multi-device testingshowroom load time acceptanceshowroom handover sign-off