https://github.com/POV-Ray/povray/issues/183

I have not follwed all the gamma issues and discussions. Just read a 
githubmessage from Clipka.

Imo there is no proper way to fix things. There are pre gamma scenes, post 
gamma fix scenes, CRT viewed scenes, broken scenes and there is artistic 
freedom, just plain "abuse" and users not reading the fine print.

The way colours are speciefied don't make it easier. With or without 
macros.

We've seen the granite discussion. Regardless of "right and wrong" it is 
complex.

Now, I don't think we can just toss all that doesn't look right. But do we 
realy need all the old stuff? What's wrong with keeping a repository of 
those with the comment that they only look right when used with the 
equipment and settings the creator used. 

Fix only the scenes hat are mentioned in the docs and the easy ones. Maybe 
add modern scenes as was done in 3.7 iirc.

This is not to make it easy, but to prevent spending lots of time on sub-
optimalisations.

-- 
https://ingoogni.nl

Post a reply to this message

Am 16.06.2021 um 15:20 schrieb ingo:

> Now, I don't think we can just toss all that doesn't look right. But do we
> realy need all the old stuff? What's wrong with keeping a repository of
> those with the comment that they only look right when used with the
> equipment and settings the creator used.

What I'd really like to see is some esteemed members of the community 
sticking their heads together, looking through the sample scenes, and 
then deciding, on a case-by-case basis, how to proceed with the scene.

I'm okay with _deliberately_ keeping scenes as they are, I'm okay with 
giving them a bit of a facelift, and I'm okay with giving them a major 
overhaul. I can live with either of those approaches.

What really bugs me is that we've been dragging around outdated scenes 
because nobody BOTHERS to take the time and give them some love and 
care. Because it's easier to forget about it once again, and just go 
ahead with the next release cycle.


DECIDING is the keyword in that sentence up there. If we leave the 
scenes unchanged once again, I want that to be a deliberate DECISION. 
Ideally for each and every individual scene.

If we want that to be done, NOW is the time to go into action, because 
we're heading towards bundling them with binaries and saying "this is 
it, these are the scenes we consider authoritative part of the official 
release proper".


And no, I feel in no position to make such decisions. This is something 
the people on the artistic end of the equation should have the last word 
on, not some technical nerd like me who hasn't thrown together a single 
scene for artistic purposes in ages.

Post a reply to this message

in news:60ca2637$1@news.povray.org clipka wrote:

> What really bugs me is that we've been dragging around outdated scenes 
> because nobody BOTHERS to take the time and give them some love and 
> care. Because it's easier to forget about it once again, and just go 
> ahead with the next release cycle.

When I move I put dates on boxes. Boxes that have not been opened are 
thrown out unopnend after two years unless they have a red sticker.

Thinking about this and backwards compatibilty, would it be easier to keep 
a few startegic versions of POV-Ray running, executing, compiling for 
current and future compilers and OS's (3.1g, 3.5, 3.7)? This could give a 
dev more freedom to break things and probably to keep the source cleaner? 
It would also kind of solve the old image problem.

Dreaming, maybe a future povray parser could just start an other engine 
depending on the #version of the scene file.

(I have no idea of the complexity of all that)

Is there anything of a time frame, weeks, months, less than a year and a 
halve? Currently my time is limited but it will change towards the end of 
the year.

-- 
https://ingoogni.nl

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> What I'd really like to see is some esteemed members of the community
> sticking their heads together, looking through the sample scenes, and
> then deciding, on a case-by-case basis, how to proceed with the scene.

Certainly could do that, although AFAICR, there were a LOT of scenes in the
distribution...  IIRC, it's something like > 2600 files.

I'm not sure what the best way to attack this is, but if I were gonna play
Project Manager, I'd suggest that an outline was made by outputting a directory
tree, and then people with the artistic and technical eyes for detail could do a
quick sifting through the rendered scenes to tag the most egregious examples, or
using knowledge of the code features to pick out the ones that would need
editing due to deprecated keywords/syntax/code structure or other such things
that don't necessarily show themselves in the renders.

