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

On Tue, 04 Dec 2001 13:35:29 GMT, Angelo 'kENpEX' Pesce wrote:
> suggest another feature now: full support of compiled scripts too...

Quick, how do you represent a floating-point number in a cross-platform
binary format?

You know, we've thought of this sort of thing before.  It's easy enough to
make a utility program output scripts, and not as hard or as slow to parse
as you think it is.  It's not easy to keep any sort of "compiled" format
standardized - so no utility program would be able to keep up - and in 
any case, it wouldn't read into the renderer any faster.  Profiling has
shown us that the vast majority of our parse time is spent allocating 
memory.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

On Tue, 04 Dec 2001 13:35:29 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
> That's why I
> suggest another feature now: full support of compiled scripts too...

I think you are talking about binary format rather than compiled scripts. It was
talked so many times. If not ... The parser waste time with memory allocations.
If you don't want memory allocations you can swap and restore whole block of POV
memory ("comiled" script). But it is not portable at all and I doubt it is
portable between sessions.

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

Are you talking about something similiar to my idea from last week in
povray.general, right ?

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

Angelo 'kENpEX' Pesce wrote:
> 
> On 3 Dec 2001 16:18:05 -0500, Warp <war### [at] tagpovrayorg> wrote:
> >  Adding more scripting support is ok, not *replacing* anything!

Making easier to add more pattern should be ok, 
but dynamic loading of binary is bad for portability, unless
 you re-implement a on-the-fly compilation of source...
 but then, you stopped doing a renderer and started making a 
  compiler/fast interpreter (p-code ? No thanks! Java, ditto).
 

> >
> >Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
> >: 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,

Search for povman : you will see a povray derivative using shader...
  it might be useful for developing a new pattern because you need
  not to know the internal of povray to add and use it, 
  but IMO the official povray should have all pattern hard-coded !

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

Just because MS W* lack a decent editor is not a reason to stop portability.
The front-end might be different, but scenes render the same whatever the
platform. you're suggesting to stop that, and that's a bad idea.

> 
> >: 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 either the Job of the compiler, or a gigantic workload.
By the time you will be ready with the asm version, your CPU will be out-dated.
 (Next to P4 is Itanium, which is not compatible at the instruction level !
 Just ask the Mac people how they went from the M68000 to the G4... the
 OS add to have an emulator for 68000 code and new programs had both version
 compiled until it officially says that it won't run on old mac anymore)
Moreover, for every patch, you will have to redo the work.

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

You should learn patience.
The fact is that the more power you have, the more complex the model became.
Rendering a sphere on a plane used to be very long, so they were rendered
in low resolution. Nowaday, the math is the same, but the CPU runs so fast
that you can afford multiple reflective spheres, with media and other fancy
options. 

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

IRTC images are in Jpeg, so they usually suffers from jpeg artefacts.
The constraint on file size forces to have an average compression of 6:1
 (800*600 at 24 bit is 1.4 Mega, allowed is 250 ko !), so it's hard
to judge the anti-aliasing with that compression.

> 
> >: Also is megapov going to die when povray 3.5 final is out?
> >  This is a really frequently asked question. The answer is: No.
> 

It might just be quite the opposite: a lot of patchers are awaiting
the final 3.5 before doing more patchs.

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

B*S*. Because the radiosity in povray is not called Montecarlo, it 
nevertheless use a lot of random rays.
Montecarlo is a buzzword for an heuristic which use random sample instead
of full study. 


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

Displacement mapping is fast only with mesh.
So, it's easily done in the other renderers, because all they know are usually
meshes (even nurbs rendered tends to fake the rendering by tesselating the 
nurbs as a mesh). For them, even a sphere is a mesh!
Once that said, I have done displacement routine for mesh in pov.
That's easy, you input a mesh and a displacement pattern, and end up
with a displaced mesh. (I'm waiting for the 3.5 to finish it, because
currently, the texture does not follow the displacement, so
strange things happened with non-plain texture!)

Wanting to Do displacement for mathematical object (as most pov object are), 
is a kind of abberation of the mind (No offense intended for the people 
who did it, you are great, because It has been done also for pov, 
it was very slow but it worked).

The only reasonnable solution would be to transform the pov-object in
a mesh, and then do as the other renderers for displacement.
BUT UNDERSTAND ME WELL FIRST: I do NOT want that all the pov-object be
transformed
in mesh, I really like the pov approach of mathematical objects!


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

It's better then to have it as an independant package, provided separately.
Best renders farms are made by sharing the disk, and then 
calling povray for each frame on a different machine. The biggest thing
is knowing a machine is idle and there is something to render, while
avoiding collision.

> Just another thing... Why don't include in the standard pack a few
> selected 3rd party tools/include files? 

You already have a lot of demo scenes. It's even bigger in 3.5 !

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

Translation: without them, lightwave is crap and worth nothing.

May I remind you that Pov want to be free and portable.

That means that only 3rd party include would qualify, as 
I cannot imagine distributing the source of a restricted shareware...

I hardly mastered the include file from 3.1 after a few years,
and it seems it will take me more time for the numerous in 3.5
 (Hopefully, the help is there, with good samples !)

FYI, the old dkbtrace (the ancestor of povray) came with a set of
C programs to perform some operation (such as repeating an object
with rotation and scale to produce kind of shells). Pov has since
evolved so as that such things can be done directly in the SDL.

Post a reply to this message

On 4 Dec 2001 08:26:50 -0500, Ron Parker <ron### [at] povrayorg>
wrote:

>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,
Once you've made a dll loader for win,linux and mabye mac you've
covered much of the povray's users, also I can't imagine a unix user
that does not know how to use a compiler... And there are windows
compilers that are free too, btw, as for windows you will be using
dlls this is not a problem... If you're thinking about the fact that
povray users can't write their own shaders without the compiler
well... you can't have anything. Shader support IS a MAJOR feature (it
is it is it is), now you have only to choose between a slow and script
based and less flexible (as the script won't have the same power of a
complete programming language) or a faster choice... BTW for win you
can d/l mingw32 or lcc32 that is very tiny and easy to use too. and
BTW if you want to code a script, you should really have some
programming skills...

