|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi(gh)!
On 07.02.21 03:02, Bald Eagle wrote:
> I worked it all out to my satisfaction at the time:
>
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d3c5fe27be432e04eec112d0%40news.povray.org%3E/?ttop=429839
> &toff=50
>
> It hasn't been implemented anywhere else AFAIK.
Wow! That would be perfect for my gas giants, such as Sagan/Whatmough or
Qais/Ghurghusht!
Which unofficial patch did you use?
See you in Khyberspace!
Yadgar
Now playing: Polonaise (Jon and Vangelis)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> Hi(gh)!
> Wow! That would be perfect for my gas giants, such as Sagan/Whatmough or
> Qais/Ghurghusht!
>
> Which unofficial patch did you use?
When I get some rest and have some more energy and focus, I'm going to try to
make sure it's fully applicable for use with 3D pigment patterns and media.
I figured out how to implement a placement / repetition warp in SDL, and so once
it's all worked out, you should be able to plop multiple spiral warps into a
single pigment pattern definition, and have them all work.
It's gonna be a little complicated, so it may take some time, but the important
parts are figured out - so now it's just making a scene incorporating all of the
pieces, seeing what's broken or missing, and iteratively tweaking it...
No unofficial patch - it was all done in standard POV-Ray 3.8 (qtpovray)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-02-12 8:20 PM (-4), Bald Eagle wrote:
> =?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
>>
>> Which unofficial patch did you use?
>
> No unofficial patch - it was all done in standard POV-Ray 3.8 (qtpovray)
qtpovray *is* an unofficial patch. Do you mean that you used only
standard POV-Ray 3.8 features?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoocom> wrote:
> qtpovray *is* an unofficial patch. Do you mean that you used only
> standard POV-Ray 3.8 features?
I think of a "patch" as a slightly modified version that includes things not
available in the standard version.
AFAIK, qtpovray is just an interface for 3.8 - which is as official as it's
likely to get for a while.
But yes, it's all just standard functions and pigments.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/13/2021 7:17 PM, Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
>> qtpovray *is* an unofficial patch. Do you mean that you used only
>> standard POV-Ray 3.8 features?
>
> I think of a "patch" as a slightly modified version that includes things not
> available in the standard version.
>
> AFAIK, qtpovray is just an interface for 3.8 - which is as official as it's
> likely to get for a while.
One thing I've been pondering lately is that official is stuck/dead. My
plan is to not deviate from that.
OTOH, povr has some interesting features that would be nice to slurp.
And there is the .grey bug that has an easy fix that I really want to
incorporate. What to do?
--
dik
Rendered 50,081,587,200 of 50,081,587,200 pixels (100%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14/02/2021 à 06:46, Dick Balaska a écrit :
> On 2/13/2021 7:17 PM, Bald Eagle wrote:
>> Cousin Ricky <ric### [at] yahoocom> wrote:
>>
>>> qtpovray *is* an unofficial patch. Do you mean that you used only
>>> standard POV-Ray 3.8 features?
>>
>> I think of a "patch" as a slightly modified version that includes
>> things not
>> available in the standard version.
>>
>> AFAIK, qtpovray is just an interface for 3.8 - which is as official as
>> it's
>> likely to get for a while.
>
> One thing I've been pondering lately is that official is stuck/dead. My
> plan is to not deviate from that.
> OTOH, povr has some interesting features that would be nice to slurp.
> And there is the .grey bug that has an easy fix that I really want to
> incorporate. What to do?
>
*sliding surreptitiously on our back*
Do you have some commercials for povr ?
I mean some catalog of all the features that povr has ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] freefr> wrote:
> Le 14/02/2021 à 06:46, Dick Balaska a écrit :
> *sliding surreptitiously on our back*
>
> 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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 19/02/2021 à 00:32, Bald Eagle a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 14/02/2021 à 06:46, Dick Balaska a écrit :
>
>> *sliding surreptitiously on our back*
>>
>> 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|