On 10/24/19 6:52 AM, Thomas de Groot wrote:
> Op 23/10/2019 om 15:38 schreef William F Pokorny:
...
>>
>> Are you able to compile personal versions of POV-Ray?
> 
> I prefer to wait for a release; no hurry ;-)

:-) In that, I expect you intended to touch upon my standing quandary.

Prior to bailing on pull requests altogether, nothing of mine got into 
POV-Ray proper after an initial set of 30 or so commits - and that's OK. 
It just is. Nobody is being paid to deal with my pile of junk or to do 
the grunt work of releases.

My recent path has been to do what I'm interested in and to provide that 
code as branches so anyone interested - and compiling versions of 
POV-Ray themselves - can play.

To do releases requires I commit to doing them in some fashion - that I 
commit time. Against such an investment I'm looking of late at 
relatively major code and structural changes to finish off the solver 
stuff I've been at a long time; at a practical break with the official 
POV-Ray code base.

I'm uncertain how to proceed with my hobby. This VM / pattern / built in 
function stuff of late(1) is me procrastinating.

In any case, it's good you're in no hurry for a release of my recent 
changes! :-)

(1) - A faster multi-object pattern capability is on my list of ideas 
for additional inbuilt functions, but not one near the top. It's the 
case the inside testing, upon which the object pattern is built, is 
often slow.

> 
>>
>> I cleaned up the scene this morning as instructive of technique even 
>> without a version of POV-Ray with which to use it.
> 
> I shall study this; Thank you indeed.
> 

Sorry to see this morning my scrub failed to remove three pointless 
declares in Jade0, FnRadialRaw and FnYYOffRaw.

The technique boils down to having raw_wave, three turbulence 
specifications applied to three y plane 'sheets' and the three gradient 
values to dial in how much of the turbulence fuzz the rays pick up. The 
rest is normal scene stuff - at which you are more capable than me.

I'm away now for several days.

Bill P.

Post a reply to this message

Op 24/10/2019 om 16:57 schreef William F Pokorny:
> On 10/24/19 6:52 AM, Thomas de Groot wrote:
>> Op 23/10/2019 om 15:38 schreef William F Pokorny:
> ...
>>>
>>> Are you able to compile personal versions of POV-Ray?
>>
>> I prefer to wait for a release; no hurry ;-)
> 
> :-) In that, I expect you intended to touch upon my standing quandary.
> 
> Prior to bailing on pull requests altogether, nothing of mine got into 
> POV-Ray proper after an initial set of 30 or so commits - and that's OK. 
> It just is. Nobody is being paid to deal with my pile of junk or to do 
> the grunt work of releases.
> 
> My recent path has been to do what I'm interested in and to provide that 
> code as branches so anyone interested - and compiling versions of 
> POV-Ray themselves - can play.
> 
> To do releases requires I commit to doing them in some fashion - that I 
> commit time. Against such an investment I'm looking of late at 
> relatively major code and structural changes to finish off the solver 
> stuff I've been at a long time; at a practical break with the official 
> POV-Ray code base.
> 
> I'm uncertain how to proceed with my hobby. This VM / pattern / built in 
> function stuff of late(1) is me procrastinating.
> 
> In any case, it's good you're in no hurry for a release of my recent 
> changes! :-)
> 
> (1) - A faster multi-object pattern capability is on my list of ideas 
> for additional inbuilt functions, but not one near the top. It's the 
> case the inside testing, upon which the object pattern is built, is 
> often slow.
> 

In general I prefer to keep clear of compiling as such. It is not my 
strongest point nor my primary interest. However, I hope that, one way 
or another, your investigations get into the main branch somehow. I 
guess there are lot of goodies worth to be offered to the simple users 
at large, like me :-)

>>
>>>
>>> I cleaned up the scene this morning as instructive of technique even 
>>> without a version of POV-Ray with which to use it.
>>
>> I shall study this; Thank you indeed.
>>
> 
> Sorry to see this morning my scrub failed to remove three pointless 
> declares in Jade0, FnRadialRaw and FnYYOffRaw.
> 
> The technique boils down to having raw_wave, three turbulence 
> specifications applied to three y plane 'sheets' and the three gradient 
> values to dial in how much of the turbulence fuzz the rays pick up. The 
> rest is normal scene stuff - at which you are more capable than me.
> 

Oh well, I shall do my best. I find your basic technique interesting and 
shall first investigate how using other wave forms apply.

> I'm away now for several days.
> 
> Bill P.


-- 
Thomas

Post a reply to this message

I love this isosurface technique of yours!

Here is an example of my tweaking. I had to increase threshold to about 
0.5 as at 0.0 nothing showed up. I replaced raw_wave by poly_wave 0.16 
for the green and by sine_wave for the other two patterns. I also played 
around with (scaled) warp {turbulence} instead of turbulence. And 
finally, I used different values of accuracy for the different 
isosurfaces. Did also a bit of work on the textures.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'wfp_groundcovertdg.png' (971 KB)