>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.
Well you can develop a full compiler system like the renderman
scripting stuff (renderman shaders are compiled and executed in a
virtual machine) but this is WAY harder and still slower...

>>>: 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.
This is an old topic. I agree that the algorithm makes the difference,
but with asm you CAN speed up anything appreciably than c compiled
code. And this is particulary true for complex floating point math as
compilers can't really do a good job with f.p. (I'm talking about my
experience with Intel chips).


>>>: 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.
1) Someone asked me how to do that
2) I know that everyone can look at siggraph stuff, but as I have some
friends that actually implemented disp.mapping in a raytracer (I'm not
the only one that has an interest in raytracing) mabye I could ask
them to clear out things, if U have any problem

>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.
Yep, many renderers use that trick. I don't think that they are
"inferior" renderers btw but this is a topic for a big talk, I would
be very pleased to do such talk with other raytracing fans but this
won't help povray developing much...

>> 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? 
Superb but huuge. It's not easy for a beginner to navigate it as links
are not rated

 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.
Yes but you have to spend a lot of time to download and configure this
stuff. Making them part of the "official" distro could save time to
inexperienced users that mabye don't know that there's something that
already did that macro or this external tool... It seems to me that
povray is a bit slow into incorporating stuff that other ppl did for
it (for example now you're merging megapov in the official pov source
tree, it seems, I hope you're not recoding megapov stuff...). Btw this
is not very important... Ah... bigger download is not a very good
reason btw, as U can always do it as an optional pack... (this would
be a really good idea).

Post a reply to this message

Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: 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)...

  I don't understand how speed affects antialiasing quality. You speak like
a faster program would make a better antialiasing.
  Of course a smaller antialiasing threshold takes longer to render, but the
result will be identical independently of how fast the program or the
computer is.
  If you had said "a faster program allows you to use a higher quality
antialiasing in the same render time", that would have been more accurate.
  And besides, I don't remember seeing many images with crappy antialiasing
in the IRTC.

-- 
#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 4 Dec 2001 08:42:28 -0500, Ron Parker <ron### [at] povrayorg>
wrote:

