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