 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I managed to squeak in some work on some basic CSG items I'll be using for
scenes.
Definitely need to work on the metal textures, and it's very obvious that the
skysphere, lighting, and angle have very significant effects on the rendered
appearance.
My lighting and textures are still craptastically rudimentary, but like many
things, it's a WIP...
I've noticed that when I tried to overlay the benchtop with a thin box patterned
with some granite/agate smudge and the rest of the color_map is rgbt <0, 0, 0,
1> or rgbt <1, 1, 1, 1> , I get a pronounced darkening of the underlying
benchtop.
{During writing, it occurred to me that it might be a coincident surface
problem, and I raised the layer 0.001, and it's fine now - just putting this
here for future reference / solution}
As an aside,
Searching for povray metal textures I actually found someone else who modeled a
heatsink:
https://en.wiki2.org/wiki/File:Heatsink_povray.png
and was shocked to find that the associated SDL source took 38 min to render on
my machine. :O Must be those area lights...
My whole 9-heatsink scene takes 26 sec.
Post a reply to this message
Attachments:
Download 'heatsink1.png' (1780 KB)
Preview of image 'heatsink1.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I managed to squeak in some work on some basic CSG items I'll be using for
> scenes.
>
> Definitely need to work on the metal textures, and it's very obvious that the
> skysphere, lighting, and angle have very significant effects on the rendered
> appearance.
>
> My lighting and textures are still craptastically rudimentary, but like many
> things, it's a WIP...
>
> I've noticed that when I tried to overlay the benchtop with a thin box patterned
> with some granite/agate smudge and the rest of the color_map is rgbt <0, 0, 0,
> 1> or rgbt <1, 1, 1, 1> , I get a pronounced darkening of the underlying
> benchtop.
> {During writing, it occurred to me that it might be a coincident surface
> problem, and I raised the layer 0.001, and it's fine now - just putting this
> here for future reference / solution}
>
> As an aside,
> Searching for povray metal textures I actually found someone else who modeled a
> heatsink:
> https://en.wiki2.org/wiki/File:Heatsink_povray.png
> and was shocked to find that the associated SDL source took 38 min to render on
> my machine. :O Must be those area lights...
...or inefficient coding.
It uselessly use a merge of 2 boxes and 38 cylinders, most of witch are
later removed.
That merge is the base shape for a difference where you chop off 20
boxes to carve the channels between the fins.
For each pixels, you need to totally evaluate the 62 components.
Also, the 3 10 by 10 non-adaptive area_light are performance killers.
A better approach would have been to have the base plate, then add the
121 fins elements and add the fixations in an union.
> My whole 9-heatsink scene takes 26 sec.
>
For the metals:
Set ambiant to zero.
Always use metallic reflection and highlights.
Use uberpov to be able to use blurred reflection.
Have a low diffuse.
Diffuse + reflection must be less than 1.
Brilliance is usually set between 2 and 7.
An interesting environment is important.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.08.2016 um 16:10 schrieb Bald Eagle:
> I managed to squeak in some work on some basic CSG items I'll be using for
> scenes.
(I guess when schedules are tight we all feel like squeaking from time
to time ;) -- SCNR)
Heat sinks are crucially important for render performance, so keep up
the work! ;)
> Definitely need to work on the metal textures, and it's very obvious that the
> skysphere, lighting, and angle have very significant effects on the rendered
> appearance.
One common group of mistakes when trying to model metals (and one which
I suspect you fell for) is to use non-zero `diffuse` and/or `emission`
(or `ambient` in older scenes) in the finish.
As for `emission` (or an uncommonly high `ambient` value), I guess it is
by now commonly known that it is an absolute no-go for /any/ material
that doesn't actually glow in the dark.
As for `diffuse`, this mechanism is only useful for modelling materials
in which the dull appearance results primarily from /subsurface
scattering/, i.e. light actually entering the material, getting
scattered around maybe a few hundred times on average, and ultimately
leaving the material again in a virtually random direction.
In metals however, light /never/ enters the material itself. Instead,
when metals appear dull, this is exclusively due to a more or less
pronounced roughness of the surface. As a result the direction of the
outgoing light is only somewhat random, and is still more or less
centered on the direction in which a perfect mirror would reflect.
Consequently, using non-zero `diffuse` in metals is also a no-go --
except to model some evenly distributed contamination of the surface,
such as dust or certain forms of tarnish (note in this context that the
self-protecting oxide layer that naturally forms on aluminium is
virtually transparent, and therefore does not warrant any noteworthy
`diffuse`).
Instead, to model dull bare metals you have essentially two options:
(A) Use a patched version of POV-Ray specifically designed to model dull
specular reflection (such as MCPov or UberPOV).
(B) Model the roughness of the surface using the `normal` statement,
using a random pattern (e.g. `bumps`) scaled to very small size, an
approach known as "micronormals".
Note that the micronormals approach will result in quite noisy images,
and you will have to force oversampling of either the entire image or
the dull metllic surfaces, which can be achieved in a multitude of ways:
(a) Use high-quality anti-aliasing. Note however that the anti-aliasing
modes built into official POV-Ray may not always effectively combat the
type of resulting noise. Also, high-quality anti-aliasing also increases
render time in other portions of the image.
(b) Use a miniscule amount of focal blur with high quality settings.
This does quite a decent work at oversampling noisy portions of the
image. However, it still increases render time in other portions of the
image.
(c) Use a layered texture with a high number of layers, all defined
virtually identical except for an offset in the `normal` statement. This
not only limits the oversampling to where the dull metallic surfaces are
visible in the image, but to the reflection at that surface itself. The
drawback is that this oversampling is not adaptive.
(If you go for (c) and a /very/ high number of layers, there is an
alternative to micronormals, known as "macronormals": Rather than
scaling the normals very small, they are scaled very large and offset
even larger. Some people claim this approach gives a superior look.
However, it has the major disadvantage that it cannot benefit from any
anti-aliasing or focal blur you may happen to be using anyway.)
> As an aside,
> Searching for povray metal textures I actually found someone else who modeled a
> heatsink:
> https://en.wiki2.org/wiki/File:Heatsink_povray.png
> and was shocked to find that the associated SDL source took 38 min to render on
> my machine. :O Must be those area lights...
They do play a role indeed. Adding `adaptive 0` to the area lights
speeds up the scene by a factor of 4; demoting them to straightforward
point light sorces really lets the scene take off.
However, the main factor is the careless use of `difference`. For
instance, a heat sink modeled as a union of a base and 11x11 = 121
individual "fingers" renders about 10 times as fast as a heat sink
modeled as a single block with 2x10 = 20 "grooves" cut into it.
As a rule of thumb, avoid `difference` wherever possible.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> One common group of mistakes when trying to model metals (and one which
> I suspect you fell for) is to use non-zero `diffuse` and/or `emission`
> (or `ambient` in older scenes) in the finish.
I started off with the "stock" metals in textures.inc, and yes, they had ambient
and diffuse values. I just commented those out. I ought to do that with all
of the textures there, and probably revamp the whole thing, given all we've
learned about good metal textures over the last 15 years or so.
> In metals however, light /never/ enters the material itself.
Well, Feynman's lectures on QED make me question everything I've ever "learned"
about light, but that's material for a WHOLE 'nother discussion.
> However, the main factor is the careless use of `difference`. For
> instance, a heat sink modeled as a union of a base and 11x11 = 121
> individual "fingers" renders about 10 times as fast as a heat sink
> modeled as a single block with 2x10 = 20 "grooves" cut into it.
>
> As a rule of thumb, avoid `difference` wherever possible.
Really??? My heatsinks are ALL primarily made with loops of differences. I
try to avoid them, after reading Mike Williams' page about holes, but they are
convenient. It must be something else slowing down that scene.
I'm making NINE heatsinks, and that's only one.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.08.2016 um 22:55 schrieb Bald Eagle:
>> However, the main factor is the careless use of `difference`. For
>> instance, a heat sink modeled as a union of a base and 11x11 = 121
>> individual "fingers" renders about 10 times as fast as a heat sink
>> modeled as a single block with 2x10 = 20 "grooves" cut into it.
>>
>> As a rule of thumb, avoid `difference` wherever possible.
>
> Really??? My heatsinks are ALL primarily made with loops of differences. I
> try to avoid them, after reading Mike Williams' page about holes, but they are
> convenient. It must be something else slowing down that scene.
Sorry, I made the "main factor" statement above in error, based on the
factor 4 speedup for making the area lights adaptive. I hadn't measured
the speedup for eliminating the area lights classic entirely.
It turns out that the area lights account for a factor of about 40,
which is obviously more than the factor of 10 for the differences.
Still, avoiding differences does pay off -- and in contrast to avoiding
area lights it doesn't reduce the render quality.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