Preview of image 'wfp_groundcovertdg.png'

On 11/4/19 6:51 AM, Thomas de Groot wrote:
> I love this isosurface technique of yours!
> 
> Here is an example of my tweaking. I had to increase threshold to about 
> 0.5 as at 0.0 nothing showed up. I replaced raw_wave by poly_wave 0.16 
> for the green and by sine_wave for the other two patterns. I also played 
> around with (scaled) warp {turbulence} instead of turbulence. And 
> finally, I used different values of accuracy for the different 
> isosurfaces. Did also a bit of work on the textures.
> 

Ah, cool! Glad you got it to work. I'm so used to working at a threshold 
of 0 for isosurfaces I didn't even think about changing it so the new 
raw_wave was not needed(1).

What I intended to be dead / dried ground cover shows up much better in 
your render too (your poly_wave use maybe? (2)).

Playing with accuracy is a good idea too. I didn't think to try that and 
I expect it a useful 'effects knob' here like gradient.

Bill P.

(1) - The new raw_wave keyword is necessary for stuff to show up at a 
threshold of 0 (to show up reliably). An implication of changing the 
threshold is the 'vertical' position of everything moves with that 
change, but it makes this a workable technique today.

(2) - Still on my list to introduce something like a 'function_mode' 
keyword which like 'raw_wave' will allow functions to generally work 
with wave modifiers. Unlike 'raw_wave,' it would continue to enable 
access to all the wave modifiers - poly_wave etc. I was calling this 
'function_wave,' but think now 'function_mode' a better name for what it 
will do. Namely, change the behavior of wave modifications so as to be 
function compatible (thinking all to a -1 to 1 range instead of 0 to 1, 
but otherwise doing the same sort of wave-shaping thing they do today(3)).

(3) - On my todo list is to someday think more about how the new to 3.8 
blend_mode, blend_gamma overlap (and not) with the existing pattern wave 
modifiers. Carrying a question since the blend_* keywords introduced(3a) 
about whether we really needed blend_gamma, but something for another day.

(3a) - ... and that blend_gamma isn't applied to the filter and transmit 
channels and perhaps it should always be - or that we should use 
poly_wave over blend_gamma when we want this behavior ...

Post a reply to this message

Op 04/11/2019 om 14:57 schreef William F Pokorny:
> On 11/4/19 6:51 AM, Thomas de Groot wrote:
>> I love this isosurface technique of yours!
>>
>> Here is an example of my tweaking. I had to increase threshold to 
>> about 0.5 as at 0.0 nothing showed up. I replaced raw_wave by 
>> poly_wave 0.16 for the green and by sine_wave for the other two 
>> patterns. I also played around with (scaled) warp {turbulence} instead 
>> of turbulence. And finally, I used different values of accuracy for 
>> the different isosurfaces. Did also a bit of work on the textures.
>>
> 
> Ah, cool! Glad you got it to work. I'm so used to working at a threshold 
> of 0 for isosurfaces I didn't even think about changing it so the new 
> raw_wave was not needed(1).
> 
> What I intended to be dead / dried ground cover shows up much better in 
> your render too (your poly_wave use maybe? (2)).
> 
> Playing with accuracy is a good idea too. I didn't think to try that and 
> I expect it a useful 'effects knob' here like gradient.
> 

The dried, sandy ground is a bit more contrasting thanks to tweaked 
textures, while using sine_wave. the used accuracy is 0.005 and 0.0005 
respectively for these two isosurfaces. In contrast, the vegetation uses 
poly_wave, a scale-dependent warp turbulence, and a still smaller 
accuracy (0.00005).

-- 
Thomas

Post a reply to this message

Just for the fun of it, I added radiosity.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'wfp_groundcovertdg.png' (855 KB)

Preview of image 'wfp_groundcovertdg.png'

On 11/12/19 7:23 AM, Thomas de Groot wrote:
> Just for the fun of it, I added radiosity.
> 
Neat! Looks good.

Bill P.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Just for the fun of it, I added radiosity.
>
> --
> Thomas

The original looks good but it looks even better with radiosity.

Post a reply to this message

Op 12/11/2019 om 13:23 schreef Thomas de Groot:
> Just for the fun of it, I added radiosity.
> 

Indeed. More could be done I am sure with some more smart work on the 
individual textures. If I find the time... ;-)

-- 
Thomas

Post a reply to this message

Op 22/11/2019 om 10:31 schreef s.day:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Just for the fun of it, I added radiosity.
>>
>> --
>> Thomas
> 
> The original looks good but it looks even better with radiosity.
> 

Indeed. More could be done I am sure with some more smart work on the 
individual textures. If I find the time...

-- 
Thomas

Post a reply to this message