Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: It would be good to remove every shading
: stuff from povray and use only compiled scripts. Slower, but much
: better.

  NO THANKS!!!

  Rendering is painly slow already. That kind of "let's make it even slower
than it currently is" idea is just plain ridiculous.

  Adding more scripting support is ok, not *replacing* anything!

: Another option (a better one imho because it's lots faster and
: easier to develop too) is to use a shader-plugin architecture

  Dynamically loadable plugins and portability are mutually exclusive.
Not likely to happen. (Include files are a different thing, if that's what
you were talking about.)

: 2) AFAIK (mabye i'm saying just bullshits here) povray does not use
: BSP trees for triangle meshes.

  It uses octrees. It is very fast.
  Have you ever tried rendering a mesh with millions of triangles?

: Also it would be nice
: to improve some routines (for example, intersection tests) with asm.

  And drop out portability?
  Besides, you are optimizing just for ONE processor, while a compiler can
optimize for any new processor in the future. Compilers are not that bad
at optimizing (they often do a better job than a human, specially for larger
pieces of code).

: Also is megapov going to die when povray 3.5 final is out?

  This is a really frequently asked question. The answer is: No.

: 4) adaptive DOF

  Focal blur? It has existed for years.

: 6) better radiosity :P

  Better in which way?

: 7) displacement mapping

  Please provide the algorithms for this.

: 8) a small rendering strip distribuition stuff over TCP/IP to set up
: small rendering farms

  With standard C++?

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message