Here there are some ideas for the next povray... Well, at last, this
is something I would like to have :P

1) Programmable shaders. PovMan is GREAT, why don't add this stuff to
the official povray too? It would be good to remove every shading
stuff from povray and use only compiled scripts. Slower, but much
better. Another option (a better one imho because it's lots faster and
easier to develop too) is to use a shader-plugin architecture

2) AFAIK (mabye i'm saying just bullshits here) povray does not use
BSP trees for triangle meshes. Why? It would not be faster with them?
It's very important to speed up the whole thing. Also it would be nice
to improve some routines (for example, intersection tests) with asm.

3) adaptive Blurred reflection, motion blur and blinn microfacet
highlights from megapov (I know that those features has been discarded
from povray 3.5 feature list but I don't know why as it's kinda easy
to do too). Also is megapov going to die when povray 3.5 final is out?

4) adaptive DOF

5) compiled scene-scripts

6) better radiosity :P

7) displacement mapping

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

Post a reply to this message

ah... an a particle system would be nice too :PPP, yes I know that it
could be made with scripts but it would be sooo slow...

Post a reply to this message

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

>   Adding more scripting support is ok, not *replacing* anything!
>
do you say shaders will be programmable like renderman shaders??

Post a reply to this message

And when you rub the mouse, make a genie come out and do your bidding ;-)

"Angelo 'kENpEX' Pesce" <ken### [at] uniplanit> wrote in message
news:3c0baf07.22135953@news.povray.org...
> Here there are some ideas for the next povray... Well, at last, this
> is something I would like to have :P
> [lots and lots of not-so-likely stuff]

Post a reply to this message

> And when you rub the mouse, make a genie come out and do your bidding ;-)

well, if you don't ask you don't get.


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

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

On Tue, 04 Dec 2001 13:02:58 GMT, Angelo 'kENpEX' Pesce demonstrated
that a little knowledge can be a dangerous thing thusly:

>>  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 it means for *everybody* to make different implementations, or for
every user to have their own compiler and know how to use it.  Sure,
GCC is free, but the "default" compilers for Mac and Windows cost actual 
money.  Besides that, most POV users (and by that I mean the ones who
haven't even found this server yet, let alone this group) are probably 
not going to want to mess with source code.

So, if we can't provide a plugin that will just work on every platform
that POV supports (ideally, including the ones that are supported by
third-party ports) it's really not going to work.

That's not to say that it'll never happen; anything's possible.  But 
if it does happen, it won't be a DLL or an .so file, and nobody will
have to use a C compiler to build it.

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

They might be marginally faster.  They're slower to build, though, so
there's a bit of a tradeoff.

> 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

Have you looked at the routines you're proposing that we rewrite in
assembly?  They're slow because they're complex floating-point math,
not because they're not assembly.  Rewriting them would accomplish just
one thing: it would make them harder for us to read.  They won't run
appreciably faster by being rewritten in any other language.  Your best
bet if you want faster is either to buy more computers or redesign the
algorithm, and buying more computers is more likely to help.

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

Well, you shall have your wish.  Ka-pwing!  It uses Monte Carlo radiosity.
Don't let it bother you that it has always used Monte Carlo radiosity; pay
no attention to that man behind the curtain.

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

Why don't you do that.  I mean, we never thought to actually look at any
sort of academic papers or scholarly journals or anything like that.  I've
never seen a SIGGRAPH proceedings in my life.  Gosh, why didn't this occur
to us sooner?  I'm sure there must be some miracle process out there by
which to displace arbitrary algebraic surfaces, if only we'd look.

But look here, we don't want any of those papers that require decomposition
into triangles, y'hear?  We already know about those, but POV doesn't use
triangles for everything like some inferior renderers do.

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

Why make the POV download take longer when you can just go download those
utilities yourself if you want them by following the links from our
linkmaster's superb link collection?  Unlike Newtek, we're not gouging 
the last dime from your wallet for our software, so we don't need to
toss in questionably-useful freeware to get you to think it was worth the
price.

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

On Tue, 4 Dec 2001 02:54:20 -0000, "Rick [Kitty5]" <ric### [at] kitty5com>
wrote:

>> And when you rub the mouse, make a genie come out and do your bidding ;-)
>
>well, if you don't ask you don't get.
Yep

I know that I'm not any better than anyone else on this ML and I'm
sorry if this was not the right ng to post this stuff on (but I don't
think so) but as a 3d graphician and a coder I thought that I could
help with my advice (as a graphician I can tell what I need, as a
coder I can see if it's doable...). I know that an advice is not much,
but I don't think I'll contribute to povray as I'm writing my own
stuff an as I'm much more interested in realtime stuff as a coder.
Rick, I'm not saying "do this or I'll kill you", it's only an advice,
I'm happy if povray goes further as it's a good opensource project
imho, but I'm not really that sad if the features that I need won't be
implemented because as a graphician I have and use SoftImage 3.9.1
extreme (this means... mental ray) and if I want more quality I have
only to run lightflow (that is the best raytracer that I know of,
imho)

Post a reply to this message

On Tue, 4 Dec 2001 02:56:07 +0200, "Ahmet Oktar"
<ahm### [at] yahoocom> wrote:

>
>>   Adding more scripting support is ok, not *replacing* anything!
>>
>do you say shaders will be programmable like renderman shaders??
>
>
Yep I say this... :) And I don't like extending the script support...
I'd like to have a more terse script as scripting (for me) only
increases parse time, memory allocation and file size (you know that
in real projects renderman scripts grow BIG). A complex
scene-description language is good if U want to do scenes by scripts,
but it seems to me that povray has not thinked at all that it would be
MUCH more useful to develop an interface between a renderer and a
modelling program than between a renderer and the user... That's why I
suggest another feature now: full support of compiled scripts too...
compiled scripts are generated easier by export plugins than script,
they are faster, require less memory and no parsing. It would be a
really good idea to make a compiled script library too, something that
can be used by the povray core rendering system and by export plugins
too, so it would be much easier to do such plugins.

Post a reply to this message