Le 21/02/2021 à 15:10, William F Pokorny a écrit :
> On 2/21/21 6:03 AM, Le_Forgeron wrote:
>> Le 19/02/2021 à 00:32, Bald Eagle a écrit :
>>>>
>>>> Do you have some commercials for povr ?
>>>>
>>>> I mean some catalog of all the features that povr has ?
>>>
>>> I think that may mean "You should consider doing an hgpovray38 version."
>>> Which, I think, is an excellent idea.  :D
>>>
>>
>> The catalog for hgpovray38 is in the wiki.
>> (as well as illustrated in the distribution, but that's only after
>> download, so not a real advertisement)
>>
>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
>>
>> I'm lacking such information about povr.
>>
> 
> As am I currently for any concise form for the whole.
> 
> ---
> 
> I'm struggling with how to document. I have no plans to continue to use
> the wiki though a chunk of my early documentation is there, if you look.
> The wiki method is too slow to use and not under code control.
> [SNIP]
I tried to use the github wiki (separate repository, tied to the
project), but it was painful (especially with dual repository in github
& bitbucket). So I returned to povray.wiki.

If you like documentation in code control, there is the md files which
could be used (but focus on supported features by github, forget fancy
options). Everything starts at README.md,

> The povr branch is based off of v3.8, but it's absolutely a break from
> strong backward compatibility. Mostly, this is because it's all I can
> manage - but I also think it's necessary to fix many of the long
> standing issues! There are hundreds of fixes little and large in povr. I
> think too often today's documented features are not really working as
> they should! Is adding many new features on such a base the best
> immediate path forward?
> 

Stalled fixing, or adding needed stuff, large dilemma.
I answered for myself when CLipka starts rewriting a lot of the code and
moved files. One cook in the kitchen is enough.

> Aside: I'm only four years getting into c++ when it takes 10 to be
> really good at anything. I'd probably be much further along if I'd long
> been a c++ programmer. As a language c++ is nothing if not a huge
> mountain to climb all by itself... :-( Let alone all our own classes and
> template classes.)
> 

Beware, CLipka (I believe) was applying Misra/Autosar C++ coding rules,
a fully painful set of constraints, on the rewrite of the old C object
oriented code (from the very old code in 3.1). It is more than just C++.

> Anyway. Me rambling. The povr branch is my strong push toward what I
> think 'POV-Ray' should be in the future, but there is no doubt, it's
> more than I can handle in any short term time frame.
> 
> FYI. I'm away from my computer for the next few days.
> 
> Bill P.
>

Post a reply to this message

Op 21/02/2021 om 18:07 schreef Le_Forgeron:
> Le 21/02/2021 à 15:10, William F Pokorny a écrit :
>> On 2/21/21 6:03 AM, Le_Forgeron wrote:
>>> Le 19/02/2021 à 00:32, Bald Eagle a écrit :
>>>>>
>>>>> Do you have some commercials for povr ?
>>>>>
>>>>> I mean some catalog of all the features that povr has ?
>>>>
>>>> I think that may mean "You should consider doing an hgpovray38 version."
>>>> Which, I think, is an excellent idea.  :D
>>>>
>>>
>>> The catalog for hgpovray38 is in the wiki.
>>> (as well as illustrated in the distribution, but that's only after
>>> download, so not a real advertisement)
>>>
>>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
>>>
>>> I'm lacking such information about povr.
>>>
>>
>> As am I currently for any concise form for the whole.
>>
>> ---
>>
>> I'm struggling with how to document. I have no plans to continue to use
>> the wiki though a chunk of my early documentation is there, if you look.
>> The wiki method is too slow to use and not under code control.
>> [SNIP]
> I tried to use the github wiki (separate repository, tied to the
> project), but it was painful (especially with dual repository in github
> & bitbucket). So I returned to povray.wiki.
> 
> If you like documentation in code control, there is the md files which
> could be used (but focus on supported features by github, forget fancy
> options). Everything starts at README.md,
> 
>> The povr branch is based off of v3.8, but it's absolutely a break from
>> strong backward compatibility. Mostly, this is because it's all I can
>> manage - but I also think it's necessary to fix many of the long
>> standing issues! There are hundreds of fixes little and large in povr. I
>> think too often today's documented features are not really working as
>> they should! Is adding many new features on such a base the best
>> immediate path forward?
>>
> 
> Stalled fixing, or adding needed stuff, large dilemma.
> I answered for myself when CLipka starts rewriting a lot of the code and
> moved files. One cook in the kitchen is enough.
> 
>> Aside: I'm only four years getting into c++ when it takes 10 to be
>> really good at anything. I'd probably be much further along if I'd long
>> been a c++ programmer. As a language c++ is nothing if not a huge
>> mountain to climb all by itself... :-( Let alone all our own classes and
>> template classes.)
>>
> 
> Beware, CLipka (I believe) was applying Misra/Autosar C++ coding rules,
> a fully painful set of constraints, on the rewrite of the old C object
> oriented code (from the very old code in 3.1). It is more than just C++.
> 
>> Anyway. Me rambling. The povr branch is my strong push toward what I
>> think 'POV-Ray' should be in the future, but there is no doubt, it's
>> more than I can handle in any short term time frame.
>>
>> FYI. I'm away from my computer for the next few days.
>>
>> Bill P.
>>
> 
> 
> 

