An attempt a semi-arid ground cover using three isosurfaces and 
turbulence enabled via the raw_wave keyword discussed in this thread:

http://news.povray.org/povray.beta-test.binaries/thread/%3C5daec47c%241%40news.povray.org%3E/

Not sure how good it looks, but it's relatively quick to create. A 
1200x750 with AA render took 16 minutes on my two core i3. Posting 
smaller jpg as the detail makes for large image files.

The trick is one I've posted before. It uses violent turbulence along 
with purposely setting the isosurface gradient relatively low to get 
fuzzy - even cloud-ish like 'stuff.' The isosurface gradient becomes a 
knob for controlling the fuzzy 'density.' No AA much faster, but it's 
the AA that makes hard and fuzzy; soft and fuzzy. ;-)

Previously method based on my df3 patch as I didn't have 'raw_wave', but 
for this one the base shape just a thin z plane sheet. Oh yeah, not all 
that apparent, but the sheet also displaced with the fixed radial 
pattern using a sine_wave modifier - the ground isn't flat.

Bill P.

Post a reply to this message

Attachments:
Download 'groundcovertest.jpg' (176 KB)

Preview of image 'groundcovertest.jpg'

Op 22/10/2019 om 11:20 schreef William F Pokorny:
> An attempt a semi-arid ground cover using three isosurfaces and 
> turbulence enabled via the raw_wave keyword discussed in this thread:
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5daec47c%241%40news.povray.org%3E/

> 

this goes way beyond my understanding but I appreciate the work 
undertaken here.

> 
> Not sure how good it looks, but it's relatively quick to create. A 
> 1200x750 with AA render took 16 minutes on my two core i3. Posting 
> smaller jpg as the detail makes for large image files.
> 

One could interpret it both as a landscape, or as a rugged texture for a 
rocky surface I guess. Interesting stuff.

> The trick is one I've posted before. It uses violent turbulence along 
> with purposely setting the isosurface gradient relatively low to get 
> fuzzy - even cloud-ish like 'stuff.' The isosurface gradient becomes a 
> knob for controlling the fuzzy 'density.' No AA much faster, but it's 
> the AA that makes hard and fuzzy; soft and fuzzy. ;-)
> 
> Previously method based on my df3 patch as I didn't have 'raw_wave', but 
> for this one the base shape just a thin z plane sheet. Oh yeah, not all 
> that apparent, but the sheet also displaced with the fixed radial 
> pattern using a sine_wave modifier - the ground isn't flat.
> 

This calls for getting dirty hands! ;-)

Code available?

-- 
Thomas

Post a reply to this message

On 10/23/19 2:34 AM, Thomas de Groot wrote:
> Op 22/10/2019 om 11:20 schreef William F Pokorny:
>> An attempt a semi-arid ground cover using three isosurfaces and 
>> turbulence enabled via the raw_wave keyword discussed in this thread:
> 
> This calls for getting dirty hands! ;-)
> 
> Code available?
> 

A version of POV-Ray as a branch - or compiled release - is not yet 
available. It will be late next week best case for a published code 
branch due real life time and my being busy with related function, 
pattern and wave updates in the near-term hobby time I have(1).

Are you able to compile personal versions of POV-Ray?

I cleaned up the scene this morning as instructive of technique even 
without a version of POV-Ray with which to use it.

I'd mentioned no AA renders were faster. A 800x600 render of the 
attached scene took 26 seconds on my two core i3.

Bill P.

(1) I have a list of common operations I believe should be shipped as 
inbuilt, pre-compiled helper functions. I'm playing with the form and 
measure of some of them.

Post a reply to this message

Attachments:
Download 'groundcovertdg.pov.txt' (4 KB)

Op 23/10/2019 om 15:38 schreef William F Pokorny:
> On 10/23/19 2:34 AM, Thomas de Groot wrote:
>> Op 22/10/2019 om 11:20 schreef William F Pokorny:
>>> An attempt a semi-arid ground cover using three isosurfaces and 
>>> turbulence enabled via the raw_wave keyword discussed in this thread:
>>
>> This calls for getting dirty hands! ;-)
>>
>> Code available?
>>
> 
> A version of POV-Ray as a branch - or compiled release - is not yet 
> available. It will be late next week best case for a published code 
> branch due real life time and my being busy with related function, 
> pattern and wave updates in the near-term hobby time I have(1).
> 
> Are you able to compile personal versions of POV-Ray?

I prefer to wait for a release; no hurry ;-)

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

> 
> I'd mentioned no AA renders were faster. A 800x600 render of the 
> attached scene took 26 seconds on my two core i3.

That's fast.

> 
> Bill P.
> 
> (1) I have a list of common operations I believe should be shipped as 
> inbuilt, pre-compiled helper functions. I'm playing with the form and 
> measure of some of them.


-- 
Thomas

Post a reply to this message

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'