Kokraf: a browser 3D modeller with a real mesh model under Three.js

A modeller that runs in a browser tab

Kokraf is a modern, browser based 3D modelling tool built for real-time creativity, and the README names its audience directly: a hobbyist, a designer or a developer who wants to model, manipulate and view 3D objects directly in the browser, with no installation needed.

That framing sets the scope precisely. This is not a game engine, not a CAD system and not a photogrammetry tool. It is an interactive modelling surface, and the hosted version at kokraf.com is the product, with the note that it is best viewed on a desktop browser such as Chrome. There is a demo video, a user manual hosted at kokraf.com/manual, and a link into the project files themselves.

The technology choices are stated plainly in the README's built with list. Three.js does the 3D rendering, the interface is plain HTML, CSS and JavaScript, Supabase is the backend, and GitHub Pages provides free hosting. There is no build step in that list, and that is not an oversight, because the getting started instructions tell you to open `index.html` and use the Live Server extension.

The repository is JavaScript, the default branch is `dev` rather than `main`, and the last push was on 2026-10-20. There are no GitHub releases, so the site and the repository are the distribution channel. The project is a commercial-adjacent one, with `pricing/` and `terms/` directories at the top level, and the licence is reported as a custom one that GitHub cannot classify, which makes the LICENSE file something to read before you build on it.

The mesh is the model, and Three.js is only the renderer

This is the most interesting thing in the README, and it is the reason to look at the source.

Kokraf does not edit Three.js geometries directly. Instead it uses a custom vertex, edge and face adjacency mesh, a VEF mesh, as its core data model. Every modelling operation, the README lists extrude, move and split among them, operates on that mesh. After each operation, the mesh is converted into a BufferGeometry and handed to Three.js purely for rendering.

The division is what separates a modelling tool from a render-only editor, and the README says so directly. Because the modelling logic is independent of the renderer, you can represent polygons, quads directly, and you get real modelling workflows rather than editing for display.

Each of those three consequences deserves a moment. Independence from the renderer means the mesh can be exported, versioned or processed without going through a display pipeline, and it means a different renderer could be swapped in without rewriting the tools. Direct quad representation matters because a triangle soup, which is what most renderers consume, forces a triangulated mesh to be the storage format, and triangulating on the way in and merging on the way out is exactly the kind of round trip that makes meshes behave badly in a modelling tool. And supporting real modelling workflows rather than render-only editing is the difference between a viewer you can push a mesh into and a tool you can construct a shape in.

The top level directory listing supports this reading. There is a `js/` directory, a `components/` directory, `css/`, and a `wasm/` directory, which is where compiled code would live if any of the geometry work is done outside the JavaScript. There is also `kokraf-mcp/`, a directory whose name suggests an integration built for the Model Context Protocol, though the README does not describe what it exposes.

Running it locally is a clone and a Live Server

The getting started section is deliberately short, and the reason is the absence of a build step.

git clone https://github.com/sengchor/kokraf.git
cd kokraf

After that, the instruction is to open the project in Visual Studio Code, open `index.html` and use the Live Server extension to view the project in the browser.

There is no npm install, no bundler configuration and no compile command in those instructions, which tells you the application is served as static files. The GitHub Pages hosting in the built with list is the same arrangement: the site is the repository.

That has a clear advantage for anyone who wants to look inside. You can clone it, read the JavaScript, change a line, and reload the page, with no toolchain between the edit and the result. For a hobby project or a learning exercise, that is a much lower barrier than a packaged application with an installer and an opaque bundle.

It also means the project has no declared compatibility surface. The README says nothing about which browser versions are supported, how the Live Server extension should be configured, or what to do when the page loads and the Supabase backend is unreachable. A reader who wants to run it against their own backend instance will find the `supabase/` directory in the repository but no description of the schema or the environment variables in the README.

The `manual/` directory in the repository listing and the user manual at kokraf.com/manual are where the actual workflow is documented, and the README itself points at the online version rather than repeating it.

A static frontend with a real backend behind it

The hosting story is unusual enough to be worth spelling out, because the two halves of the deployment live in different places.

The frontend is static. GitHub Pages serves the HTML, CSS and JavaScript, the repository is the site, and the Live Server extension reproduces that arrangement on a laptop. There is no application server to run and no server-side language in the stack.

The backend is Supabase, which the README lists as the backend, and the repository has a `supabase/` directory at the top level. That directory usually holds the database migrations and the edge functions for a Supabase project, which suggests the models, the accounts and any shared state live there rather than in the browser. The README does not describe the schema, the tables, the authentication model or the row level security rules, and the `projects/` directory next to it suggests user projects are stored server side rather than locally.

The consequence for a user is that the local experience and the hosted experience are not identical. Running `index.html` from a clone gives you the interface, but anything that depends on the backend, which is at minimum the storage of your work, depends on having a configured Supabase project or on the hosted service.

The other directories at the top level sketch the rest of the product. `features/` and `explore/` are probably the marketing pages for the tool categories and the gallery of public work, `about/` and `terms/` and `pricing/` are the standard site pages, and `kokraf-mcp/` is the only one whose purpose is not obvious from the name alone.

What the documentation does not tell you, and where the tool stops

The honest limitation of this project is documentation, not technology.

The README covers the concept, the stack, the local run and the mesh model, and then points at the hosted manual for the tools themselves. It does not list the modelling operations, does not describe export formats, does not say whether a project can be saved locally as a file, and does not mention the pricing, terms or account model beyond the existence of those directories. The project description calls it a collaborative 3D modelling application, and the README never explains what collaboration means here, whether that is shared editing, comment threads or simply sharing a link to a model in the cloud. A reader has to go and find out.

The second limitation is the licence. GitHub cannot classify it, which means the LICENSE file in the repository is a custom text rather than a standard open source licence, and the README does not summarise its terms. That is unusual for a project whose source is on GitHub Pages and whose directory layout invites copying, and it is the first file anyone planning to build on this should read. This is not legal advice.

The third is the release model. There are no GitHub releases, the default branch is `dev`, and there is no changelog in the top level listing, so there is no documented version history to pin against and no stated compatibility policy for saved projects.

The fourth is scope. Kokraf is a modelling tool, not a renderer, and the README is explicit that Three.js is used purely for rendering the converted mesh. There is no coverage of surface shading, baking, animation, rigging or export to other tools, so anyone arriving from Blender, Maya or Fusion expecting a comparable feature set will find the product far narrower.

Set against those limits, the project is coherent. A browser tool with a proper mesh data model, a rendering layer that is deliberately decoupled, a hosted service and a documented manual is a sensible thing to have built, and the parts that are described are described well.

Editorial conclusion

Kokraf is a good fit for someone who wants to model in a browser tab, prefers a source tree they can read over an opaque desktop installer, and cares about the modelling data model more than the rendering fidelity. It is the wrong choice for production art pipelines, for teams that need a documented file format and export guarantees, and for anyone who needs the collaboration features the project description implies but the documentation never explains. Verify first what the licence file actually permits, because GitHub cannot classify it, and read the manual linked from the site for the workflow, because the repository README does not describe the tools, the export options or the backend schema.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. sengchor/kokraf on GitHub