 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
An attempt for a flame, using a blob container. Some dots appear on the surface:
known bug?
Also: In the doc at "3.4.7.5 Area Lights" it is explained that, with 'circular',
area_lights can be elliptical if x and y axis are not equal. It seems that if I
make so, the thickness of the soft shadows are of the same thickness in all
directions. In this test scene I tried y=5*x, but the soft shadow of the sphere
on the left is even all around. Is this the effect of 'orient'? What did I miss?
Post a reply to this message
Attachments:
Download 'flame2.png' (64 KB)
Preview of image 'flame2.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 26.02.2011 03:24, schrieb Bruno Cabasson:
> An attempt for a flame, using a blob container. Some dots appear on the surface:
> known bug?
That would depend on what you actually did there :-)
> Also: In the doc at "3.4.7.5 Area Lights" it is explained that, with 'circular',
> area_lights can be elliptical if x and y axis are not equal. It seems that if I
> make so, the thickness of the soft shadows are of the same thickness in all
> directions. In this test scene I tried y=5*x, but the soft shadow of the sphere
> on the left is even all around. Is this the effect of 'orient'? What did I miss?
I think the docs don't mention it, but in case "orient" is used, the
area light's Y axis is effectively ignored.
The reason is probably because when you use "orient", it is no longer
clearly defined in which directions the area light's axes point - only
that the axes are re-oriented to be perpendicular to the direction of
the light; so the result might get messy. And even if "orient" would be
specified to try keep the Y axis "as vertically as possible" (like
point_at does with the camera), it still wouldn't give you what you'd
want for shadows above or below the light source.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Am 26.02.2011 03:24, schrieb Bruno Cabasson:
> > An attempt for a flame, using a blob container. Some dots appear on the surface:
> > known bug?
>
> That would depend on what you actually did there :-)
See code below (other version with only the area_light inside the flame, but
artifact still there)
>
> > Also: In the doc at "3.4.7.5 Area Lights" it is explained that, with 'circular',
> > area_lights can be elliptical if x and y axis are not equal. It seems that if I
> > make so, the thickness of the soft shadows are of the same thickness in all
> > directions. In this test scene I tried y=5*x, but the soft shadow of the sphere
> > on the left is even all around. Is this the effect of 'orient'? What did I miss?
>
> I think the docs don't mention it, but in case "orient" is used, the
> area light's Y axis is effectively ignored.
>
> The reason is probably because when you use "orient", it is no longer
> clearly defined in which directions the area light's axes point - only
> that the axes are re-oriented to be perpendicular to the direction of
> the light; so the result might get messy. And even if "orient" would be
> specified to try keep the Y axis "as vertically as possible" (like
> point_at does with the camera), it still wouldn't give you what you'd
> want for shadows above or below the light source.
Would it be possible to specify a rotation axis with some keyword like 'up' or
'axis' or whatever?
Bruno
#include "colors.inc"
#include "strings.inc"
global_settings
{
assumed_gamma 1
ambient_light 0
}
#declare LIGHT_COLOR = (2*Yellow+2*Goldenrod+Blue)/5;
#declare FLAME_COLOR1 = (2*Yellow+2*Goldenrod)/4;
#declare FLAME_COLOR2 = (2*Red+Yellow+2*Goldenrod)/5;
camera
{
location -10*z
angle 40
right x*image_width/image_height
}
light_source {
0 color LIGHT_COLOR*4
area_light x/5, y, 11, 11 adaptive 1 circular orient area_illumination
fade_distance 2 fade_power 2
}
sphere
{
0, 1
hollow
pigment {brick scale 0.5*x scale 1/150 warp {spherical}}
scale 15
}
#declare Sp_Flame = spline
{
cubic_spline
-0.1, <0, -0.5, 0, 0.9>
0.00, <0, 0, 0, 0.8>
0.30, <0.1, 1.5, 0, 0.7>
0.9, <0.1, 5.5, 0, 0.3>
1.00, <0.1, 6, 0, 0.15>
1.1, <0.05, 6.5, 0, 0>
}
#declare Sh_Flame = blob
{
#local i=0;
#local N = 101;
#while (i<N)
#local _v = Sp_Flame(i/(N-1));
#local _p = <_v.x, _v.y, _v.z>;
#local _r = _v.t;
sphere {_p, _r, 1}
#local i=i+1;
#end
threshold 0.6
scale 1/6
}
#declare M_EMedia = media
{
samples 20
emission 15
density
{
gradient y scale 1.2 translate -0.15*y
scale 5 warp {turbulence 0.4*y octaves 1} scale 1/5
translate -0.4*x
color_map
{
[0.10 rgb 0]
[0.15 Navy/2]
[0.25 FLAME_COLOR2*1.3]
[0.45 FLAME_COLOR1*1.6]
[0.90 FLAME_COLOR1]
[0.95 Orange]
}
}
}
#declare M_AMedia = media
{
samples 20
absorption 5
density
{
gradient y scale 1.2 translate -0.15*y
scale 5 warp {turbulence 0.4*y octaves 1} scale 1/5
translate -0.4*x
color_map
{
[0.10 rgb 0]
[0.15 rgb 1]
[0.25 rgb 3]
[0.45 rgb 2]
[0.90 rgb 1]
[0.95 rgb 0]
}
}
}
#declare Ob_Flame = object
{
Sh_Flame
pigment {rgbt 1}
hollow
interior
{
media {M_EMedia}
media {M_AMedia}
}
}
object {Ob_Flame scale 1.5 translate -y/2}
cylinder {0, 2*x, 0.05 pigment{Tan} translate -0.1*x-1.1*y/2}
sphere {0,1 pigment{White} scale 1/3 translate -x+y/3+3*z}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I just noticed that the artifact disappears if I remove the dome.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Would it be possible to specify a rotation axis with some keyword like 'up' or
> 'axis' or whatever?
>
> Bruno
>
I'm also thinking about some variation for orient. My take would be
orient axis. Here, the area_light would be rotated ONLY around a
provided axis, making it cylindrical instead of spherical.
Ex.: orient x
Another variation: the possibility to punch a hole in the center of the
array, keeping only the outer elements. With circular, it makes a crown
shaped light. Less usefull, but there are lights that have such a shape.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 26.02.2011 19:14, schrieb Alain:
> I'm also thinking about some variation for orient. My take would be
> orient axis. Here, the area_light would be rotated ONLY around a
> provided axis, making it cylindrical instead of spherical.
> Ex.: orient x
Thought about that, too. With exactly the same syntax, actually.
Re-orientation would then be limited to rotations about that axis, and
the "orientation direction" would be that which comes closest to the
direction towards the illuminated object.
> Another variation: the possibility to punch a hole in the center of the
> array, keeping only the outer elements. With circular, it makes a crown
> shaped light. Less usefull, but there are lights that have such a shape.
Maybe some "volume_light", taking a pattern or df3 file for the
brightness of sub-regions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Am 26.02.2011 19:14, schrieb Alain:
>> I'm also thinking about some variation for orient. My take would be
>> orient axis. Here, the area_light would be rotated ONLY around a
>> provided axis, making it cylindrical instead of spherical.
>> Ex.: orient x
>
> Thought about that, too. With exactly the same syntax, actually.
> Re-orientation would then be limited to rotations about that axis, and
> the "orientation direction" would be that which comes closest to the
> direction towards the illuminated object.
>
>> Another variation: the possibility to punch a hole in the center of the
>> array, keeping only the outer elements. With circular, it makes a crown
>> shaped light. Less usefull, but there are lights that have such a shape.
>
> Maybe some "volume_light", taking a pattern or df3 file for the
> brightness of sub-regions.
That would be nice. Some totaly customisable light sources. Obviously,
you probably can't optimize those as well as a regulat area_light.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
