On 3 Dec 2001 16:18:05 -0500, Warp <war### [at] tagpovrayorg> wrote:
>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.)

I know... but this is a major feature so I think it could be worth the
work. I know that this means to make some different implementations,
but hey, I have pov-win and it seems much different to me than
standard command-line pov (I'm saying, there is an effort to make
stuff that is non portable too). The standard unix version can discard
this feature (and just rely on static linked shaders, this means that
if U want to add a shader you have to recompile pov...) while the win
and linux ones could use dlls and .so files...

>: 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?
Mhm... Dunno, this is a thing that needs experimenting but I always
thought that bsp trees where faster

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

You can keep the portable C core and make an asm version too... This
is what happens with many "portable" project. Speed is a major issue
in a raytracer as speed==quality. It's really really unuseful to add
new features if those features are not-useabe. Most of povray images
(see IRTC etc...) have a bad aliasing (imho) because of povray is
still slow (if compared to stuff like lightflow or mentalray or other
renderers)...

>: 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.
Nope, I mean something that shoots more ray when doing DOF only if the
object hit is far away (only when the max. distance between
intersection points is lower than a threshold). I don't know if this
feature is in povray yet as I was thinking it while rendering a big
form image with vivid3 (that does not have this feat.)

>: 6) better radiosity :P
>  Better in which way?
Well, the experimental radiosity in povray 3.1 can't be called
radiosity really... It's something different, a fake imho. I think it
should use montecarlo radiosity in the future.

>: 7) displacement mapping
>  Please provide the algorithms for this.
If noone has clues on how to do this (I don't have them yet) I can
search... I have a few good doc. sources and I know ppl that did this
stuff too

>: 8) a small rendering strip distribuition stuff over TCP/IP to set up
>: small rendering farms
>  With standard C++?
Again, the same portability problem... as this is a feature that is
really important, but not vital at all there can be a makefile option
that discards it or it can be made as an external tool distribuited
with the standard binary package...

Just another thing... Why don't include in the standard pack a few
selected 3rd party tools/include files? It's not a bad idea, newtek
does something like this for lightwave plugins (they include a bunch
of freeware/lite versions of 3rdparty plugins in the main distro, they
are REALLY useful)...

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