tTh <tth### [at] noneinvalid> wrote:

>     But what if your scene, like mine, is split into several
>     included files?

Of course.
This is but a (simple) first step in implementing a suite of features.

What if you have meshes and HDRI light probes, and uv mapped image files, and
.....


We just proceed forward, one step at a time.

The simplest is just capturing that tricky equation, the thing that needed to be
twice differentiated, or meticulously translated to POV-Ray's crippled function
VM.  The laboriously developed texture that just captures that look.  Whatever.

Now it's saved as a part of the image that gets posted, and it's archived and
backed-up.

Then we can explore tar, gz, zip, 7z, and many other ways of collecting together
all of the elements to faithfully re-render any given scene.

- BW

Post a reply to this message

hi,

tTh <tth### [at] noneinvalid> wrote:
> On 4/13/25 14:07, jr wrote:
> > ... scene code itself among the meta data ...
>     But what if your scene, like mine, is split into several
>     included files?

I suspect what BE has in mind is pretty close to Tcl "starkit"s, that is, some
underlying VFS which allows mounting zips / archives.  then it'd simply be your
whole project, with its own internal (sub-)directory structure, in a single
file; which I'd prefer, personally, but the "blob" could of course also be
embedded.  so much depends on what decisions will be taken wrt a future POV-Ray.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> Tcl "starkit"s,

https://sqlite.org/appfileformat.html
https://sqlite.org/affcase1.html

What if one did something like the above. The database would contain the
complete current and past project in one file. Beside that one would have the
complete set of current versions as text files in the working dir(s). One could
feed POV-Ray the current text file(s) or the database and it would extract the
current version and render it.

Several of the editors out there are very configurable (language servers et al),
I think one could write a program that makes the construct above feasible. With
a dedicated POV-Ray editor it should be no problem at all to work this way.

In similar vain for the documentation. Stick it in a database based ebook like
thing. When one "installes" an include file, its documentation should be added
to the database so it is available in the help reader. Keywords to the index and
with full text search and may be made available in the language server.

SQLite files are not small, but 7zip can do wonders to them (for distribution)

Just thoughts,

ingo

Post a reply to this message

hi,

"ingo" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > Tcl "starkit"s,
>
> https://sqlite.org/appfileformat.html
> https://sqlite.org/affcase1.html
>
> What if one did something like the above. The database would contain the
> complete current and past project in one file. Beside that one would have the
> complete set of current versions as text files in the working dir(s). One could
> feed POV-Ray the current text file(s) or the database and it would extract the
> current version and render it.

you're preaching to the converted </grin>.  personally, I (and I guess you)
would like to see SQLite at the core of the "next-gen" POV-Ray.



> Several of the editors out there are very configurable (language servers et al) ...

but you're thinking way more "integrated" than self does.


> With a lot of test images and reuse of scenes I loose track of command line
> settings, camera settinges etc.

had me thinking that, at least for the *NIX builds, one could have POV-Ray dump
its argv[] to a '~/.povray_history', to help with that.  (WFP ? :-))


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "ingo" <nomail@nomail> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > Tcl "starkit"s,
> >
> > https://sqlite.org/appfileformat.html
> > https://sqlite.org/affcase1.html
> >
> > What if one did something like the above. The database would contain the
> > complete current and past project in one file. Beside that one would have the
> > complete set of current versions as text files in the working dir(s). One could
> > feed POV-Ray the current text file(s) or the database and it would extract the
> > current version and render it.
>
> you're preaching to the converted </grin>.  personally, I (and I guess you)
> would like to see SQLite at the core of the "next-gen" POV-Ray.
>
>
>
> > Several of the editors out there are very configurable (language servers et al)
...
>
> but you're thinking way more "integrated" than self does.
>
>
> > With a lot of test images and reuse of scenes I loose track of command line
> > settings, camera settinges etc.
>
> had me thinking that, at least for the *NIX builds, one could have POV-Ray dump
> its argv[] to a '~/.povray_history', to help with that.  (WFP ? :-))
>
>
> regards, jr.

I like this.
A LOT.
https://sqlite.org/appfileformat.html  makes a great case, and it's very much
what I've been wanting / thinking about for a long time.

With regard to the editor and integrating things into the POV-Ray application, I
like that we can simply include an SQLite library into POV-Ray and be just about
done with it.
As for the editor, it seems to me that there has always been a very rigid
segregation between what POV-Ray DOES, and HOW the user gets / generates the
data for POV-Ray to raytrace.

I just got doing my taxes, and I had to go searching for this form, and that
table, and another Schedule, and ....
And by the time I was halfway through I was ready to declare the start of the
Second American Revolution.

Using POV-Ray can be very much like that, where I need to switch back and forth
between a drawing application, an image viewer, a spreadsheet, a PDF reader, and
my web browser in order to collect, digest, and curate the data that I need to
represent in SDL to make my scene.   Plus, I'm forever opening file folders to
open .inc files so that I can make sure I'm using the correct name of a texture
or macro, since I'm unsure of the exact placement of an underscore, or the
capitalization of the identifier.

It seems to me that with SQLite, one could use a very feature-rich editor that
could handle several file types in separate tabs, or no editor at all.

I very much like the versioning and history aspects of this as well, since one
can follow along to see the incremental changes to a scene (and even animate the
progress).  This would also allow _parallel_ versioning in a collaborative
project, so that various avenues toward the same end could be explored, and the
approaches compared and contrasted.

Further, it seems that since it's a relational database, we could easily have
documentation to pull up for keywords, macros, functions, etc., search for the
closest match to my misspelled texture or macro name, or perhaps even search for
search terms in the description of a macro or function to find what we need or
determine if it even exists at all.