Just out of curiosity: How is this related to "POV-Ray 4" or whatever 
POV-Ray 4 stands for? I am lost about the history of that ng.

-- 
Thomas

Post a reply to this message

Le 22/02/2021 à 08:43, Thomas de Groot a écrit :

> Just out of curiosity: How is this related to "POV-Ray 4" or whatever
> POV-Ray 4 stands for? I am lost about the history of that ng.
> 

I tried to redirect to a more suitable group the discussion started in
p.b.animations about povr & hgpovray38.

I forgot to update the subject line, and place a FU2 notice too.

I do not know if there is any correlation between pov4 and povr.

For me, povr (as well as hgpovray38) is a divergent work from official
povray (3.8 not yet published), so it would have been better to continue
in p.u.patches .

Post a reply to this message

Op 22/02/2021 om 17:40 schreef Le_Forgeron:
> Le 22/02/2021 à 08:43, Thomas de Groot a écrit :
> 
>> Just out of curiosity: How is this related to "POV-Ray 4" or whatever
>> POV-Ray 4 stands for? I am lost about the history of that ng.
>>
> 
> I tried to redirect to a more suitable group the discussion started in
> p.b.animations about povr & hgpovray38.
> 
> I forgot to update the subject line, and place a FU2 notice too.
> 
> I do not know if there is any correlation between pov4 and povr.
> 
> For me, povr (as well as hgpovray38) is a divergent work from official
> povray (3.8 not yet published), so it would have been better to continue
> in p.u.patches .
> 

Yes, I understand that, but my question (out of sheer curiosity) was 
what, historically, 'POV-Ray 4' was intended to be. I guess it was the 
next future version of POV, but the newsgroup 'pov4.discussion.general', 
over the years, seems to be filled with unrelated topics. So, I wondered 
how povr and hgpovray38 relate to that mythical pov4? Are they 
intermediary steps or are they the intended as the 'real thing'? Just 
idle questions from a guy who has nothing better to do ;-)

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> Yes, I understand that, but my question (out of sheer curiosity) was
> what, historically, 'POV-Ray 4' was intended to be. I guess it was the
> next future version of POV, but the newsgroup 'pov4.discussion.general',
> over the years, seems to be filled with unrelated topics. So, I wondered
> how povr and hgpovray38 relate to that mythical pov4? Are they
> intermediary steps or are they the intended as the 'real thing'? Just
> idle questions from a guy who has nothing better to do ;-)

Well, unless someone can provide a clear and unambiguous historical answer, I'd
say that whatever the intention was, it's lost to history.

I'd say that probably what we're looking for gets broken down into speed,
reliability, and functionality.

So, then we make ourselves an outline, and start making entries under those
headings.

1. What can be made faster / what really NEEDS (realistically) to be faster?
2. What are the parts of POV-Ray that are unstable/unreliable?
3. And functionality -
which I think can be broken down into 3 parts
  A. programming / math - because as much as POV-Ray is a renderer,
     it primarily relies on SDL code to generate the content
     So, data types/containers, algorithms, mathematical functions

  B. scene assembly / modeling
     this can be split up into geometry and texturing,
     and of course we have other things like camera, lighting, etc
     ...and the parser.

  C. rendering
     Likely much of this will be things like ray-object intersections
     and related things that Bill Pokorny is up to his eyeballs in


clipka had some things to say about some of this here:

http://news.povray.org/povray.general/thread/%3C49ca3d4e%241%40news.povray.org%3E/?mtop=305193&moff=10

So maybe one single thread can be set aside to post nothing but the barest
descriptive entries, with a meta-thread dedicated to commentary and discussion.
The we can see where we're at, and where it would be productive for people to go
and do.

Plus, it would provide an easy list to refer to when sifting through the forums
for code that already accomplishes (mostly) what is on the wish list.

Because 4.0 was supposed to be a break from the slow bureaucratic suicide of
backwards-compatibility - so since we're the only ones using POV-Ray, and HERE,
guess who decides what 4.0, if it's ever going to get made, will be?

Post a reply to this message

