 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] ignorancia org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> > 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
Here is the code:
#macro SkyShell(minAlt, maxAlt, Int)
difference
{
sphere {<0, 0, 0> 1000000+maxAlt}
sphere {<0, 0, 0> 1000000+minAlt}
hollow
texture {pigment {color rgbf 1}}
interior {Int}
translate <0, -1000000, 0>
}
#end
SkyShell(4000, 5000,
interior {
media {
method 3
samples 20
scattering {2, color rgb 0.0075 extinction 1}
density
{
wrinkles
scale <4000, 1000, 4000>
warp { turbulence 2 }
lambda 4
color_map
{
[0.00 color rgb 1.0]
[0.50 color rgb 0.8]
[0.55 color rgb 0.0]
[1.00 color rgb 0.0]
}
translate <-4000, 0, -1000>
}
density
{
gradient y
scale 1000
color_map
{
[0.0 color rgb 0.00]
[0.4 color rgb 1.00]
[0.9 color rgb 1.00]
[1.0 color rgb 0.00]
}
}
}
}
)
I lied. It was concentric spheres!
And nice solution for the artifacts! One to remember.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/26/2016 12:39 PM, Jaime Vives Piqueres wrote:
>> Nice and fluffy as it should be.
>
> Thanks... perhaps too fluffy, tough.
>
>> The method of averaging object patterns will be of further use - at
>> least I hope
>> so...
>
> Well, it's nothing fancy, just the average pattern. The real trick is
> that the averaged blobs are concentric (with diminishing radius and the
> same threshold):
maybe i'm misunderstanding ... more complicated than taking the base
blob object and making scaled copies?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> maybe i'm misunderstanding ... more complicated than taking the base
> blob object and making scaled copies?
Just scaling down the copies only works for objects which are
symmetric on all axes. Scaling down an irregular, asymmetric blob makes
some components to be displaced towards the center, thus they get
outside the component on the original copy (and yes, I too though it
would work and tried that first... ;).
--
jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 04/28/2016 08:44 AM, Jaime Vives Piqueres wrote:
> > 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.
> >
>
> Great! At least it was one of the Bill P's helped out... :-)
>
> Bill P.
Haha, I keep meaning to call this out. Too many Bill Ps! At least you come up as
a William on your account name, that saves huge confusion on the digest page (I
usually use the web view).
Jaime, glad my suggestion worked well. Honestly I nearly didn't say anything, I
thought it was too obvious and that you were bound to have tried it already! I
shall wheel out random suggestions more often in that case :)
Bill (the other P)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
