stbenge <not### [at] hotmailcom> 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


Thanks a lot for your support. Before I dive straight into editing my shader in
PovWin, I also would like to ask if you think there may be a solution to this:

The exporter I'm using (Bend2pov) doesn't allow me to call
for the object that is declared automatically. I can append texture blocks to it
or anything inside the object block or even in the globals I can declare stuff.
But the real object, a blender model, (So there's no point in completely
writing it down as a mesh2 myself...) That object, said I, to which I want to
apply the macro can't be called inside any of these blocks as if it was written
after the call is parsed. I tried declaring a dummy object with the same name,
but it doesn't get overridden by anything automatically generated maybe the
#local directive can be used for something like that? Or Is Even this call to
obj really necessary? Any clue can help as I'm a PovNoob

Post a reply to this message

"Mr" <nomail@nomail> wrote:

> Thanks a lot for your support. Before I dive straight into editing my shader in
> PovWin, I also would like to ask if you think there may be a solution to this:

Don't bother actually, I just found the way to do exactly what I wanted with the
exporter, This app combination could become a killer.
(Big joy now!)

For those who would want to try it, I just had to declare the lpos and light in
the Init text file. Then anything referring to the object I put in the PovMat
text file which is appended late enough in the pov files to be able to call for
it after it has automatically been declared.

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...?

Post a reply to this message

Mr wrote:
> "Mr" <nomail@nomail> wrote:
> 
>> Thanks a lot for your support. Before I dive straight into editing my shader in
>> PovWin, I also would like to ask if you think there may be a solution to this:
> 
> Don't bother actually, I just found the way to do exactly what I wanted with the
> exporter, This app combination could become a killer.
> (Big joy now!)

I'm glad you got it working!

> 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.

Sam

Post a reply to this message

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] hotmailcom> 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