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)
3D orbit view
Basic CSG operations (when they feel like it)
Export back to .pov (theoretically working)
Display Modes:
Phong Shading
Wireframe
Point cloud

What's broken:
Pretty much everything else.
Very intricate CSG falls apart.
Textures? LOL

Havent taken it very far, just been iterating to get the csg started.  Im not a
coder, I just threw ideas at AI in my spare time and this popped out (Im using
the same method to create actual functional CAD tools for work, which *are*
fully functional - CSG is a lot more complex from a code standpoint)


The Point:
This is what you can build with AI in 2 days when you don't know what you're
doing. If you actually know POV-Ray internals, you could make this not-terrible.
I'm releasing it GPL-3.0. Fork it, fix it, burn it for warmth, whatever. Just
seemed like a waste to let it rot on my hard drive.
How to use:

Open the HTML in Chrome - sample scene loads - play around then:
Load a .pov file into the window
Watch it probably fail to parse CSG properly (Woodbox.pov is a sample I've been
iterating on - and it sees most of the primitives now, but it's not evaluating
correctly.  Chess-2.pov shows promise as well.)

If you want to improve it:
Feed the code to ChatGPT 5.2 or Claude or Gemini with prompts like "fix the
cylinder parsing" or "make CSG actually work" and iterate. That's literally what
I did.  My iterating is generally - load the POV file (start simple) -
screenshot the scene, and paste the screenshot + Pov file into the AI chat and
have it evaluate where the parser failed and iterate to write a new .html..

If you get anything working I'd love to hear back, take your html and iterate
more.. I have a lot of ideas on how to set up the view and object handing based
on what Im doing at work...

Have fun.

- Chris

Post a reply to this message

Attachments:
Download 'povray-modeller-goldmaster-v0.3.8.2.html.htm' (110 KB)

"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

Post a reply to this message

Attachments:
Download 'pov_js_build_bundle.zip' (5 KB)

"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

Here is a refactored version of the monolithic file, organized into labeled
sections with comments.
The main JS header/module index begins at line ~209 (after the HTML/CSS block)
and has the details.

Post a reply to this message

Attachments:
Download 'povray-modeller-goldmaster-v0.3.8.2r1.html.htm' (114 KB)

"Chris" <esc### [at] gmailcom> wrote:

> 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.

It's been a long-standing idea, since so much of scene development is crafting
the code and just getting something to fully parse without errors.
I'm often in the situation where I have some form of text editor, but no way to
access POV-Ray.  So a browser-based parser would be a great tool for when I have
random blocks of unoccupied time and want to work something out.

> 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.

Yes, I understand that finding some way to implement / modernize Moray is a high
priority goal.  This is a very cool way of doing that.

> 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.

Yes, and I like that.  Any idea how large an html file is practical?


> 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.

I definitely think that playing with the source code, hunting down bugs, and
experimenting with fixes, new features, and alternate algorithms will be a lot
easier if some module that's implemented in a browser can be modified and tested
withing minutes, locally, without having a complex compilation process.

- BE

Post a reply to this message

>
> Yes, and I like that.  Any idea how large an html file is practical?
....
> - BE

My fractal zoomer program just crossed 6k lines... still running great.

- Chris

Post a reply to this message