>On Tue, 04 Dec 2001 13:35:29 GMT, Angelo 'kENpEX' Pesce wrote:
>> suggest another feature now: full support of compiled scripts too...
>
>Quick, how do you represent a floating-point number in a cross-platform
>binary format?

Like java class files do? IEE754 format? Using 128bit fixedpoint math?
>
>You know, we've thought of this sort of thing before.  It's easy enough to
>make a utility program output scripts, and not as hard or as slow to parse
>as you think it is.  It's not easy to keep any sort of "compiled" format
>standardized - so no utility program would be able to keep up - and in 
>any case, it wouldn't read into the renderer any faster.  Profiling has
>shown us that the vast majority of our parse time is spent allocating 
>memory.

Mhm yes I agree with you, writing a script file is not so hard (btw I
still think that the pov script language is not very well suited for
that kind of conversion), but reading a script file is! And many tools
require that. So mabye it's easyier to decouple the script-reading
stuff from povray and make a library for tool developers. Btw those
are only raw ideas, mabye someone already did that or did something
better!
>
>-- 
>plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
>z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
>*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
>"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: if I want more quality I have
: only to run lightflow (that is the best raytracer that I know of,
: imho)

  Show us some lightflow images which can't be done in POV-Ray.

-- 
#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 15:07:46 +0100, W³odzimierz ABX Skiba
<abx### [at] babilonorg> wrote:

>On Tue, 04 Dec 2001 13:35:29 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
>> That's why I
>> suggest another feature now: full support of compiled scripts too...
>
>I think you are talking about binary format rather than compiled scripts. It was
>talked so many times. If not ... The parser waste time with memory allocations.
>If you don't want memory allocations you can swap and restore whole block of POV
>memory ("comiled" script). But it is not portable at all and I doubt it is
>portable between sessions.
>
>> 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.
>
>Are you talking about something similiar to my idea from last week in
>povray.general, right ?
mhm mabye I can't remember well because I've read maaaaany msgs in
those days (I'm a newbie of this ng and this is clear as many ppl
think that i'm just another lamer, it seems).

Post a reply to this message

Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: Using 128bit fixedpoint math?

  Why not just ASCII? You'll get more accuracy, and ASCII floats seldom take
more than 16 characters.

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

In article <slr### [at] fwicom> , Ron Parker 
<ron### [at] povrayorg>  wrote:

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

Not to mention that the POV-Team (actually only Chris Cason) would have to
pay for users to be able to download it.  It is not like hosting servers
with several terabyte annual traffic is done for free by anybody without a
commercial interest in what they are distributing...

    Thorsten

Post a reply to this message

On Tue, 04 Dec 2001 15:54:46 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
> > Are you talking about something similiar to my idea from last week in
> > povray.general, right ?
> mhm mabye I can't remember well because I've read maaaaany msgs in
> those days

http://news.povray.org/povray.general/20336/

> (I'm a newbie of this ng and this is clear as many ppl
> think that i'm just another lamer, it seems).

As a newbie (in pov-community) you shuldn't mixing so much at begining. Mostly
you are talking about things already discussed. But it seems it is privilage of
newbies.

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

On 4 Dec 2001 10:53:11 -0500, Warp <war### [at] tagpovrayorg> wrote:
>  Show us some lightflow images which can't be done in POV-Ray.

I advise "lightflow" searching at povray.binaries.images first :-)

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

In article <3c0cc693.932849@news.povray.org> , ken### [at] uniplanit (Angelo 
'kENpEX' Pesce) wrote:

> if compared to stuff like lightflow or mentalray or other renderers

Remind me, what did Softimage with Mental Ray cost again?  About as much as
a mid-sized car?  Or was is a Mercedes?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Tue, 04 Dec 2001 16:01:51 +0100, =?iso-8859-1?Q?J=E9r=F4me?=
Grimbert <jer### [at] atosorigincom> wrote:

>Angelo 'kENpEX' Pesce wrote:
>> 
>> On 3 Dec 2001 16:18:05 -0500, Warp <war### [at] tagpovrayorg> wrote:
>> >  Adding more scripting support is ok, not *replacing* anything!
>
>Making easier to add more pattern should be ok, 
>but dynamic loading of binary is bad for portability, unless
> you re-implement a on-the-fly compilation of source...
> but then, you stopped doing a renderer and started making a 
>  compiler/fast interpreter (p-code ? No thanks! Java, ditto).