And then, once the development of a scene is "complete" (is it ever?), one could
produce an optimized final version that has all of the unnecessary data stripped
out, and only the core dependencies retained.  (No one ever needs to include the
entirety of colors.inc)

And following up on jr's comments - one could likely store "state data" such as
resolution, antialiasing settings, and a host of other things for any given
"version" that one is working on.  I think it would also trivially allow the
much-requested _persistent_ values across animation frames.

And likely a lot more things that I haven't listed off the top of my head.

Am I properly understanding the capabilities?
Does what I propose make sense?

What do we need to start making this work?

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> What do we need to start making this work?
>


Regarding state, maybe stop using the command line switches and start using the
ini-file for it. That can be added in the DB / history.

To get a feel for such a thing and figure out what functionality is useful, set
up fossil on your workstation and use that. Create a working dir for a project
and add that to fossil. Then add everything you need to folders within your
working dir. This will get you one fossil file per project. Fossil is a general
tool, so it can do way more than needed, unless you want to start a forum for
every project.

You can set up a batch file that you use to start a render and that also first
commits the current state of the project to fossil. Or you use gui automation
tools to do the check in on `Alt+G` or the render button. (not sure how powerful
such tools are). Also for several editors there are fossil integration plug ins
available.

But with all that, I would still like some way to put user defined metadata from
the scene file in the image.

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> Regarding state, maybe stop using the command line switches and start using the
> ini-file for it. That can be added in the DB / history.

I get all discombobulated with .ini files and .inc files.  I always start trying
to render the wrong file when I'm working on things.
I also need some sort of workflow roadmap that's laid out by people who already
use such tools, as I've been system-hopping due to HDD crashes and laptop
catastrophes - so I haven't ever had enough time to learn much command line fu,
or familiarize myself with the tools that are available.

So when I want to get something done, I want to stay "heads-up" and hammer out
the project, not be stuck "heads-down" trying install packages, learn
command-line tools, or basically sort out all of that low-level stuff.
It is, unfortunately, a self-reinforcing cycle.

> But with all that, I would still like some way to put user defined metadata from
> the scene file in the image.

https://news.povray.org/povray.windows/thread/%3Cweb.56d3b273af51b1d05e7df57c0%40news.povray.org%3E/?ttop=444751

Looks like you can use a post-render shell command to somehow insert the data
into the graphic file?
IIRC, there was a thread where I discussed using a shell command to overlay text
onto rendered frames . . .  it was a while ago.

- BW

Post a reply to this message

On 4/14/25 07:47, jr wrote:
>> With a lot of test images and reuse of scenes I loose track of command line
>> settings, camera settinges etc.
> had me thinking that, at least for the *NIX builds, one could have POV-Ray dump
> its argv[] to a '~/.povray_history', to help with that.  (WFP ? :-))

Hi jr.

Phase of the moon maybe - or that many of us have tax time hangovers...

It happens, I'm about a week into another run at replacing the POV-Ray 
(yuqk), command line and ini parsing(*). I've patched bugs in the yuqk 
fork over time, but many remain.

The one probably most important for the metadata subject is that our 
current, to ini file, dump mechanism isn't covering all the options - no 
matter how options are set. Also, the thread count setting, for example, 
should probably not be captured, but always is.

The yuqk fork - given it's rapidly changing - should capture the 
particular release version too. I'm also pushing on ideas like creating 
persistent (perhaps never freed) stuff during the command line / ini 
parsing stage(**). I've not thought about how features like that might 
work with captured rendering states.

As to your particular '?' jr, Something like a ~/.povray_history is 
possible, but does it offer much over the terminal's command history? 
Such a file would be specific to 'povray' and I suppose more persistent? 
The generic, Linux / Unix history capability I do use heavily - to 
render again with the same flags.

Bill P.

(*) - I've started this effort several times over the past five years or 
so - and I've always bailed. Don't hold your breath.

(**) - Anything from simple value, vector, string storage (extended 
'declare' command capabilities) to a new, optional, first parse pass. 
The entire 'first parse' result would be treated as persistent storage.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/14/25 07:47, jr wrote:
> >> ... I loose track of command line settings, camera settinges etc.
> > ... '~/.povray_history', to help with that.

> ...
> As to your particular '?' jr, Something like a ~/.povray_history is
> possible, but does it offer much over the terminal's command history?
> Such a file would be specific to 'povray' and I suppose more persistent?
> The generic, Linux / Unix history capability I do use heavily - to
> render again with the same flags.

I too use the BASH history, but may clear mine between "tasks".  and you're
right to question the "suitability" of a file-based approach.  perhaps the
command-line could be included when 'all_file=true', instead ?


> (**) - Anything from simple value, vector, string storage (extended
> 'declare' command capabilities) to a new, optional, first parse pass.
> The entire 'first parse' result would be treated as persistent storage.

that's a really good idea, 2-pass parsing, real "benefits" to be had.  and with
the speed of modern machines, the user will not even notice.  nice.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> > (**) - Anything from simple value, vector, string storage (extended
> > 'declare' command capabilities) to a new, optional, first parse pass.
> > The entire 'first parse' result would be treated as persistent storage.
>
> that's a really good idea, 2-pass parsing, real "benefits" to be had.  and with
> the speed of modern machines, the user will not even notice.  nice.

We can in some respect do this via a self-including .pov file, with #if #else
#end or #switch blocks.
Identifiers that are assigned values at any stage of the parsing are persistent,
and can be modified as well.

- BW

Post a reply to this message