 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
>
> using those radiosity settings, my 3.01 Ghz Phenom II X6 machine sits on its
> thumbs and shows a black window.
>
> Even when I turn off the light source fading, the focal blur and the
> anti-aliasing. With those radiosity settings my computer just sits there.
>
> I have no idea what's going on with this scene, but even when I remove the point
> lights and replace them with emissive objects (simple spheres no ambient or
> diffuse just emission 60 and no_image) the IndoorHQ settings from rad_def.inc
> cause my scene to bog down at 0%. It doesn't even get to the water.
>
> here is the actual water material I'm using:
>
> #declare M_Watx4 =
> material {
> texture {
> pigment { color rgbft <0.235, 0.318, 0.618, 1.0, 0.96> }
> finish {
> diffuse 0
> ambient 0
> // reflection {0.1, 0.9 fresnel on exponent 0.8}
> reflection { 1.0 fresnel on }
> conserve_energy
> specular albedo 1
> roughness 0.007
> }
> normal {
> function {f_ridged_mf(x,y,z, 0.1, 3.0, 7.0, 0.7, 0.7, 2)} 0.3
> scale <1.0, 0.09375, 1.0>
> // scale <4.68, 3.2, 4.68>/12
> }
> }
> interior {
> ior 1.31
> fade_distance 10
> fade_power 1001
> fade_color <0.235, 0.318, 0.618>
> }
> }
>
> my command line: +AM2 +a0.03 +H945 +W1680 +BM2 -RVP +WT6 +P serraglio.pov
>
> I get some slowdown from the floor because the tiles are all geometry (prisms),
> and I expect that effects the water some, but I don't think it explains
> everything.
>
> my lights are point lights with fade_distance 7 and fade_power 2
>
> other than that, my radiosity settings are dumbed down from the tutorial for
> conventional lighting in the docs.
>
> radiosity {
> pretrace_start 0.04
> pretrace_end 0.005
> count 35
>
> nearest_count 10
> error_bound 0.5
> recursion_limit 2
>
> low_error_factor 0.1
> gray_threshold 0.2
> minimum_reuse 0.015
> maximum_reuse 0.2
> brightness 1.0
> normal off
>
> adc_bailout 1/256
> }
>
> Regards,
> A.D.B.
>
I'm running out of ideas too. I played aroud with your settings here and
my very simple test scene but found no solution for the riddle.
Meanwhile I think that there must be an other problem and the water
material is the wrong track. But I have no idea what it could be. I
first exchanged my water material by yours given here. The computing
time decreased (!) to 6m 41s. Then I added your fade_distance and
fade_power to my dimmed light_sources: 6m 41s. But you may have another
scaling (for me 1 unit=1 meter). Then I worked through your command line
options. Your higher anti alias settings yielded 8m 21s. Adding +bm2:
9m 58s. -rvp saved 32s. +p should not have any effect on the computation
time but indicates that you are not running the Windoze version like me.
All computations mentioned above done with this insane IndoorHQ settings.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello, Anthony D Baye. I would draw some pictures to show the technique which I
said: using reflection to make highlight of the water. But before doing this, I
just saw that you use prisms to simulate the floor. I just know this, and Um...,
it contains a problem, maybe you have known it. When we 'difference' or
'intersection' a union of a large number of objects with any other object, it
will extremly slow down the rendering. It is just very slow. So a union contains
a large number of objects actually shouldn't do 'difference' or 'intersection'
anymore.
I show a example:
A 100x100 tilings. It took only 1 second to render.
#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)
object{
one_piece
translate <i*0.4, j*0.4, 0>
}
#end
#end
}
the_tiling
Post a reply to this message
Attachments:
Download 'array_test1 1 1s.png' (177 KB)
Preview of image 'array_test1 1 1s.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The second is the same 100x100 tilings, but intersection a cylinder for the
bounding. It takes 35minutes and 20 seconds to render.(2000 times ,Is it
terrable?)
#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)
object{
one_piece
translate <i*0.4, j*0.4, 0>
}
#end
#end
}
intersection
object{
the_tiling
}
cylinder{
<20,20,0>,<20,20,1>,19
}
cutaway_textures
}
Post a reply to this message
Attachments:
Download 'array_test1 2 35m20s.png' (131 KB)
Preview of image 'array_test1 2 35m20s.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
}
cutaway_textures
}
#end
#end
}
the_tiling
Post a reply to this message
Attachments:
Download 'array_test1 3 2m4s.png' (131 KB)
Preview of image 'array_test1 3 2m4s.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MichaelJF <mi-### [at] t-online de> wrote:
> >
> >
>
> I'm running out of ideas too. I played aroud with your settings here and
> my very simple test scene but found no solution for the riddle.
> Meanwhile I think that there must be an other problem and the water
> material is the wrong track. But I have no idea what it could be. I
> first exchanged my water material by yours given here. The computing
> time decreased (!) to 6m 41s. Then I added your fade_distance and
> fade_power to my dimmed light_sources: 6m 41s. But you may have another
> scaling (for me 1 unit=1 meter). Then I worked through your command line
> options. Your higher anti alias settings yielded 8m 21s. Adding +bm2:
> 9m 58s. -rvp saved 32s. +p should not have any effect on the computation
> time but indicates that you are not running the Windoze version like me.
>
> All computations mentioned above done with this insane IndoorHQ settings.
I think what I posted a moment ago is the key point. It is not the render
settings or the lighting problem.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.08.2015 um 01:53 schrieb Anthony D. Baye:
> I have tried all of these things. The media gives good results as long as I
> don't care if it's pure white... The problem of course is that the parts that
> affect the radiosity will be well beyond the white-point and any attempt to add
> color reduces their brightness to such a degree that they no longer have the
> desired effect.
- Increase the size of the light-emitting objects.
- Make the media fall off gradually, so that although it may turn out
white at the center, you'll still see some colour at its fringes.
- Render to a high dynamic range format (OpenEXR is recommended) and use
post-processing to tune down lights until you get a hint of colours.
- Enjoy the beauty of an image where part of the scene is so dark that
it almost - but not quite - gets lost in the shadows.
- Make sure your display is reasonably well calibrated, especially with
respect to black point and gamma.
- Make sure you are using proper gamma handling (assumed_gamma 1.0,
Display_Gamma .ini setting matching your display system).
- Cheat, using an assumed_gamma setting even lower than 1.0.
- Cheat, using a radiosity brightness setting higher than 1.0.
- Cheat, using two copies of each light emitting object: A bright one
with no_image, and a darker one with no_radiosity. (One of them should
also have no_reflection.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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, th
en 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
>
--
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
Post a reply to this message
Attachments:
Download 'us-ascii' (1 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.08.2015 um 19:09 schrieb And:
> MichaelJF <mi-### [at] t-onlinede> wrote:
>>>
>>>
>>
>> I'm running out of ideas too. I played aroud with your settings here and
>> my very simple test scene but found no solution for the riddle.
>> Meanwhile I think that there must be an other problem and the water
>> material is the wrong track. But I have no idea what it could be. I
>> first exchanged my water material by yours given here. The computing
>> time decreased (!) to 6m 41s. Then I added your fade_distance and
>> fade_power to my dimmed light_sources: 6m 41s. But you may have another
>> scaling (for me 1 unit=1 meter). Then I worked through your command line
>> options. Your higher anti alias settings yielded 8m 21s. Adding +bm2:
>> 9m 58s. -rvp saved 32s. +p should not have any effect on the computation
>> time but indicates that you are not running the Windoze version like me.
>>
>> All computations mentioned above done with this insane IndoorHQ settings.
>
> 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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.08.2015 um 23:15 schrieb Jérôme M. Berger:
>> #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
>> }
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 bounding
box for the intersection of a given set of objects defaults to the
intersection of their bounding boxes.
Render performance goes down the drain when you have a large shape
defined as an intersection which either (A) is comprised of many large
and/or infinite shapes with a lot of overlap, or (B) contains at least
one large union of many small shapes with very little overlap all
crammed together without much of a hierarchy.
The reason is that while union CSGs only require ray-object intersection
tests with the individual member primitives, which is done quickly using
the scene's global bounding hierarchy, intersection CSGs also start out
by finding a ray-object intersection with any of its members via global
bounding, but then need to do an /inside test/ to check whether the
ray-object intersection point just found is actually inside /all/ of the
intersection's other members (and if that member happens to be a union,
that in turns means checking whether the intersection point is in /any/
of that union's members).
Another problematic case is (C) the difference of one large shape and a
lot of small shapes (such as holes cut out of a large part); as a matter
of fact, this is a special case of (A) in disguise, because internally a
difference is represented as an intersection of the first object and the
inverse of the other objects; and the inverse of a finite shape is an
infinite shape.
In case of (B), a bounding hierarchy could help speed up the inside
testing, and in case of (C) that would also help provided we'd bound the
"hole" in the infinite objects; however, currently no such local
bounding hierarchy is implemented in CSG objects.
It should, however, be possible to manually construct such a bounding
hierarchy: In case (B), you could bundle nearby union members into a
sub-union; in case (C), instead of a difference of the primary object
and many individual cutouts you could use a difference of the primary
object and a single union of cutouts, which again you could group
hierarchically into sub-unions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 29.08.2015 um 23:15 schrieb Jérôme M. Berger:
>
> >> #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
> >> }
>
> 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 bounding
> box for the intersection of a given set of objects defaults to the
> intersection of their bounding boxes.
>
Em...Clipka, I trust your profession on the POV-Ray's internal detail. But, for
this problem, why I add Jérôme M. Berger's adding code, its rendering time
decreases to 2 seconds?
I knew that POV-Ray makes a global bounding hierarchy for the first(global)
level .... But from the rendering time what I tried just now it seems that
POV-Ray didn't make boundings for my objects.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
