 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge schrieb:
>> Is it true That if I directly include the macro inside my scene
>> instead of
>> including and calling for it wherever it is, it will render faster...?
>
> What version are you using? It used to be true. This problem seems to
> have been fixed in the newer 3.7 beta releases.
It is generally the case that macros defined in an external file parse
slower than macros copied to the file in which they are invoked.
Or, to be more precise, the /invocation/ of a macro defined in a
different file adds some constant overhead per invocation.
If you invoke just a single big externally-defined macro once, not much
time is lost.
If you invoke a small externally-defined macro hundred thousands of
times for some reason, it really bogs down parsing, even in 3.7. Maybe
the overhead has been reduced, but it's still there.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Is it true That if I directly include the macro inside my scene instead of
> including and calling for it wherever it is, it will render faster...?
>
>
>
It depends.
If you use a big macro only one or two times, the overhead is negligible.
Keep in in it's include file.
If you use a small macro many thousands of times, then the overhead of
accessing the include will get huge.
Copy the macro into the file where it's used.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> stbenge schrieb:
>>> Is it true That if I directly include the macro inside my scene
>>> instead of
>>> including and calling for it wherever it is, it will render faster...?
>>
>> What version are you using? It used to be true. This problem seems to
>> have been fixed in the newer 3.7 beta releases.
>
> It is generally the case that macros defined in an external file parse
> slower than macros copied to the file in which they are invoked.
>
> Or, to be more precise, the /invocation/ of a macro defined in a
> different file adds some constant overhead per invocation.
>
> If you invoke just a single big externally-defined macro once, not much
> time is lost.
> If you invoke a small externally-defined macro hundred thousands of
> times for some reason, it really bogs down parsing, even in 3.7. Maybe
> the overhead has been reduced, but it's still there.
Ah, that's good to know, thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge <not### [at] hotmail com> wrote:
> stbenge wrote:
> > Mr wrote:
> >> I am trying to use Fast SSS 2 from Stbenge macro but can't manage to
> >> get an
> >> ordinary finish with it. any specularity seems to cover up the effect.
>
> Here's a simpler version:
>
> object{obj
> texture{
> pigment{
>
> fastSSS2(obj,lpos*100000,min_extent(obj)-0.5,max_extent(obj)+0.5,<1,1,1>*8,3,20)
> colour_map{[0 rgb 0][1 rgb<1,.25,.5>]}
> }
> finish{phong 1 phong_size 200 reflection{.002,1 falloff 2} ambient .5
> diffuse 0}
> }
> }
>
> I hope that indentation turns out all right.
>
> Sam
Do I need the pigment_pattern?
I would like to layer this over something else but it generates an error.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <nomail@nomail> wrote:
> Do I need the pigment_pattern?
> I would like to layer this over something else but it generates an error.
Clipka explained to me that pigment patterns should'nt be a problem. Thanks
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here is what I have so far with the skin shader I'm trying to do... not much :(
maurice.raybaud.eu/images/stories/FastSSSradFlicker.avi
I used FastSSS2 macro to get render times below 6 minutes per frame (I was
aiming for below 3 But it's still faster than true SSS.
The problem is I had to use radiosity So now I wonder if the flickering I get on
the backlit side is because of fastprox or because of radiosity.
Here are my settings,
- for FastSSS:
#declare thisSSS=
pigment{pigment_pattern{fastSSS2(OBSuz,lpos,min_extent(OBSuz)-0.5,max_extent(OBSuz)+0.5,<1,1,1>*24,2,11)
cubic_wave}}
texture{
pigment_pattern{thisSSS}
texture_map{
[0
pigment{rgb <0.73, 0.25, 0.145>}
finish{
diffuse 0.8, 0.7
ambient 0
//phong 0.35
//phong_size 1
brilliance 4
specular 0.1
}
]
[1
pigment{rgb<0.83, 0.45, 0.225>}
finish{
diffuse 0.8, 0.5
ambient 0.2
//phong 0.35
//phong_size 1
brilliance 4
specular 0.2
}
]
}
}
- And the parameters for radiosity:
pretrace_start 0.08
pretrace_end 0.08
count 22
nearest_count 8
error_bound 2
recursion_limit 1
low_error_factor 0.3
gray_threshold 0
minimum_reuse 0.05
brightness 1.0
adc_bailout 0.01/2
always_sample off
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mr schrieb:
> Here is what I have so far with the skin shader I'm trying to do... not much :(
>
> maurice.raybaud.eu/images/stories/FastSSSradFlicker.avi
>
> I used FastSSS2 macro to get render times below 6 minutes per frame (I was
> aiming for below 3 But it's still faster than true SSS.
> The problem is I had to use radiosity So now I wonder if the flickering I get on
> the backlit side is because of fastprox or because of radiosity.
Unless you make use of POV-Ray's mechanisms for storing and re-loading
of radiosity samples, some deal of flicker is virtually inevitable with
radiosity - the lower-quality the settings, the worse.
(Of course it doesn't help that if your scene contains any moving
objects, you'd theoretically need to recompute radiosity for every frame
anyway.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> Unless you make use of POV-Ray's mechanisms for storing and re-loading
> of radiosity samples, some deal of flicker is virtually inevitable with
> radiosity - the lower-quality the settings, the worse.
You mean more than other renderers?
>
> (Of course it doesn't help that if your scene contains any moving
> objects, you'd theoretically need to recompute radiosity for every frame
> anyway.)
Of course I want to be able to animate the character in the long run, so I have
planned to do it with no baking, that's why my radiosity settings are so low.
I have to increase them. But I really would have liked to stay under 6 minutes
per frame. Is Povray radiosity never used for animation? It's the main reason
why I first came to Pov instead of Blender Internal
You seem to imply that you recognize this flicker as Pov radiosity's fault, if
so and if you're right, I can try to lower fast proxsampling and increase
Radiosity's to keep reasonable times and reduce flicker.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr"
> You seem to imply that you recognize this flicker as Pov radiosity's fault, if
> so and if you're right, I can try to lower fast proxsampling and increase
> Radiosity's to keep reasonable times and reduce flicker.
Great! I switched to BSP for a try and the scene went down from 6 min 26 sec, to
4 min 18 sec! Now I have the room to improve radiosity: 2 spare minutes per
frame should allow for quite some polishing. don't you think that the flicker
could totally disappear? I mean not from a theoretical point of view, but as a
user, comparing to other renderers: they can get invisible when settings are
high enough
Or maybe POV can't be used for animation as much as these renderers because of
some real limitation it has that they don't?
I'll ask some more about BSP in another thread, it seems to be worth it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mr schrieb:
> don't you think that the flicker
> could totally disappear? I mean not from a theoretical point of view, but as a
> user, comparing to other renderers: they can get invisible when settings are
> high enough
Honestly, a theoretical point of view is the only one I can offer here;
I'm not doing animations myself, so I have no experience how well
POV-Ray radiosity behaves in animations in practice, let alone in
comparison with other renderers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