Op 23/02/2021 om 12:48 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> Yes, I understand that, but my question (out of sheer curiosity) was
>> what, historically, 'POV-Ray 4' was intended to be. I guess it was the
>> next future version of POV, but the newsgroup 'pov4.discussion.general',
>> over the years, seems to be filled with unrelated topics. So, I wondered
>> how povr and hgpovray38 relate to that mythical pov4? Are they
>> intermediary steps or are they the intended as the 'real thing'? Just
>> idle questions from a guy who has nothing better to do ;-)
> 
> Well, unless someone can provide a clear and unambiguous historical answer, I'd
> say that whatever the intention was, it's lost to history.
> 
> I'd say that probably what we're looking for gets broken down into speed,
> reliability, and functionality.
> 
> So, then we make ourselves an outline, and start making entries under those
> headings.
> 
> 1. What can be made faster / what really NEEDS (realistically) to be faster?
> 2. What are the parts of POV-Ray that are unstable/unreliable?
> 3. And functionality -
> which I think can be broken down into 3 parts
>    A. programming / math - because as much as POV-Ray is a renderer,
>       it primarily relies on SDL code to generate the content
>       So, data types/containers, algorithms, mathematical functions
> 
>    B. scene assembly / modeling
>       this can be split up into geometry and texturing,
>       and of course we have other things like camera, lighting, etc
>       ...and the parser.
> 
>    C. rendering
>       Likely much of this will be things like ray-object intersections
>       and related things that Bill Pokorny is up to his eyeballs in
> 
> 
> clipka had some things to say about some of this here:
> 
>
http://news.povray.org/povray.general/thread/%3C49ca3d4e%241%40news.povray.org%3E/?mtop=305193&moff=10
> 
> So maybe one single thread can be set aside to post nothing but the barest
> descriptive entries, with a meta-thread dedicated to commentary and discussion.
> The we can see where we're at, and where it would be productive for people to go
> and do.
> 
> Plus, it would provide an easy list to refer to when sifting through the forums
> for code that already accomplishes (mostly) what is on the wish list.
> 
> Because 4.0 was supposed to be a break from the slow bureaucratic suicide of
> backwards-compatibility - so since we're the only ones using POV-Ray, and HERE,
> guess who decides what 4.0, if it's ever going to get made, will be?
>

Right! Very clear indeed; I didn't remember that post by Christoph and 
he says some very fundamental things too. I need to ponder this a bit 
more...

-- 
Thomas

Post a reply to this message

On 2/21/21 12:07 PM, Le_Forgeron wrote:
> Le 21/02/2021 à 15:10, William F Pokorny a écrit :
...
> 
> Beware, CLipka (I believe) was applying Misra/Autosar C++ coding rules,
> a fully painful set of constraints, on the rewrite of the old C object
> oriented code (from the very old code in 3.1). It is more than just C++.
> 

Thanks. I didn't know the where he was getting the 'extremely robust' 
set of constraints. Even as the rules are represented in in the code 
source I believe they nearly impossible to follow completely without 
some kind of automation - and I see there was the ability to integrate 
those rules as checks in perforce itself. Had you guys done that?

Bill P.

Post a reply to this message

On 2/22/21 11:40 AM, Le_Forgeron wrote:
> Le 22/02/2021 à 08:43, Thomas de Groot a écrit :
> 
>> Just out of curiosity: How is this related to "POV-Ray 4" or whatever
>> POV-Ray 4 stands for? I am lost about the history of that ng.
>>
> 
...
> 
> I do not know if there is any correlation between pov4 and povr.

None.

My povr branch implements some things 'I' think should be part of any 
povray 4.0.

> 
> For me, povr (as well as hgpovray38) is a divergent work from official
> povray (3.8 not yet published), so it would have been better to continue
> in p.u.patches .
> 

The povr branch has only been 'published' as a patch/tarball.

I've been mentioning the work in other newsgroups when I think it helps 
along a POV-Ray discussions or when a povr update has been driven by a 
bug or discussion in some newsgroup.

It's also true I've borrowed the povray.beta-test.binaries newsgroup to 
publish some of the functionality. In not being mirrored to the web 
interface that group mostly doesn't show up to regular users, but was 
thinking my 'ideas' for the future are at least documented in a place 
later povray developers can find along with code in an occasionally 
published tar ball.

...I see on coming back, discussions in other newsgroups where I could 
chime in with detail and stuff only povr at the moment can do - though 
much of the basic infrastructure is there in POV-Ray already.

But, I see your point too. Mention of povr, other than here, is 
confusing and noise to all but a 'very few' users. Unlike your branch 
and Dick's, the povr branch is not in total compatible with v3.8 master.

I'll aim to limit povr mentions to this newsgroup. I'll still put 
tarballs in povray.binaries.programming when I happen to get something 
together.

No one should take povr as other than my personal branch!

