"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