But this is what pixar's photorealistic renderman does, and renderman
is famous (and it's the most used renderer for film stuff) just
because of its rendering speed (==quality :P) and of its shader
support

>> >
>> >Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>> >: 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,
>
>Search for povman : you will see a povray derivative using shader...
>  it might be useful for developing a new pattern because you need
>  not to know the internal of povray to add and use it, 
>  but IMO the official povray should have all pattern hard-coded !
I know it... It would be really nice to have the povman system in the
main povray distro!!! Actually I don't use povray 3.1, just megapov
and povman

>> 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).
>
>Just because MS W* lack a decent editor is not a reason to stop portability.
>The front-end might be different, but scenes render the same whatever the
>platform. you're suggesting to stop that, and that's a bad idea.
I'm not suggesting to stop that at all... Just if U have a system
without dynamic plugin support you'll have to recompile povray with
every plugin you need and then you can render every scene you want.
This is what povray *ACTUALLY* does, so using plugins will only
improve povray usability for some plattforms, but not penalize the
others, as for the others the system will remain the same (of course
there should be a way to compile a "plugin" as a plugin or not without
modifing its source...)

>> >: 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 either the Job of the compiler, or a gigantic workload.
>By the time you will be ready with the asm version, your CPU will be out-dated.
> (Next to P4 is Itanium, which is not compatible at the instruction level !
> Just ask the Mac people how they went from the M68000 to the G4... the
> OS add to have an emulator for 68000 code and new programs had both version
> compiled until it officially says that it won't run on old mac anymore)
>Moreover, for every patch, you will have to redo the work.
Of course you should recode in asm only a few routines, that won't
change easily between versions (you know, I don't think you're going
to change the ray-sphere intersection test), also if you wrote
something for p3 you don't have to think that you've wasted work just
because p4 is out (and it have a completelly different architecture),
you have just to add (someday) the support for the new cpu. And btw
there's some ppl that goes crazy for asm optimization so there can be
a team of "assemblers" that do only this stuff, I don't think that it
will take soooo much time...

>> 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. 
>
>You should learn patience.
>The fact is that the more power you have, the more complex the model became.
>Rendering a sphere on a plane used to be very long, so they were rendered
>in low resolution. Nowaday, the math is the same, but the CPU runs so fast
>that you can afford multiple reflective spheres, with media and other fancy
>options. 
Nope. What I was trying to say is that it's wiser to concentrate into
optimizing a renderer than into adding more complex features. For
example, radiosity,caustics,diffraction,etc etc... are complex topics
that require hard work, but they are not really useful as they
influence just a small number of images. Photorealistic renderman is
not a raytracer, it doesn't have correct reflections as it uses
reflection mapping afaik (I don't know if pixar changed something, but
at least the prman used for ToyStory was like that and I know that
prman is not a raytracer), it doesn't have radiosity nor caustics nor
those fancy things, but it's really famous and many ppl use it. Why?
Because it's fast and U can affod doing complex scenes with it in
reasonable time (you always have a time limit if you're doing
something serious).

>> 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)...
>
>IRTC images are in Jpeg, so they usually suffers from jpeg artefacts.
>The constraint on file size forces to have an average compression of 6:1
> (800*600 at 24 bit is 1.4 Mega, allowed is 250 ko !), so it's hard
>to judge the anti-aliasing with that compression.
jpeg artifacts usually tend to smooth out details and add noise in the
color channels, not to sharpen edges...

>> >: Also is megapov going to die when povray 3.5 final is out?
>> >  This is a really frequently asked question. The answer is: No.
>It might just be quite the opposite: a lot of patchers are awaiting
>the final 3.5 before doing more patchs.

>> >: 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.
>B*S*. Because the radiosity in povray is not called Montecarlo, it 
>nevertheless use a lot of random rays.
>Montecarlo is a buzzword for an heuristic which use random sample instead
>of full study. 
Yes I know but afaik povray actually uses something like path tracing
(I'm not sure, so if U can also explain me this I'll be happy, as I
could not find a tech doc on povray internals) assuming that as
diffuse lighting does not change a lot over surfaces you can subsample
this stage and do linear interpolation.You know that this is not
really correct, at least you could do some adaptative evalutation
instead of a fixed grid by using a quadtree.
 
