POV-Ray : Newsgroups : moray.win : Browser-based POV-Ray Scene Editor (v0.3.8.2 - Very Broken But Promising) : Re: Browser-based POV-Ray Scene Editor (v0.3.8.2 - Very Broken But Promisin= Server Time
21 Dec 2025 04:25:21 EST (-0500)
  Re: Browser-based POV-Ray Scene Editor (v0.3.8.2 - Very Broken But Promisin=  
From: Chris
Date: 18 Dec 2025 17:05:00
Message: <web.694473692814dba8eb3f524d4874d4b3@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Chris" <esc### [at] gmailcom> wrote:
> > Hey folks,
> > I spent a weekend messing around with GPT-5.2 and built a quick proof-of-concept
> > for a MORAY-style scene editor that runs entirely in your browser. No install,
> > just open the HTML.
> >
> > What works:
> > Parses .pov files (most of the time)
>
> I tried to get my CoPilot to implement the POV-Ray parser so that it would flag
> syntax errors and allow composition of pov files in the absence of a local
> install.
>
> It sqwaked about what it was able to access and process, but the idea was to
> convert the parser into some kind of WASM / JSON thing and embed it into the
> html.
>
> I don't have the access or the knowledge to make that happen, so I'll just post
> the zip of that here.
>
> If there's a way to partition this browser-based thing into pieces, maybe
> there's a way to put the pieces on a wiki page, and people can submit
> fixes/expansions on the forum/email, and that would be a way forward.
>
> - BE

BE, that's a great angle.
A real POV-Ray grammar/parser in WASM would be the ideal endgame if someone
wants strict syntax validation plus macro/include handling in-browser.

What I've built so far is intentionally more "Moray-like".
It's a browser viewport + scene graph + editor with a tolerant reader.
It tries to extract primitives/CSG/transforms where it can.
It preserves the original text so an input-to-output round trip doesn't
destroy the file.
It's not (yet) a full POV preprocessor.
The viewport is an approximation.
Final render still belongs to POV-Ray.

On modularity.
I originally kept it as a single self-contained HTML because it's easy for
people to try.
No toolchain, no install, just open the HTML.
But I agree that contributing is painful in one giant file.

Proposed middle ground (lowest friction).
Keep a single-file "release" build for end users.
Refactor the code into clearly labeled module sections inside the monolithic
file.
Parser / SceneGraph / Renderer / UI / Export, etc.
That way people can point to a section and propose targeted patches without
requiring a full repo/toolchain.

Also just to set expectations.
I'm not planning to run or manage a repo.
I don't really have the GitHub workflow knowledge (honestly I barely
understand GitHub).
I don't want to pretend otherwise.
If someone else wants to host a repo and accept PRs, I'm totally fine with
that.
But I'm personally aiming for "copy/paste friendly + easy to try" first.

If folks are interested in contributing, the most useful bite-sized areas are.
Parser improvements: more POV-Ray 3.7 syntax patterns, transform order,
axis math, plane forms.
Primitive coverage: torus, quadric, blob, lathe/sor, prism, mesh2,
even as viewport approximations.
CSG viewport evaluator speed/robustness: SDF raymarch tuning and fallback
paths.

Also.
If anyone has a favorite small-but-nasty .pov that breaks parsing, attaching
that is gold.
Those files are basically unit tests.

P.S.
I'll work on refactoring the single-file HTML into clearly labeled sections
and add some comments so it's easier to navigate and propose targeted fixes.

P.S.S.
If you're trying to refactor or generate larger chunks of code, I've had much
better luck with GPT-5.2 specifically.
It seems to handle bigger files and multi-step changes with fewer hiccups
than the default Copilot chat.

P.S.S.S. I'm also using ChatGPT as a quick "jargon translator" while I ramp up
on POV-Ray parsing and rendering terminology, so if I misuse a term, feel free
to correct me.

- Chris


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.