 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MichaelJF <mi-### [at] t-online de> wrote:
> Am 29.08.2015 um 19:09 schrieb And:
> > MichaelJF <mi-### [at] t-onlinede> wrote:
> > I think what I posted a moment ago is the key point. It is not the render
> > settings or the lighting problem.
> >
> >
> I fear you mixed up the rendering times for your second and your third
> example, but indeed such things can prolong rendering times and increase
> the hunger for memory dramatically, especially when made wet. I
> encountered this issue some months ago while playing with the blockwall
> macros. If you have an blocking object there, every piece of stone of a
> wall is in a difference {} with this blocking object. With complex
> buildings one can run out of memory very soon. But as I understood this
> blockwall stuff so far, it is necessary there for the spline follow macro.
>
> I suspect too, that Anthony's problem is not with the water, but may be
> multiplied by this. But we don't know if this problem is present in
> Anthony's scene finally.
>
> Best regards,
> Michael
Em...
I'm sorry. I just felt that his problem should be the difference/intersection
problem then I said that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30-8-2015 7:45, And wrote:
> MichaelJF <mi-### [at] t-onlinede> wrote:
>> Am 29.08.2015 um 19:09 schrieb And:
>>> MichaelJF <mi-### [at] t-onlinede> wrote:
>>> I think what I posted a moment ago is the key point. It is not the render
>>> settings or the lighting problem.
>>>
>>>
>> I fear you mixed up the rendering times for your second and your third
>> example, but indeed such things can prolong rendering times and increase
>> the hunger for memory dramatically, especially when made wet. I
>> encountered this issue some months ago while playing with the blockwall
>> macros. If you have an blocking object there, every piece of stone of a
>> wall is in a difference {} with this blocking object. With complex
>> buildings one can run out of memory very soon. But as I understood this
>> blockwall stuff so far, it is necessary there for the spline follow macro.
>>
>> I suspect too, that Anthony's problem is not with the water, but may be
>> multiplied by this. But we don't know if this problem is present in
>> Anthony's scene finally.
>>
>> Best regards,
>> Michael
>
> Em...
> I'm sorry. I just felt that his problem should be the difference/intersection
> problem then I said that.
>
>
Which reminds me of: http://www.econym.demon.co.uk/holetut/index.htm
Another thing which can be asked Anthony: is the water object
overlapping with any other media (atmosphere or lighting)? I found in my
Not Islay scene that that slows down render speed dramatically when that
area is reached by the render. My solution was to cut the atmosphere
container just above the water surface.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> On 30-8-2015 7:45, And wrote:
> >
> > Em...
> > I'm sorry. I just felt that his problem should be the difference/intersection
> > problem then I said that.
> >
> >
>
> Which reminds me of: http://www.econym.demon.co.uk/holetut/index.htm
>
> Another thing which can be asked Anthony: is the water object
> overlapping with any other media (atmosphere or lighting)? I found in my
> Not Islay scene that that slows down render speed dramatically when that
> area is reached by the render. My solution was to cut the atmosphere
> container just above the water surface.
>
> --
> Thomas
Hi, I remember this, too. When I encountered the problem, I just thought of this
article which I read several years ago.
great!
--
Cheng Han Tsai
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi, I rendered some pictures to interpretation my method. You can just use the
'reflection' keyword to render the highlight.
The first one is a scene that contains a point light_source, a (looks_like)
white emission sphere but no_radiosity and no_shadow. A ground, and some
reflection spheres.
You can see the effect.
//----------------start of scene-----------------
#version 3.7
global_settings{
assumed_gamma 1
max_trace_level 8
}
//------------------light source--------------
#declare light_pos = <0, 0.12, -0.5>;
#declare light_color = rgb <0.5,1,1>;
light_source{
light_pos
color light_color
fade_distance 1
fade_power 2
}
#declare light_r = 0.12;
#declare emission_area = 4*pi*light_r*light_r;
sphere{
light_pos, light_r
no_shadow
no_radiosity
pigment{light_color}
finish{ambient 0 emission 1 diffuse 0}
}
//-----------------camera--------------------
camera {
location<3,2,0>
look_at<0,0,0>
}
//-----------------object--------------------
plane{
<0,1,0>,0
texture{
checker
texture{pigment{rgb <0.7,0.65,0.1>} finish{ambient 0 diffuse 1
brilliance 1.5 reflection{0.02,0.52 falloff 3}}},
texture{pigment{rgb <0.7,0.65,0.1>} finish{ambient 0 diffuse 1}}
scale <0.6,1,1.5>
rotate <0,45,0>
}
}
#declare sphere1=
sphere{
<0,0.14,0.3>, 0.14
texture{
pigment{rgb<0.19,0.18,0.19>}
finish{ambient 0 diffuse 1 brilliance 1.5 reflection {0.01,0.2 falloff
3}}
}
}
#declare GOLDEN_RATIO = (1+sqrt(5))/2;
#declare sitting_r = 4;
#declare sitting_center = <0,0,0>;
#declare sphere_amount = 250;
#for(i, 20, 49)
#local this_r = sqrt(1/2+i)/sqrt(sphere_amount);
#local this_theta = i*2*pi*(1-1/GOLDEN_RATIO);
#local this_point = <this_r*cos(this_theta), 0,
this_r*sin(this_theta)>*sitting_r;
object{
sphere1
translate sitting_center + this_point
}
#end
//----------------end of scene---------------
Post a reply to this message
Attachments:
Download 'finish test2 1.png' (132 KB)
Preview of image 'finish test2 1.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
But the main problem is, there are no highlights on my reflection spheres.
Uh..., no, in fact there are, but you cannot see, because the highlight is too
weak. ?
I use a color for the point light source, and assign the same color for the
looks-like emission sphere. It works not good. So, I try to adjust the
brightness of the emission sphere. Let us multiply 10.
sphere{
light_pos, light_r
no_shadow
no_radiosity
pigment{light_color*10} //10 times
finish{ambient 0 emission 1 diffuse 0}
}
Post a reply to this message
Attachments:
Download 'finish test2 3.png' (133 KB)
Preview of image 'finish test2 3.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Now you can see the difference between them. That is the highlight. Ok, so the
common mistake we often make is setting a too dim brightness on the emission
look-like sphere.
When using the 'reflection' keyword to produce a high light, here I can tell you
a formula of the relation between the looks-like sphere and the light_source it
represent.
(For the photorealism)
It is:
(color of the emission sphere) = (color of the light_source) * 4* pi / (the area
of the emission sphere)
When we apply this formula, we can calculate the correct brightness relation
between them.
It will get a realism result.
I apply it to my example, I calculate the color of my emission sphere is in fact
69.4444 times the color of the light source.
sphere{
light_pos, light_r
no_shadow
no_radiosity
pigment{light_color*69.4444}
finish{ambient 0 emission 1 diffuse 0}
}
Post a reply to this message
Attachments:
Download 'finish test2 4.png' (134 KB)
Preview of image 'finish test2 4.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And here is a picture it works with radiosity feature on:
Post a reply to this message
Attachments:
Download 'finish test2 5.png' (165 KB)
Preview of image 'finish test2 5.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/30/2015 12:39 AM, clipka wrote:
> Why fix a perfectly good and fast-rendering scene? It's the other
> variant that takes ages to render.
>
> Besides, the intersection code /already/ makes sure that the bounding
> box isn't larger than what you suggest to specify manually; the boundin
g
> box for the intersection of a given set of objects defaults to the
> intersection of their bounding boxes.
>
Erm, no it isn't. The bounding box of the intersection *should* be
the intersection of the bounding boxes, but experience shows that it
isn't (and hasn't been for more than 15 years). Actually I'm not sure
whether the issue is that the bounding box is wrong or that
intersections disable automatic bounding altogether, but I do know that
manual bounding fixes the problem.
Note that the other even slower scene could probably be fixed by
proper manual bounding too, it's just more difficult to do...
Jerome
--
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
Post a reply to this message
Attachments:
Download 'us-ascii' (1 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 15-08-29 17:15, Jérôme M. Berger a écrit :
> On 08/29/2015 06:35 PM, And wrote:
>> And the third is the 100x100 tilings, takes 2 minutes and 4 seconds to render.
>> Every object in it is intersection with the bounding cylinder first, then union.
>>
>>
>> #declare one_piece =
>> union{
>> box{
>> <0.005, 0.005, 0>, <0.395, 0.395, 0.01>
>> }
>> cylinder{
>> <0.02, 0, 0>, <0.38, 0, 0>, 1
>> scale <1,0.18,0.02>
>> translate <0, 0.2, 0.01>
>> }
>> pigment{
>> rgb<0.4,0.6,0.6>
>> }
>> }
>>
>> #declare the_tiling =
>> union{
>> #for(i, 0, 99)
>> #for(j, 0, 99)
>> intersection{
>> object{
>> one_piece
>> translate <i*0.4, j*0.4, 0>
>> }
>> cylinder{
>> <20,20,0>,<20,20,1>,19
>> }
> Try to add these lines here:
> bounded_by { box { min_extent (one_piece)+<i*0.4, j*0.4, 0>,
> max_extent (one_piece)+<i*0.4, j*0.4, 0> } }
>> cutaway_textures
>> }
>> #end
>> #end
>> }
>>
>>
>> the_tiling
>>
>
>
Ouch!
When you add a manual bounding to an union, that union is no longer
splitted. That cause it to take MUCH more time to render as each ray
that hit the manual bounding box now need to be tested against each and
every components of the union. It's similar in effect to uselessly using
merge instead of union.
Also, as your manual bounding box is larger than the original union,
it's even slower.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/30/2015 07:38 PM, Alain wrote:
> Ouch!
> When you add a manual bounding to an union, that union is no longer
> splitted. That cause it to take MUCH more time to render as each ray
> that hit the manual bounding box now need to be tested against each and
> every components of the union. It's similar in effect to uselessly usin
g
> merge instead of union.
>
> Also, as your manual bounding box is larger than the original union,
> it's even slower.
>
Have you tried it? ;) According to And, adding the manual bounding
box decreases the render time from 2m04s to 2s...
Jerome
--
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
Post a reply to this message
Attachments:
Download 'us-ascii' (1 KB)
|
|
| |
| |
|
|
|
|
| |
|
|
