El 27/04/16 a las 10:05, Thomas de Groot escribió:
> Ah yes, the cloud bottom was a problem indeed.

   BTW, I've just found a way to avoid the "bottom" problem with df3
clouds: do not use the df3 directly on the density, but declare it first
as a pigment, then use it on a "gradient y" density map with a less
turbulent version at the bottom. Works nicely...

       density{
         gradient y
         density_map{
           [0 pigment_pattern{p_df3}
             ...little turbulence at bottom...
           ]
           [1 pigment_pattern{p_df3}
             ...full turbulence at the top...
           ]
         }
       }


--
jaime

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:

> > Awesome. I look forward to this time next year when the full size
> > version finishes rendering!
>
>    Thanks, but it's not that slow... that test took just 29 min, and the
> one attached here, using +a, took 1h45m using only 4 out of 6 cores. I
> guess the full render at 1600x900 will take about 4 hours with 6 cores.
> The idea of using a blob as container, instead a box or sphere, works
> pretty well... it's just a shame it generates some artifacts. :(

I guess the blob containers makes for fewer media calculations - that's a decent
time for such a render.

What causes the artifacts, is it something about the way blobs are implemented?
How about using a merge of the blob component spheres instead?

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:

> > Awesome. I look forward to this time next year when the full size
> > version finishes rendering!
>
>    Thanks, but it's not that slow... that test took just 29 min, and the
> one attached here, using +a, took 1h45m using only 4 out of 6 cores. I
> guess the full render at 1600x900 will take about 4 hours with 6 cores.
> The idea of using a blob as container, instead a box or sphere, works
> pretty well... it's just a shame it generates some artifacts. :(
>
> --
> jaime

I feel for you concerning the artifacts. I have tried all kinds of tricks to get
rid of them and usually end up in a worse place than I began with. Blasted
container objects! May they be for ever confined to the ninth circle of hell
(the one reserved for treachery)!

I ended up using a single containing object (box or plane) and then filling it
with a skewed y-gradient density to get a flat bottom and then adding a mixture
of wrinkles, bozo and crackle (form<1, 0, 0>) to try to approximate fluffy tops.
Some of my images over at www.landofthefirst.com were created using this. I am
still not 100% happy with them.

I think your idea much better (and I love the results). More ideas to play with.

Post a reply to this message

On 28-4-2016 12:59, Jaime Vives Piqueres wrote:
> El 27/04/16 a las 10:05, Thomas de Groot escribió:
>> Ah yes, the cloud bottom was a problem indeed.
>
>    BTW, I've just found a way to avoid the "bottom" problem with df3
> clouds: do not use the df3 directly on the density, but declare it first
> as a pigment, then use it on a "gradient y" density map with a less
> turbulent version at the bottom. Works nicely...

Thanks! Shall try!

-- 
Thomas

Post a reply to this message

> What causes the artifacts, is it something about the way blobs are
> implemented? How about using a merge of the blob component spheres
> instead?

   Damn... that was so obvious and easy! Indeed it works great, thanks!
Currently rendering with your solution the exact same clouds for comparison.

--
jaime

Post a reply to this message

> I ended up using a single containing object (box or plane) and then filling it
> with a skewed y-gradient density to get a flat bottom and then adding a mixture
> of wrinkles, bozo and crackle (form<1, 0, 0>) to try to approximate fluffy tops.
> Some of my images over at www.landofthefirst.com were created using this. I am
> still not 100% happy with them.

   The ones at Othil Homtoh look very nice...

--
jaime

Post a reply to this message

On 04/28/2016 07:04 AM, Bill Pragnell wrote:
> Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:

>>> Awesome. I look forward to this time next year when the full size
>>> version finishes rendering!
>>
>>     Thanks, but it's not that slow... that test took just 29 min, and the
>> one attached here, using +a, took 1h45m using only 4 out of 6 cores. I
>> guess the full render at 1600x900 will take about 4 hours with 6 cores.
>> The idea of using a blob as container, instead a box or sphere, works
>> pretty well... it's just a shame it generates some artifacts. :(
>
> I guess the blob containers makes for fewer media calculations - that's a decent
> time for such a render.
>
> What causes the artifacts, is it something about the way blobs are implemented?
> How about using a merge of the blob component spheres instead?
>

Answering without going back to refresh my old brain cells...

When Gail Shaw hit this issue back in 2005. At that time Slime wrote:

-------
This is probably just a problem with the accuracy of the blob solver; I 
think it's not noticing the second (backside) surface near the edges, so 
it thinks there's a long distance of media and makes it very bright as a 
result. (In 3.5 this may have been diminished by anti-aliasing.)

A suggestion: Use a small box as your media container instead of a blob, 
and then use a density{} in the media with the object pattern with the 
blob, so that all points outside of the blob have no media.

- Slime
-------

In my digging I've found blob surfaces are actually a bit noisy 
especially as the rays hit the surface in a more tangential way - so I 
think Slime's thinking as to the cause is probably right.

Things that tend to help:

1) Try running with sturm off.

2) Lower the blob threshold - start extreme with 0.0001 say - though you 
may of course lose the blob effect you want, but perhaps in the case of 
these clouds this would be OK?

3) The code change I have been working to verify against blob problem 
cases from years past tends to help a little with bright artifacts - 
more with dark artifacts. Specifically the change in blob.cpp is changing:

const DBL DEPTH_TOLERANCE = 1.0e-2;

to:

const DBL DEPTH_TOLERANCE = 1.0e-4;

4) AA sometimes helps - and sometimes not - depending on how tangential 
the super samples themselves are I guess.

5) What the other Bill P suggested should help too - if the merge 
eliminates internal blob surfaces causing the artifacts.

Hope one or more things here enough to get this cloud method working 
generally.

Bill P.

Post a reply to this message

> Hope one or more things here enough to get this cloud method working
> generally.

   Thanks for the detailed explanation, but in this case the best
solution was the one the other Bill P. suggested. A merge of spheres
with same radius and placement did work pretty well, and in this case it
doesn't matter as it is an invisible container. It still does the job of
being a close container, and the speed up provided is even a little
better too.

--
jaime

Post a reply to this message

Attachments:
Download 'ocean-18c.jpg' (130 KB)

Preview of image 'ocean-18c.jpg'

On 04/28/2016 08:44 AM, Jaime Vives Piqueres wrote:

>> Hope one or more things here enough to get this cloud method working
>> generally.
>
>    Thanks for the detailed explanation, but in this case the best
> solution was the one the other Bill P. suggested. A merge of spheres
> with same radius and placement did work pretty well, and in this case it
> doesn't matter as it is an invisible container. It still does the job of
> being a close container, and the speed up provided is even a little
> better too.
>
> --
> jaime
>

Great! At least it was one of the Bill P's helped out... :-)

Perhaps I missed it, but are these renders with 3.7.0 or that latest 
3.7.1 ?

Asking because Christoph made media related fixes in 3.7.1 which in my 
few experiences help both performance and result.

Bill P.

Post a reply to this message

> Perhaps I missed it, but are these renders with 3.7.0 or that latest
> 3.7.1 ?

   3.7.1, latest alpha...

> Asking because Christoph made media related fixes in 3.7.1 which in my
> few experiences help both performance and result.

   I didn't know, but yes, that must have helped too...

--
jaime

Post a reply to this message