I certainly know that I find many posted renders to be really nice, while others
are instantly capable of spotting bad lighting, radiosity settings,
antialiasing, artefacts, and other flaws that I might overlook or completely be
oblivious to.  So having some clue as to what files to look at and WHY would
give people who are so inclined a head-start on where to begin.

> What really bugs me is that we've been dragging around outdated scenes
> because nobody BOTHERS to take the time and give them some love and
> care. Because it's easier to forget about it once again, and just go
> ahead with the next release cycle.

As you know, it's a huge struggle to juggle RL and the endless list of new
projects and bug-hunting, let alone sift through the archives of scenes hidden
in the depths of directories off in /usr/share/qtpovray-3.8/scenes/ or wherever
one might have them squirreled away.

What precious few regulars we have here do our best, but without direction and
specifics - or at least one good illustrative example - a lot of us would just
be left guessing about what to do.

Post a reply to this message

Am 16.06.2021 um 20:14 schrieb ingo:
> When I move I put dates on boxes. Boxes that have not been opened are
> thrown out unopnend after two years unless they have a red sticker.

So, following that logic, should we just throw away all the sample 
scenes altogether? ;)


> Thinking about this and backwards compatibilty, would it be easier to keep
> a few startegic versions of POV-Ray running, executing, compiling for
> current and future compilers and OS's (3.1g, 3.5, 3.7)? This could give a
> dev more freedom to break things and probably to keep the source cleaner?
> It would also kind of solve the old image problem.

For a purely command-line only thingumajig - no graphical output 
whatsoever - that might be feasible. But porting a graphical user 
interface between different OS versions, different operating systems, 
hardware platforms etc. over and over again... that will almost 
inevitably lead to feature rot, as features not easily portable and not 
strictly necessary will be "temporarily" disabled, others not necessary 
on a particular platform will be amputated and not revived when ported 
to a platform that might benefit from it, and so on...

In the end, the UI versions of the old pieces of software will become 
unusable hunks of rotted code, that aren't worthy of keeping alive.

And then some day command-line interfaces may go out of fashion 
entirely, and the command-line-only strain of the software will suffer 
the same fate, too.


Also, each time the programming language standards change, the old code 
will have to be adapted to work with the new standard. Same deal there: 
Code that was originally clean and sane becomes patched up only at the 
edges that openly exhibit issues, while other portions may be forgotten 
and quietly slip out of alignment, until some day the whole thing comes 
crashing down, because at its core, hidden under layers of patches, its 
bones have become brittle. And the libraries our code relies on will 
also be moving targets, which will break stuff every now and then. Which 
is especially problematic when it's something we're using as extensively 
as the boost thread library.


At some point in time, it will probably be easier to just install an 
emulator or virtual machine, and run old binaries that way.


We've been doing something along those lines with POV-Ray v3.7, at least 
as far as the Unix version goes - putting out maintenance releases to 
keep it compatible with whatever comes our way. But we won't be able to 
keep it supported forever, especially on the Windows platform. We'd 
eventually need to write a brand new front-end for it. Which takes time 
and energy, because the front-end interface differs from that of v3.8. 
And eventually v3.7 will succumb to boost rot, because newer versions of 
boost will grow more and more incompatibilities with our code, and 
eventually cease to even support what we're using it for, because that 
portion of boost is effectively outdated already; while the older 
versions of boost will grow more and more incompatibilities with modern 
compilers, and be unavailable for more and more modern target platforms. 
And ripping out boost and replacing it with something else may turn out 
to be more work than it's worth, due to how intensively we were using it 
in v3.7. At that point, v3.7 will go the way of the Dodo.

The good news is that v3.8 will be reasonably close to v3.7 in its 
behavior, and hopefully work as a plug-in replacement. And work for 
ripping out boost (the most extensively used portions anyway) had almost 
finished in v3.8 (in fact it had, but we're reverting back to before 
that for v3.8.0), so it'll be much less susceptible to poorly aging 
libraries, and thus might be a lot easier to keep alive in the long run 
than poor old v3.7.