>> >: 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
>Displacement mapping is fast only with mesh.
>So, it's easily done in the other renderers, because all they know are usually
>meshes (even nurbs rendered tends to fake the rendering by tesselating the 
>nurbs as a mesh). For them, even a sphere is a mesh!
Yes I know. This is a not so lame approach by the way... Btw I replied
to that into another post.>Once that said, I have done displacement
routine for mesh in pov.

>That's easy, you input a mesh and a displacement pattern, and end up
>with a displaced mesh. (I'm waiting for the 3.5 to finish it, because
>currently, the texture does not follow the displacement, so
>strange things happened with non-plain texture!)
Well but "those" mesh renderes don't do only that... They at least try
to do an adaptive subdivision to make displacement mapping nice :P

>Wanting to Do displacement for mathematical object (as most pov object are), 
>is a kind of abberation of the mind (No offense intended for the people 
>who did it, you are great, because It has been done also for pov, 
>it was very slow but it worked).
:) Where can I find this "abberated" pov-patch??

>The only reasonnable solution would be to transform the pov-object in
>a mesh, and then do as the other renderers for displacement.
>BUT UNDERSTAND ME WELL FIRST: I do NOT want that all the pov-object be
>transformed
>in mesh, I really like the pov approach of mathematical objects!
Mhm yes, this is a matter of taste. But I also really like the power
of displacement mapping!!! :P

>> >: 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...
>It's better then to have it as an independant package, provided separately.
>Best renders farms are made by sharing the disk, and then 
>calling povray for each frame on a different machine. The biggest thing
>is knowing a machine is idle and there is something to render, while
>avoiding collision.
Mhm do U know of a tool like that for povray? It would be really
useful...

>> Just another thing... Why don't include in the standard pack a few
>> selected 3rd party tools/include files? 
>You already have a lot of demo scenes. It's even bigger in 3.5 !

>> 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)...
>Translation: without them, lightwave is crap and worth nothing.
Mhm, you lightwave does not deserve those words. It's one of the best
polygonal modellers around, one of the first subdivision surfaces
modeller, one of the fastest raytracers around and imho the better
raytracer around when it comes to rendering quality (and I can
remember that DigitalDomain rated lw5.6 as the second best quality
rendered in their choice).

>May I remind you that Pov want to be free and portable.
>That means that only 3rd party include would qualify, as 
>I cannot imagine distributing the source of a restricted shareware...
Well there are MANY intresting include files that really BOOST povray
rendering power...

>I hardly mastered the include file from 3.1 after a few years,
>and it seems it will take me more time for the numerous in 3.5
> (Hopefully, the help is there, with good samples !)

>FYI, the old dkbtrace (the ancestor of povray) came with a set of
>C programs to perform some operation (such as repeating an object
>with rotation and scale to produce kind of shells). Pov has since
>evolved so as that such things can be done directly in the SDL.

Post a reply to this message

On Tue, 04 Dec 2001 17:11:08 +0100, W³odzimierz ABX Skiba
<abx### [at] babilonorg> wrote:

>On Tue, 04 Dec 2001 15:54:46 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
>> > Are you talking about something similiar to my idea from last week in
>> > povray.general, right ?
>> mhm mabye I can't remember well because I've read maaaaany msgs in
>> those days
>
>http://news.povray.org/povray.general/20336/
>
>> (I'm a newbie of this ng and this is clear as many ppl
>> think that i'm just another lamer, it seems).
>
>As a newbie (in pov-community) you shuldn't mixing so much at begining. Mostly
>you are talking about things already discussed. But it seems it is privilage of
>newbies.
Well this is normal, as I can't know that things have already been
discussed! I haven't found a povray.programming faq or any other faq
that tells users why povray has some features, why other features are
discarded and stuff like that

Post a reply to this message

Angelo 'kENpEX' Pesce wrote:
> 
> mhm mabye I can't remember well because I've read maaaaany msgs in
> those days (I'm a newbie of this ng and this is clear as many ppl
> think that i'm just another lamer, it seems).

Although i think nearly everyone who answered your postings was quite
friendly it would probably be a good idea to read some of the previous
discussions on these subjects, a lot of the things you mentioned are also
covered somehow in Warp's VFAQ:

http://www.students.tut.fi/~warp/povVFAQ/

And i think it would be good to simply accept the fact that there won't be
new features introduced that only work on a few platforms, no matter if
these cover 90% of the users or not.  Same probably applies for algorithms
that require tesselation of objects.

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 <3c0cd249.3930998@news.povray.org> , ken### [at] uniplanit (Angelo 
'kENpEX' Pesce) wrote:

>>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?
>
> Superb but huuge. It's not easy for a beginner to navigate it as links
> are not rated

We are working on that...

    Thorsten

Post a reply to this message

In article <3c0cf075.11656238@news.povray.org> , ken### [at] uniplanit (Angelo 
'kENpEX' Pesce) wrote:

> Like java class files do? IEE754 format? Using 128bit fixedpoint math?

And then just do a fread?  Try it, and you will be very surprised.  Or look
into the JVM source code and see how easy it is...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Tue, 04 Dec 2001 15:46:57 GMT, Angelo 'kENpEX' Pesce wrote:
> already did that macro or this external tool... It seems to me that
> povray is a bit slow into incorporating stuff that other ppl did for
> it (for example now you're merging megapov in the official pov source
> tree, it seems, I hope you're not recoding megapov stuff...). Btw this

Of COURSE we're recoding megapov stuff.  What, you thought it was done
right?

All of this has been discussed ad nauseum before.  I will not discuss it
further.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

On Tue, 04 Dec 2001 17:37:32 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> We are working on that...

I hope for large web update with finale 3.5 release :-)

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

In article <3c0cf1f2.12037077@news.povray.org> , ken### [at] uniplanit (Angelo 
'kENpEX' Pesce) wrote:

> I'm not suggesting to stop that at all... Just if U have a system
> without dynamic plugin support you'll have to recompile povray with
> every plugin you need and then you can render every scene you want.
> This is what povray *ACTUALLY* does, so using plugins will only
> improve povray usability for some plattforms, but not penalize the
> others, as for the others the system will remain the same (of course
> there should be a way to compile a "plugin" as a plugin or not without
> modifing its source...)

I am not aware of any POV-Ray "plug-ins" at all, be they dynamically or
statically linked.  Maybe one of us is on the wrong planet.  I am sure it
isn't me, so it must be you.

Anyway, looking back at my first reply, "Looks like you have a few
misconceptions about POV-Ray (or are looking for a flame war).", I have to
correct myself.  I should have asked "Why are you looking for a flame war?"!

    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

On Tue, 04 Dec 2001 17:29:45 +0100, Christoph Hormann
<chr### [at] gmxde> wrote:

>
>
>Angelo 'kENpEX' Pesce wrote:
>> 
>> mhm mabye I can't remember well because I've read maaaaany msgs in
>> those days (I'm a newbie of this ng and this is clear as many ppl
>> think that i'm just another lamer, it seems).
>
>Although i think nearly everyone who answered your postings was quite
>friendly
I think so too

> it would probably be a good idea to read some of the previous
>discussions on these subjects, a lot of the things you mentioned are also
>covered somehow in Warp's VFAQ:
>http://www.students.tut.fi/~warp/povVFAQ/
mhm... I've read that

>And i think it would be good to simply accept the fact that there won't be
>new features introduced that only work on a few platforms, no matter if
>these cover 90% of the users or not.  Same probably applies for algorithms
>that require tesselation of objects.
well if that's the point, I accept it. I accept every decision of
povray team, mabye I don't agree, but as I'm not a povray developer, I
can only accept it... I'm just telling what I think, it many other ppl
think that I'm right, mabye the povteam will change its mind... That's
what a ng is for I think

Post a reply to this message

On 4 Dec 2001 10:50:59 -0500, Warp <war### [at] tagpovrayorg> wrote:

>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>: 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)...
>
>  I don't understand how speed affects antialiasing quality. You speak like
>a faster program would make a better antialiasing.
>  Of course a smaller antialiasing threshold takes longer to render, but the
>result will be identical independently of how fast the program or the
>computer is.
>  If you had said "a faster program allows you to use a higher quality
>antialiasing in the same render time", that would have been more accurate.
>  And besides, I don't remember seeing many images with crappy antialiasing
>in the IRTC.
If your time limit is +inf, then speed is not equal to quality. Other
wise it is. But usually when I talk I'm thinking of real world, not of
every other thing.