Aside: I am mostly busy with real life for a bit (a week?). I need to do 
my US taxes :-( Plus, get after some other too long put off tasks about 
the home.

Bill P.

Post a reply to this message

Op 25/02/2021 om 16:33 schreef William F Pokorny:
> On 2/22/21 11:40 AM, Le_Forgeron wrote:
>> Le 22/02/2021 à 08:43, Thomas de Groot a écrit :
>>
>>> Just out of curiosity: How is this related to "POV-Ray 4" or whatever
>>> POV-Ray 4 stands for? I am lost about the history of that ng.
>>>
>>
> ...
>>
>> I do not know if there is any correlation between pov4 and povr.
> 
> None.
> 
> My povr branch implements some things 'I' think should be part of any 
> povray 4.0.
> 
>>
>> For me, povr (as well as hgpovray38) is a divergent work from official
>> povray (3.8 not yet published), so it would have been better to continue
>> in p.u.patches .
>>
> 
> The povr branch has only been 'published' as a patch/tarball.
> 
> I've been mentioning the work in other newsgroups when I think it helps 
> along a POV-Ray discussions or when a povr update has been driven by a 
> bug or discussion in some newsgroup.
> 
> It's also true I've borrowed the povray.beta-test.binaries newsgroup to 
> publish some of the functionality. In not being mirrored to the web 
> interface that group mostly doesn't show up to regular users, but was 
> thinking my 'ideas' for the future are at least documented in a place 
> later povray developers can find along with code in an occasionally 
> published tar ball.
> 
> ...I see on coming back, discussions in other newsgroups where I could 
> chime in with detail and stuff only povr at the moment can do - though 
> much of the basic infrastructure is there in POV-Ray already.
> 
> But, I see your point too. Mention of povr, other than here, is 
> confusing and noise to all but a 'very few' users. Unlike your branch 
> and Dick's, the povr branch is not in total compatible with v3.8 master.
> 
> I'll aim to limit povr mentions to this newsgroup. I'll still put 
> tarballs in povray.binaries.programming when I happen to get something 
> together.
> 
> No one should take povr as other than my personal branch!
> 
> Aside: I am mostly busy with real life for a bit (a week?). I need to do 
> my US taxes :-( Plus, get after some other too long put off tasks about 
> the home.
> 
> Bill P.
> 
> 

Please go on posting about povr (and Le_Forgeron about hgpovray38) 
wherever you see the necessity. Those are important works which I follow 
with interest, even if most of the time the content goes way over my 
head. ;-)  I see them as beachheads for any future version of POV-Ray, 
even an official version 3.8, but certainly higher, being that 4.0 or 
3.9+. Keep up the good work!

In the meantime, there is the matter of all the current includes files 
to consider too for instance, as I was made aware of again. I would 
gladly contribute to their upgrading to more modern standards where 
textures and such are concerned. However, I have some misgivings about 
my role as I know that health issues in my close family environment in 
the (near) future may seriously hamper or stop my contribution. Otoh, I 
always could start something of course and see where it leads me...

[Good luck with the taxes. Mine (NL) are coming up next month.]

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> > Aside: I am mostly busy with real life for a bit (a week?). I need to do
> > my US taxes

Don't worry Bill, the income tax, an unConstitutional unapportioned direct tax
is merely a temporary wartime measure.   Just like the 14 day lockdown to
"flatten the curve".  :|

Government: You owe us money.
Citizen: I do? How much do I owe?
Government: YOU have to figure that out.
Citizen: So, I just pay what I want?
Government: No - we know _exactly_ how much you owe, but it's up to you to
figure out how much that is.
Citizen: What if I get it wrong?
Government: You go to prison.

> Please go on posting about povr (and Le_Forgeron about hgpovray38)
> wherever you see the necessity. Those are important works which I follow
> with interest, even if most of the time the content goes way over my
> head. ;-)  I see them as beachheads for any future version of POV-Ray,
> even an official version 3.8, but certainly higher, being that 4.0 or
> 3.9+. Keep up the good work!

Yes indeed.  All of the summaries and ponderings, and unravelings of existing
code are instructive - they provide a peek under the hood, familiarize me with
the thought processes and caveats involved in source-side raytracing, and
illustrate the problems, tradeoffs, and solutions.  Things I may not have
understood 5 years ago, I will often find myself referencing multiple times as I
toy with new ideas and leap out off the edge in reckless pursuit of new
knowledge.  :D

> In the meantime, there is the matter of all the current includes files
> to consider too for instance, as I was made aware of again. I would
> gladly contribute to their upgrading to more modern standards where
> textures and such are concerned.

Hopefully most things like this will be some simple elimination of ambient in
finishes, and other things that can be quickly addressed with some good old
find-and-replace.

> However, I have some misgivings about
> my role as I know that health issues in my close family environment in
> the (near) future may seriously hamper or stop my contribution. Otoh, I
> always could start something of course and see where it leads me...

Good luck with the health issues - they catch up to us all no matter what we do.

Post a reply to this message