In fact, it might even be easier to revive any of the older versions 
than to keep v3.7 alive. v3.6.2 and earlier versions didn't use boost at 
all. Of course they also didn't support multithreading.


Well, so much for my crystal ball peek into the future, anyway. Only 
time will tell how much I'm over- or underestimating the troubles involved.


> Dreaming, maybe a future povray parser could just start an other engine
> depending on the #version of the scene file.
> 
> (I have no idea of the complexity of all that)

That won't fly at all. At best, the combo of parser and render engine 
could be exchanged. But even that would require a well-defined interface 
to plug those pieces into a front-end. We don't have such a thing at 
present, and I dare say we never will. Not a stable one, at any rate. 
Which defies the whole idea. Oddly enough, we'll probably continue trying.

Well, actually we currently have _two_ such interfaces: The POVMS 
interface and the VFE. Neither is anywhere close to intuitive though (at 
least *I* haven't gotten a good grasp on either of them yet, and it's 
not like I'm totally new to the source code), and I wouldn't want to 
have to interface to either of them. And neither seems to be 
particularly suited to just exchanging the back-end on the fly.


> Is there anything of a time frame, weeks, months, less than a year and a
> halve? Currently my time is limited but it will change towards the end of
> the year.

Folks at dev team level are itching to get v3.8.0 out as soon as quality 
concerns permit. I'm pretty sure we'll have the first beta before the 
month is over. How quickly things progress from then on depends; my 
estimates vary between anything from another month (when I'm feeling 
excessively optimistic) to half a year (when I'm extrapolating from past 
frustration). It certainly won't take as long as the v3.7.0 beta phase.

Post a reply to this message

in news:60ca5e78$1@news.povray.org clipka wrote:

> Folks at dev team level are itching to get v3.8.0 out as soon as
> quality concerns permit.


Well, let's start look for the boxes with red stickers then.


-- 
https://ingoogni.nl

Post a reply to this message

Am 16.06.2021 um 22:17 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> What I'd really like to see is some esteemed members of the community
>> sticking their heads together, looking through the sample scenes, and
>> then deciding, on a case-by-case basis, how to proceed with the scene.
> 
> Certainly could do that, although AFAICR, there were a LOT of scenes in the
> distribution...  IIRC, it's something like > 2600 files.

2579 in v3.7.

But of those,

- 312 are in the `previews` subdirectory, containing nothing but 
pre-rendered images of scenes, and

- 1778 are in the `templates` subdirectory, containing short scene 
snippets, and typically coming in pairs of one text file and one 
rendered image. Plus a few HTML files. So that's a guesstimated ~850 
code snippets.

That leaves us with <500 files making up genuine scenes, organized into 
312 distinct scenes (judging by the number of preview images).


Of course those ~850 code snippets also might warrant getting a review, 
possibly even more so than the sample scenes.


> I'm not sure what the best way to attack this is, but if I were gonna play
> Project Manager, I'd suggest that an outline was made by outputting a directory
> tree, and then people with the artistic and technical eyes for detail could do a
> quick sifting through the rendered scenes to tag the most egregious examples, or
> using knowledge of the code features to pick out the ones that would need
> editing due to deprecated keywords/syntax/code structure or other such things
> that don't necessarily show themselves in the renders.

I've thrown together something using GitHub Wiki on our repo; please 
have a look at https://github.com/POV-Ray/povray/wiki/Scene-Files-Review 
to see whether that might be a useful tool to manage this task, and how 
you think it could be improved.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

....

> I've thrown together something using GitHub Wiki on our repo; please
> have a look at https://github.com/POV-Ray/povray/wiki/Scene-Files-Review
> to see whether that might be a useful tool to manage this task, and how
> you think it could be improved.

Do you sell phials of the potion that allows you to do the work of 10 people in
mere minutes?


Are there any guidelines that we're following with regard to file formatting?
Indentation - tabs, spaces, doesn't matter...

Many files say something to the effect of
"Persistence Of Vision raytracer version 3.5 sample file."

but then there is #version  3.7;

update to make consistent?

scenes/objects/ttf1.pov is ... heinous?
I'm guessing part of this project is to make them ... better?

fonts/typefaces that are shipped are:
crystal.ttf
cyrvetic.ttf
povlogo.ttf
timrom.ttf

I recall you recently calling out timrom - are we deprecating its usage until we
find something better?  (I like the seriffage of jsMath-cmmi10.ttf and
jsMath-cmti10.ttf)

Inquiring minds want to know!  :)