>
>-- 
>#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 17:21:55 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>In article <3c0cc693.932849@news.povray.org> , ken### [at] uniplanit (Angelo 
>'kENpEX' Pesce) wrote:
>
>> if compared to stuff like lightflow or mentalray or other renderers
>
>Remind me, what did Softimage with Mental Ray cost again?  About as much as
>a mid-sized car?  Or was is a Mercedes?
Lightflow is free for non commercial use and imho it's better than
mentalray or lightwave 6 renderer. Someone thing that free stuff
should be worse than commercial stuff, some others not... Btw
softimage costs about as much a mid-sized car, or a small mercedes :P

Post a reply to this message

On Tue, 04 Dec 2001 17:39:54 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>In article <3c0cf075.11656238@news.povray.org> , ken### [at] uniplanit (Angelo 
>'kENpEX' Pesce) wrote:
>
>> Like java class files do? IEE754 format? Using 128bit fixedpoint math?
>
>And then just do a fread?  Try it, and you will be very surprised.  Or look
>into the JVM source code and see how easy it is...
Of course not...

Post a reply to this message

On Tue, 04 Dec 2001 17:44:52 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>In article <3c0cf1f2.12037077@news.povray.org> , ken### [at] uniplanit (Angelo 
>'kENpEX' Pesce) wrote:
>
>> I'm not suggesting to stop that at all... Just if U have a system
>> without dynamic plugin support you'll have to recompile povray with
>> every plugin you need and then you can render every scene you want.
>> This is what povray *ACTUALLY* does, so using plugins will only
>> improve povray usability for some plattforms, but not penalize the
>> others, as for the others the system will remain the same (of course
>> there should be a way to compile a "plugin" as a plugin or not without
>> modifing its source...)
>
>I am not aware of any POV-Ray "plug-ins" at all, be they dynamically or
>statically linked.  Maybe one of us is on the wrong planet.  I am sure it
>isn't me, so it must be you.
Of course you are not aware of them... This is only because it was a
feature proposal... As U can see the topic of my original post was
"Povray 4? wish list" and in the message that U've quoted I was
answering a question about them

Post a reply to this message

<SNIP>

> Nope. What I was trying to say is that it's wiser to concentrate into
> optimizing a renderer than into adding more complex features. For
> example, radiosity,caustics,diffraction,etc etc... are complex topics
> that require hard work, but they are not really useful as they
> influence just a small number of images. Photorealistic renderman is
> not a raytracer, it doesn't have correct reflections as it uses

<SNIP>

No, more features please!!!!!! the render time is something that will be solved
automatically be new computers, it is easier and cheaper to buy a new machine every
so often then it is to change the source code each time. although network support
would be nice ofcourse :)


Thomas

ps. And remember even assembler might perform VERY bad on different processors of
the same family. Just look at RC5 on RS-64III

Post a reply to this message

> Lightflow is free for non commercial use and imho it's better than
> mentalray or lightwave 6 renderer. Someone thing that free stuff
> should be worse than commercial stuff, some others not... Btw
> softimage costs about as much a mid-sized car, or a small mercedes :P

And have you ever tried the python interface to Lightflow? it is a bit crappy
compared to POV's. Yes you can do some stuff pov can't, but some stuff is very
complicated in it.

Thomas

Post a reply to this message

>  Or look into the JVM source code and see how easy it is...

hmmmmm I might take you on to that, the guys are sitting right upstairs here ;)



Thomas

Post a reply to this message

On Tue, 04 Dec 2001 17:11:21 +0000, Thomas <tho### [at] gmxnet> wrote:
> And have you ever tried the python interface to Lightflow? it is a bit crappy
> compared to POV's. Yes you can do some stuff pov can't

IIRC Warp waits for chellenge :-)

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

"W³odzimierz ABX Skiba" wrote:

> On Tue, 04 Dec 2001 17:11:21 +0000, Thomas <tho### [at] gmxnet> wrote:
> > And have you ever tried the python interface to Lightflow? it is a bit crappy
> > compared to POV's. Yes you can do some stuff pov can't
>
> IIRC Warp waits for chellenge :-)

What I ment is because LightFlow uses a Python interface you can build programs
that include other kinds of functionality. One could build a webserver that renders
an image on request by a client all done in a single source file. I know it is a
bit weird and the same could be achieved WITH pov and some scripts on a unix
machine with some clever redirecting. And I'm not gonna take on Warp's challenge on
that ;)


Thomas

Post a reply to this message

On Tue, 04 Dec 2001 17:11:21 +0000, Thomas <tho### [at] gmxnet> wrote:

>> Lightflow is free for non commercial use and imho it's better than
>> mentalray or lightwave 6 renderer. Someone thing that free stuff
>> should be worse than commercial stuff, some others not... Btw
>> softimage costs about as much a mid-sized car, or a small mercedes :P
>
>And have you ever tried the python interface to Lightflow? it is a bit crappy
>compared to POV's. Yes you can do some stuff pov can't, but some stuff is very
>complicated in it.
>
>Thomas
Lightflow has no "interface" so I won't talk about that... Lightflow
is only a library of routines to perform raytracing, the phyton stuff
is only a port of that library to phyton, if U like ruby more, you
could use the lib with ruby, if U like java you can use java, if U
like c++....
Lightflow has no "standard" scripting language like pov

Post a reply to this message

Please, is it too much to ask that you actually spell out the words "you"
and "people"?

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
: Same probably applies for algorithms
: that require tesselation of objects.

  It is not impossible that some general tesselation routine would be added
in the future.
  (Of course tesselation is slower than one may believe, and the meshes can
take huge amounts of memory, so the feasibility of tesselating a whole
scene can be sometimes dubious.)

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

Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
:>> Just if U have a system
:>> without dynamic plugin support you'll have to recompile povray with
:>> every plugin you need and then you can render every scene you want.
:>> This is what povray *ACTUALLY* does

: Of course you are not aware of them... This is only because it was a
: feature proposal...

  You said "this is what povray *ACTUALLY* does". Now you say it was only
a proposal, not something povray is actually doing..

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

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
:>  Show us some lightflow images which can't be done in POV-Ray.

: I advise "lightflow" searching at povray.binaries.images first :-)

  Granted, Lightflow can do pretty impressive things faster than povray (ie.
if you try to simulate the same image with povray it can take a lot longer).
However, the same holds in the other direction as well. And I'm pretty sure
that there are awesome images made with povray which are either impossible or
extremely slow to do with lightflow.
  Besides, AFAIK povray is usually faster than lightflow in many things.

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

In article <3c0d32ab@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Besides, AFAIK povray is usually faster than lightflow in many things.

POV-Ray is capable of real-time raytracing.  I have shown it is possible
with the plain 3.5 source code - the result is visible in the Windows and
Mac about boxes as easter egg...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: POV-Ray is capable of real-time raytracing.  I have shown it is possible
: with the plain 3.5 source code - the result is visible in the Windows and
: Mac about boxes as easter egg...

  Care to tell us how it is activated?-)

-- 
#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 4 Dec 2001 16:01:43 -0500, Warp wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>: POV-Ray is capable of real-time raytracing.  I have shown it is possible
>: with the plain 3.5 source code - the result is visible in the Windows and
>: Mac about boxes as easter egg...
> 
>   Care to tell us how it is activated?-)

By doing the right thing at the right time.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

On 4 Dec 2001 15:16:17 -0500, Warp <war### [at] tagpovrayorg> wrote:

>Christoph Hormann <chr### [at] gmxde> wrote:
>: Same probably applies for algorithms
>: that require tesselation of objects.
>
>  It is not impossible that some general tesselation routine would be added
>in the future.
>  (Of course tesselation is slower than one may believe, and the meshes can
>take huge amounts of memory, so the feasibility of tesselating a whole
>scene can be sometimes dubious.)
It's not dubious at all, as many other raytracers do that... It's
feasible, but I don't think it will be done for povray

Post a reply to this message