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.

I believe it essential to any vibrant future for includes, scene files 
and documentation to each have their own code control repositories and 
multiple gate keepers. Further we should have additional repositories 
such as 'tools' an 'tutorials'. I don't want to put stuff on the wiki I 
don't believe should, in the end, be on a wiki.

I'm struggling with when to 'really' document as some areas of code are 
still churning. I've posted on line in detail about many of the changes 
and new features. I hope to use a lot of those images and that text in 
any final documentation.

The final form of the inbuilt functions - where I have replaced nearly 
everything there previously - is finally settling, but it's not quite 
there. For that I can attach my current functions.inc to this - the base 
intended documentation is in there in text. Some of the new inbuilt 
functions folks could just borrow and use, but some require fixes and 
enhancements in the pattern/function bridge to work properly.

I have too my commit log off v3.8, but it's, of course, not the best 
documentation.

About half of what I've been doing is fixing issues. So, for example, I 
still have fog, but it isn't POV-Ray's fog. I have isosurfaces but 
without the broken evaluate and with a new report on/off.

I went with 'report' as the keyword because I am thinking of extending 
it to more that max gradient warnings and all shapes and surfaces. I 
find the current reporting not all that useful and it isn't free, but 
neither will 'report' control be - I've not done enough testing to trust 
a general report yes/no the way to go. Being able to turn on reporting 
for just one or some of a set of shapes in a scene would be useful.

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?

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.)

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

Attachments:
Download 'functions.inc.txt' (178 KB)