 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.04.2018 um 08:39 schrieb Kenneth:
> clipka <ano### [at] anonymous org> wrote:
>> Am 05.04.2018 um 19:09 schrieb kurtz le pirate:
>>
>>> - the floor currently uses
>>> finish {
>>> ambient 0.00
>>> emission 0.10
>>
>> No. No. Absolutely no. Unless you /specifically/ want to model something
>> that glows in the dark, do NOT EVER use "emission".
>>
>> If you want to brighten up shadows, use radiosity or "ambient".
>>
>
> That's interesting; I thought ambient and emission were identical in their
> effect (in a non-radiosity scene, that is.) Basically that they are
> interchangable.
And that's /exactly/ the reason: From their effect in /non-radiosity/
scenes they are interchangable, but from both their /intention/ and
their effect in /radiosity/ scenes the two are worlds apart.
Using "emission" to model indirect illumination of shadowy areas so
/utterly/ defies the purpose of the feature that I /must/ rant about it,
as a matter of principle. Kind of like if you'd use "assumed_gamma 500"
or something like that.
Here's some historic background:
Brightening up shadows, to model the indirect illumination they receive
from other objects, is the very thing the "ambient" mechanism was
originally designed to do. The mechanism was literally named for a
technical term denoting this type of illumination: "ambient light". It
was the very first mechanism in a triad of mechanisms.
Next in the triad came radiosity, which serves /exactly/ the same
purpose, albeit with much higher quality. So theoretically, the
"ambient" mechanism and radiosity shouldn't be used together.
However, people figured out that radiosity still picked up the light
from the "ambient" mechanism, which had two consequences:
(1) "Classic" materials (i.e. materials originally designed for
non-radiosity scenes, and therefore using a non-zero "ambient" value)
could not be used in a radiosity scene "as is" -- unless you disabled
the "ambient" mechanism altogether by using "ambient_light 0" in the
global settings.
(2) Light-emitting materials could easily be modeled in radiosity scenes
by co-opting the "ambient" mechanism, setting it to non-zero for that
particular material -- but only if you kept the "ambient" mechanism
enabled by using a non-zero "ambient_light" in the global settings.
So in radiosity scenes, there was frequently a conflict of interest
between disabling the "ambient" mechanism (to re-use existing
materials), and keeping it enabled (to model glowing materials).
To solve this conflicts of interest, the third mechanism in the triad
was introduced in v3.7: The "emission" mechanism was /specifically/
designed to model glowing materials. It does the same in both radiosity
and non-radiosity scenes. "ambient", on the other hand, is now
explicitly intended solely to model ambient light, and is disabled
automatically in radiosity scenes, so that materials can be designed to
work equally well in both radiosity scenes (where ambient light is taken
care of by radiosity) and non-radiosity scenes (where ambient light can
be approximated using the simpler "ambient" mechanism), without changing
a jot in the material definition.
> I haven't yet seen an indication in the docs that suggests
> otherwise(?)
The tutorial talks a bit about the differences ("Using Ambient" and
"Using Emission").
Also, the reference section on ambient talks a lot about "Ambient
Lighting in shadowed areas", whereas the reference section on emission
talks about "glowing materials". In the case of your floor it is pretty
clear which one is more applicable.
> Is there a visual difference? Or does it have to do with making sure that
> POV-Ray's internal computations are performed correctly?
It has to do with not co-opting a mechanism that was designed to avoid
having to co-opting the very same mechanism you should actually be using.
It has to do with making sure your materials will work equally well in
both radiosity and non-radiosity scenes. If you use the "ambient"
mechanism to model the brightening of shadows from ambient light, your
material has a fair chance of continuing to work properly if you ever
turn on radiosity. If you use the "emission" mechanism instead, your
material is /guaranteed/ to screw it all up.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> >> No. No. Absolutely no. Unless you /specifically/ want to model something
> >> that glows in the dark, do NOT EVER use "emission".
> >>
> >> If you want to brighten up shadows, use radiosity or "ambient".
[Kenneth]:
> > That's interesting; I thought ambient and emission were identical in their
> > effect (in a non-radiosity scene, that is.) Basically that they are
> > interchangable.
[Clipka}:
> And that's /exactly/ the reason: From their effect in /non-radiosity/
> scenes they are interchangable, but from both their /intention/ and
> their effect in /radiosity/ scenes the two are worlds apart.
>
> Using "emission" to model indirect illumination of shadowy areas so
> /utterly/ defies the purpose of the feature that I /must/ rant about it,
> as a matter of principle. Kind of like if you'd use "assumed_gamma 500"
> or something like that.
You're certainly allowed to rant now and then ;-) Your general patience in
answering questions is one of the best qualities of the newsgroups.
Hmm, I haven't yet tried assumed_gamma 500; sounds interesting... :-P
> Next in the triad came radiosity, which serves /exactly/ the same
> purpose, albeit with much higher quality. So theoretically, the
> "ambient" mechanism and radiosity shouldn't be used together.
Yep, that's clear.
> However, people figured out that radiosity still picked up the light
> from the "ambient" mechanism...
[snip]
Ah, I get it now. In a nutshell, and speaking simplistically, it's from the
desire to not have to change a lot of code in an already-coded scene, when
switching from non-radiosity to using it. For a scene that is not intended for
radiosity effects-- and I write a fair number of such scenes -- ambient IS the
logical way to go. But in case I change my mind later, I sometimes write
my object finishes{...} like this:
ambient .1
emission 0
diffuse *something* (but not 1.0, of course)
(or as a #default finish)
..... in case I want to run radiosity later--- which might then require me to
change a few emission values, *if* I decide to make any of those objects 'glow'
with radiosity light. Like a LDR sky sphere/image, for example. (Which
admittedly doesn't concern an object's 'ambient shadow' lighting, which is the
crux of the argument here.) But when rendering that sky sphere in my (original)
NON-radiosity version of the scene, I should choose ambient 1.0 for it at first
(according to the argument), assuming that I want to actually see its nicely-lit
image in the render. That will produce a non-fatal warning message of course--
"ambient is too high." But I ignore that, naturally.
Here's the rub, though: If, when originally writing the scene, I imagine that I
*might* eventually include radiosity, the finish for my sky sphere would be
easier/more logical to write as...
ambient 0
emission 1.0
diffuse 0
.... since ambient and emission have the same effect without radiosity. In other
words, that set-up would appear to be satisfactory for *both* worlds. Yet it
definitely goes against the (all-inclusive?) argument of not using emission in a
non-radiosity environment.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.04.2018 um 09:40 schrieb Kenneth:
> Here's the rub, though: If, when originally writing the scene, I imagine that I
> *might* eventually include radiosity, the finish for my sky sphere would be
> easier/more logical to write as...
> ambient 0
> emission 1.0
> diffuse 0
> .... since ambient and emission have the same effect without radiosity. In other
> words, that set-up would appear to be satisfactory for *both* worlds. Yet it
> definitely goes against the (all-inclusive?) argument of not using emission in a
> non-radiosity environment.
Nobody ever said that.
Don't think in terms of "ambient is for non-radiosity scenes, emission
is for radiosity scenes". Disregard whether radiosity is on in your
scene, or whether you ever may want to turn it on. Instead, just
consider what /phsical effect/ you want to model.
The matter of radiosity vs non-radiosity is just the "background story"
of why you should use "ambient" for the one purpose and "emission" for
another.
"ambient" is for modeling the ambient light (i.e. light from the
surroundings) that brightens up the shadows on the object made of that
material. Any regular material should have a little bit of "ambient",
even if you're currently working on a radiosity scene - so that if you
or anyone else ever chooses to use the material in a non-radiosity
scene, the material looks ok out of the box. (Personally, I'm of the
opinion that the "ambient" term should be attached to objects rather
than materials, because it is primarily a geometric property; but that's
the bane of backward compatibility.)
"emission" is for modeling materials emitting light in and of
themselves. Sky spheres are a prime example of this; others might be a
glowing-hot ball bearing or a mage's magic crystal. In a radiosity scene
"emission" is the only mechanism that gives you this result, so you
/must/ use it there; but in non-radiosity scenes you /also/ want to use
"emission" for this purpose, because if you used "ambient" instead, (1)
I'd slap you on the wrist, and (2) you'd have to change the material if
you ever decided to turn on radiosity.
The warning message you get when you set your sky sphere to "ambient
1.0" is to tell you, "hey, you're probably doing something wrong here -
this material looks like you want it to emit light; if that is the case,
you shouldn't be using ambient but emission". It's essentially me
slapping you on the wrist.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 06/04/2018 à 13:20, Sven Littkowski a écrit :
> Waiting for the scene code, then i can hopefully show you a number of
> amazing undergrounds, and give you plenty inspirations. :-)
Look into p.b.scenes-files
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.04.2018 um 11:43 schrieb kurtz le pirate:
> Le 06/04/2018 à 13:20, Sven Littkowski a écrit :
>> Waiting for the scene code, then i can hopefully show you a number of
>> amazing undergrounds, and give you plenty inspirations. :-)
>
>
> Look into p.b.scenes-files
>
Thank you very much for sharing your code. So I can illustrate my
imagination. This one comes close to my original idea. The scene is
placed in the kitchen by Jamie Vives Piqueres using his HDR image
derived from his POV-Comp entry (can be found at his site
www.ignorancia.org). The relections at the top left are the stickers at
his fridge (most likely). Rendering time was 1 h 11 m at an old core i7.
Subsurface scattering is not implemented so far. Just to give you a
first hint of my idea.
Best regards
Michael
Post a reply to this message
Attachments:
Download 'kacheln04.png' (1105 KB)
Preview of image 'kacheln04.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yum.
Looks crispy.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.04.2018 um 21:37 schrieb clipka:
> Yum.
> Looks crispy.
>
Many thanks, hope it is a little bit more crispy now...
Here my final image with SSS at the tiles implemented. It was a lot of
guess work since I did not really understand the central parameter of
translucency. The docs are a little bit silent about this parameter and
the sample source gives very high values. So I had to play a little bit.
But learning is no waiste of time;)
First I observed strange artefacts at the white tiles around the black
ones: Irregular thin black lines. Since they turned blue as I made a
test with a blue colored version of the round tiles, I played around
with the reflection parameters, but without any success. Then I came up
with the strange idea to use UberPov instead of POV 3.7: the artefacts
(and some radiosity artefacts under the "`cookie"' as well - can be seen
at my first post here) disappeared completely.
The remaining issue were the black tiles. I observed strange artefacts
at the surface and no specular reflection. I played around with the
parameters but got the best result by using a very dark grey finally
(White*0.0001). The SSS feature seems to call for some - even very small
- amount of colour and seems to run into problems by specifying no
colour (black) as the pigment.
Rendering time extended to 2 h 51 m 39 s at the same machine.
I have no other ideas what can be done with the floor so far.
Best regards
Michael
Post a reply to this message
Attachments:
Download 'kacheln05.png' (2485 KB)
Preview of image 'kacheln05.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18-04-17 à 17:48, MichaelJF a écrit :
> Am 14.04.2018 um 21:37 schrieb clipka:
>> Yum.
>> Looks crispy.
>>
> Many thanks, hope it is a little bit more crispy now...
>
> Here my final image with SSS at the tiles implemented. It was a lot of
> guess work since I did not really understand the central parameter of
> translucency. The docs are a little bit silent about this parameter and
> the sample source gives very high values. So I had to play a little bit.
> But learning is no waiste of time;)
>
> First I observed strange artefacts at the white tiles around the black
> ones: Irregular thin black lines. Since they turned blue as I made a
> test with a blue colored version of the round tiles, I played around
> with the reflection parameters, but without any success. Then I came up
> with the strange idea to use UberPov instead of POV 3.7: the artefacts
> (and some radiosity artefacts under the "`cookie"' as well - can be seen
> at my first post here) disappeared completely.
>
> The remaining issue were the black tiles. I observed strange artefacts
> at the surface and no specular reflection. I played around with the
> parameters but got the best result by using a very dark grey finally
> (White*0.0001). The SSS feature seems to call for some - even very small
> - amount of colour and seems to run into problems by specifying no
> colour (black) as the pigment.
>
> Rendering time extended to 2 h 51 m 39 s at the same machine.
>
> I have no other ideas what can be done with the floor so far.
>
> Best regards
> Michael
>
You are right, translucency break when you have zero value components in
the colour. Don't use rgb <1,0,0> for your red, but something like
rgb<1, e-5, e-5>
The sample use large values to model wax and some highly translucent
stone, and also, so that the effect is more visible.
The translucency represent the average distance that light will travel
into the object before comming back out and is a representation of the
average light travel distance between interaction.
As the translucency value get similar, then larger than, to the
thickness of the object, you start to see through that object.
Is your grout made out of a plane ? If yes, then you can slightly see it
under the surface of the tiles. It can be seen as artefacts. Try carving
out the body of the tiles into that plane, or model only hte part of the
grout that lies between the tiles using many box and cylinders in an union.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
New try ... in the sand.
Isosurface only.
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
Attachments:
Download 'f_helical_torus_ground_sand.jpg' (304 KB)
Preview of image 'f_helical_torus_ground_sand.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.04.2018 um 18:47 schrieb kurtz le pirate:
> New try ... in the sand.
>
> Isosurface only.
>
>
>
I have not expected such a radical change in texturing. But this one is
beautiful.
Best regards
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