Post a reply to this message

in news:web.60caa8ed490c1b141f9dae3025979125@news.povray.org Bald Eagle 
wrote:

> Indentation - tabs, spaces, doesn't matter...
> 

I would not bother with that. All together it shows POV-Ray as it is.

-- 
https://ingoogni.nl

Post a reply to this message

Am 17.06.2021 um 03:44 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
> ....
> 
>> I've thrown together something using GitHub Wiki on our repo; please
>> have a look at https://github.com/POV-Ray/povray/wiki/Scene-Files-Review
>> to see whether that might be a useful tool to manage this task, and how
>> you think it could be improved.
> 
> Do you sell phials of the potion that allows you to do the work of 10 people in
> mere minutes?

If you're talking about the list of scenes, that's just the miracle of 
Unix command-line tools (on a Windows machine no less) to get a raw 
list, and a text editor with good find/replace to bring it into the 
GitHub Markdown format.

The real work only starts from there: What do we even _do_ with this list?


> Are there any guidelines that we're following with regard to file formatting?
> Indentation - tabs, spaces, doesn't matter...

Well... there's some topic for discussion for you.

Me, personally, I would LOVE to see consistent formatting throughout all 
the sample scenes. Preferably MY own favorite style of course. (The 
style used in the "Insert Menu" sample snippets, for instance, is an 
abomination. No offense, Friedrich.)


One thing really worth investigating though is whether there are any 
lowercase variable names in those scenes - because those are very 
strongly non-recommended. William Pokorny might be able to help with 
that: If I understand correctly he has a version of the parser that 
warns on lowercase variables.

Also, while it might be argued to keep the file formatting intact to 
reflect the wide variety in that respect, I'd really love to see at 
least the file headers standardized. Again, my personal opinion.


> Many files say something to the effect of
> "Persistence Of Vision raytracer version 3.5 sample file."
> 
> but then there is #version  3.7;
> 
> update to make consistent?

Another point worth discussing: Should it be the version in which the 
sample file was first introduced, the one in which it was last updated, 
the one that it now requires as minimum, or the one it will ship with 
(i.e. v3.8)?


> scenes/objects/ttf1.pov is ... heinous?
> I'm guessing part of this project is to make them ... better?

I would think so.
Oh, by the way: That particular scene should be called out for showing 
an outdated version number in the output image.

> fonts/typefaces that are shipped are:
> crystal.ttf
> cyrvetic.ttf
> povlogo.ttf
> timrom.ttf
> 
> I recall you recently calling out timrom - are we deprecating its usage until we
> find something better?  (I like the seriffage of jsMath-cmmi10.ttf and
> jsMath-cmti10.ttf)

Unfortunately we're stuck with whatever fonts will ship with POV-Ray 
v3.8.0. Removing any of the fonts from the list is a no-go for 
compatibility reasons, and adding any other fonts means starting a 
non-trivial endeavor of selecting fonts based on (a) artistic quality, 
(b) technical quality, (c) size, (d) set of characters covered, (e) 
licensing issues, and presumably (f) then some.

The font that really got under my skin was cyrvetic.ttf. But if we stick 
to ASCII, the fonts are useful. Though arguably not the prettiest.


> Inquiring minds want to know!  :)

Team up and discuss. This is (or should be) as much your software 
package as it is mine.

Post a reply to this message