Hi all.

Another service release :)

2 bug fixes:
- missing shader call for non-objects added (problem when using a shader
pigment in a warp).
- bug fix for crash when using a declared camera with normal.

This version is now available here:

http://tofbouf.free.fr/clothray/download_en.html


Bye.

Bouf.

Post a reply to this message

Hi Christophe,

Many thanks to you and Vahur for this.

Mike Andrews.

Christophe Bouffartigue wrote:
> 
> Hi all.
> 
> Another service release :)
> 
> 2 bug fixes:
> - missing shader call for non-objects added (problem when using a shader
> pigment in a warp).

[snip]

Post a reply to this message

I played with the new sample scenes for isosurface shaders, found the
speed differences quite interesting.  

The shader rmf was much slower than the hardcoded ridgedMF function, but
with the torus shape the shader lies just between hardcoded and directly
written function.  This means that the compiled shaders are significantly
faster than the current isosurface function interpreter.  I don't know
what optimizations are planned for Povray 3.5 in that direction - just
wanted to share this observation.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3ACB5155.AA9581F7@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

>  This means that the compiled shaders are significantly
> faster than the current isosurface function interpreter.  I don't know
> what optimizations are planned for Povray 3.5 in that direction - just
> wanted to share this observation.

For complex isosurface functions a speedup factor of ten is possible,
but for extremely simple functions (like x*y) a minor slowdown will
occur.  However, all noteworthy limits in function size are eliminated
and there are hooks that could allow another factor of ten speedup (no
kidding!)...


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> For complex isosurface functions a speedup factor of ten is possible,
> but for extremely simple functions (like x*y) a minor slowdown will
> occur.  However, all noteworthy limits in function size are eliminated
> and there are hooks that could allow another factor of ten speedup (no
> kidding!)...
> 

That sounds really very good, especially if it also applies for pigment
functions (of course the pigments themselves can be very slow which is
probably more difficult to optimize)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3ACB6E40.E27E58C1@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> That sounds really very good, especially if it also applies for pigment
> functions (of course the pigments themselves can be very slow which is
> probably more difficult to optimize)

The speedup is in the actual function...the speed cost of pigment 
functions is mainly from stuff that's hard-coded C, so it most likely 
won't be faster. The only way to increase that speed would be to work on 
the pigment code, which is completely separate from the isosurface 
function code.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> The speedup is in the actual function...the speed cost of pigment
> functions is mainly from stuff that's hard-coded C, so it most likely
> won't be faster. The only way to increase that speed would be to work on
> the pigment code, which is completely separate from the isosurface
> function code.
> 

I know, just thought the actual isosurface code for calculating the ray
intersection was maybe changed too which would speed up those things
equally.  

I'm quite sure there are also possibilities for optimizing that, for
example by caching previously calculated values.     

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Thorsten Froehlich wrote:
> 
> For complex isosurface functions a speedup factor of ten is possible,
> but for extremely simple functions (like x*y) a minor slowdown will
> occur.  

Could someone disclose the secret of this "trick"? I'd like to know, how
was this acieved? Are isosurface functions precompiled in some way? Or
is the isosurface potential value calculation algorithm changed, which
allows this speedup ("minor slowdown")?
Some example of complex function?

Shaders execute functions 2-3 times faster (e.g. functions from
math_pigm.pov were 3 times faster), with more complex functions this
speedup is probably even bigger, but I'm not sure, whether speedup of 10
will be achieved.


> However, all noteworthy limits in function size are eliminated
> and there are hooks that could allow another factor of ten speedup (no
> kidding!)...

How do these hooks work? 

Vahur,
who can't wait for release of 3.5 to examine source code...

Post a reply to this message

In article <3ACC23F7.B8BCEFD8@aetec.ee> , Vahur Krouverk 
<vah### [at] aetecee>  wrote:

> Could someone disclose the secret of this "trick"? I'd like to know, how
> was this acieved? Are isosurface functions precompiled in some way? Or
> is the isosurface potential value calculation algorithm changed, which
> allows this speedup ("minor slowdown")?

The minor slowdown is caused by more overhead starting to evaluate a
function.  The speedup is due to a (very simple) VM architecture and
support for optimization of expressions.

>> However, all noteworthy limits in function size are eliminated
>> and there are hooks that could allow another factor of ten speedup (no
>> kidding!)...
>
> How do these hooks work?

They allow you to take the VM code and generate native code prior to
rendering.  Since every VM instruction takes about 15-20 native
instructions, you can reduce the code executed to about 1/15-1/20 by
compiling.  However, since you get better pipelining effects when using
the VM, the speedup will be a bit lower than the 15-20 times maximum.
It will actually be less if you call "slow" native functions like sin or
sqrt (because then the VM overhead will be a smaller percentage of the
whole), but you get a factor of about ten for functions that use only
basic math.

> Vahur,
> who can't wait for release of 3.5 to examine source code...

You? ;-)


     Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> The minor slowdown is caused by more overhead starting to evaluate a
> function.  The speedup is due to a (very simple) VM architecture and
> support for optimization of expressions.
> 
Ahah! This (esp. optimization) may become handy in shading language VM
as well. I've thought, that it would be good, if isosurface and shading
language use same VM, for they are quite similar (talking within my
limited knowledge of iso functions, of course!) but this is still more
work than I want to do, especially now when 3.5 is around a corner.
Expression optimization: does this mean, that if expression's value does
not depend from run-time variables (e.g. sin(45)/sqrt(2)?), then its
value calculation is done beforehand? I've thought about doing this in
shading language compiler, but this is another not-yet-done thing.

> > How do these hooks work?
> 
> They allow you to take the VM code and generate native code prior to
> rendering.  
I'm interested in this approach (thinking again about SL VM). Is this
"home-made" solution or are there publications available about this
technique? Will this hooking solve cross-platform compatibility?

> > Vahur,
> > who can't wait for release of 3.5 to examine source code...
> 
> You? ;-)

OK, I have to admit: I lied. My grandmother forced me to write this, she
is the one who can't wait, _my_ middle name is Patience ;-)

Vahur P. Krouverk

Post a reply to this message