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)
>>> 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.
> 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.
Post a reply to this message