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

<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