 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0f67f3.5921739@news.povray.org> , ken### [at] uniplan it (Angelo
'kENpEX' Pesce) wrote:
> So I will know not only what you're doing but also why you're not
> doing something else, and I can propose U to do things only if they
> are not in the todo/nottodo list... Also if I have (I or someone else
> this is obvious) an idea on the l,m,n things that solve a problem and
> make them more easy, I can tell U... Is this wise? I think so...
But we did that! Read the 3.5 announcement from last year. It said what
would be in 3.5, what was under evaluation and what would not be included.
As it has already been stated in p.beta-test the team will start the
devlopment of POV-Ray 4.0 after POV-Ray 3.5 is out. So how can we give you
a complete list of something we haven't even started to work on? We have
plans, not more not less, but none of those is final and there will be no
public announcement until a decison of which features goes into which of the
above categories has been made.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0f6a1f.6477919@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
> I think that there is some feature missing for that. This is what I'm
> trying to say in this thread... If U don't think so, please explain me
> why a program like lightflow (yes I always talk about that renderer,
> it's only because I know it a bit more than others, don't blame me)
> that's really new (1 or 2 years old?) developed by a single person,
It was released by that time. Nobody knowns how long the development really
took!
> that is NOT opensource at all (not so free) and this is something that
> should really go against it, I mean if I don't have the sources I
> don't know the inner-workings, it's lots harder to do an accurate
> exporter, well, why this program that seems to be so inadeguate for
> 3rd party development actually already has a working maya and 3dsmax
> exporter, while noone in 10 years made a good exporter for those
> super-wide-spread packages with povray... Mabye there is some
> difference...
Why? Maybe ecause nobody who uses a free program has the money to buy Maya
and 3D Studio Max? I, and that much is sure, don't have the money for
those...
On the other hand, if you want to sell a new product that orginally wasn't
compatible with anything but itself doesn't sell because of that and you
then take a year to write modules so people (who have money to buy your
product) can export from their tools to yours, I call that economic
interest. And I think we both agree that economic interest is a very
powerful driving force.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce wrote:
> I agree with you... you're right... But an interface between povray
> team and povray users is necessary, otherwise how can U know that a
> feature is more or less wanted?
http://tag.povray.org/
--
Ken Tyler - ken### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0f6cdd$1@news.povray.org> , "Mael" <mae### [at] hotmailcom>
wrote:
> how do you explain the success of others open source projects ?
Success in what regard? Quality or geek usage? What about Linux kernel
2.4.15? I have yet to see a Linux open source project of quality comparable
to that POV-Ray when it comes to stability, ease of portability or any
documentation.
The only project close to POV-Ray is Apache, and they have at least one
trillion worth of financial backup in form of every server vendor on the
planet. And their development model is fairly will controlled as well and
taking place in a field that only needs very widespread knowledge you can
learn about everywhere.
Contrary to this, POV-Ray is near the edge of ongoing research, i.e. in
areas of radiosity and photon maps. Obviously the point of entry of new
developers is much higher than that of a webserver or kernel, to offer only
two examples...
> moreover AFAIK many features of pov3.5 came from patches written by people
> not in the povteam, those same people you seem to think they can't bring
> anything interesting. Sure, those patches may need some rewrite, better
The rewrite thingy is the major problem. As outlined above, ray-tracing is
slightly more complicated than a webserver or a kernel. Unfortunately many
people think ray-tracing is as trivial as a webserver, which is far, far
from the truth.
So your argument completely missed the point. If you disagree, ask yourself
why the most recent GPL ray-tracer project (I think it was called Panorama)
failed so early? According to your theory it should have been more
successful.....
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 Thu, 06 Dec 2001 14:34:18 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>In article <3c0f6a1f.6477919@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>> I think that there is some feature missing for that. This is what I'm
>> trying to say in this thread... If U don't think so, please explain me
>> why a program like lightflow (yes I always talk about that renderer,
>> it's only because I know it a bit more than others, don't blame me)
>> that's really new (1 or 2 years old?) developed by a single person,
>
>It was released by that time. Nobody knowns how long the development really
>took!
Well as the developer is 21 years old I think that it couldn't be in
developing for 10 years... Also if U count that he learned coding at
the age of 16 (as he tells in his homepage). Btw who cares? I was
talking about the lack of 3rd party export tools, and for those tools
the only thing that matters is for how long the product has been
around and how easy is to write such exporters for that product...
>> that is NOT opensource at all (not so free) and this is something that
>> should really go against it, I mean if I don't have the sources I
>> don't know the inner-workings, it's lots harder to do an accurate
>> exporter, well, why this program that seems to be so inadeguate for
>> 3rd party development actually already has a working maya and 3dsmax
>> exporter, while noone in 10 years made a good exporter for those
>> super-wide-spread packages with povray... Mabye there is some
>> difference...
>Why? Maybe ecause nobody who uses a free program has the money to buy Maya
>and 3D Studio Max? I, and that much is sure, don't have the money for
>those...
Don't think so, there are many free nurbs modellers too, and if U read
IRTC gallery comments you'll see that many images are done with the
aid of commercial products. Also this would be true if the exporters
for lightflow or for other products that I use where commercial, but
since they are free, I think this is not the reason that makes povray
less attractive to exporter-writers
>On the other hand, if you want to sell a new product that orginally wasn't
>compatible with anything but itself doesn't sell because of that and you
>then take a year to write modules so people (who have money to buy your
>product) can export from their tools to yours, I call that economic
>interest. And I think we both agree that economic interest is a very
>powerful driving force.
Again, we're talking about free exporters made by 3rd part
developers... So this does not apply
> 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 Thu, 06 Dec 2001 14:20:56 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>In article <3c0f635a.4744504@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>> Premature. Now I want to know, are U going to change ray-sphere
>> intersection? Do U see new techniques to do 3d vector cross product?
>> dot product? Matrix-vector product?
>
>No, but neither of those will even benefit a single cycle if you do them in
>hand written assembler. They are too small and linear to offer any improved
>speed. Any instruction scheduler of a reasonable compiler (which are the
>compilers the POV-Team is using) will be better than a human optimizing the
>same code. To the contrary, most compilers have global optimization
>strategies that you effectively kill by adding bits and pieces of inline
>assembler because most compilers won't for good reasons not touch (read:
>optimize) user supplied hand written assembler code...
Well... Actually my asm routines tell me something different... Mabye
you should read something like agner fog asm optimization. Many guys
think that asm is not useful at all for those things... Well, at last
on intel plattform you're really wrong...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > how do you explain the success of others open source projects ?
> Success in what regard? Quality or geek usage?
yes quality, speed of development, reactivity, innovation ..
> What about Linux kernel
> 2.4.15? I have yet to see a Linux open source project of quality
comparable
> to that POV-Ray when it comes to stability, ease of portability or any
> documentation.
(i'm not a specialist of linux world )
hmmm gcc (the gnu compiler) runs on many platforms, or also gtk+ the
graphical toolkit library.. and there are certainly much more
> The only project close to POV-Ray is Apache, and they have at least one
> trillion worth of financial backup in form of every server vendor on the
> planet. And their development model is fairly will controlled as well and
> taking place in a field that only needs very widespread knowledge you can
> learn about everywhere.
i've never looked at apache code but i'm pretty sure building a web server
is not that easy ..
Personnaly i prefer to look at pov source rather than apache source :)
> Contrary to this, POV-Ray is near the edge of ongoing research, i.e. in
> areas of radiosity and photon maps. Obviously the point of entry of new
> developers is much higher than that of a webserver or kernel, to offer
only
> two examples...
you can write simple (yet valuable) patch for povray without knowing
anything about monte-carlo integration
example : i don't think a Ph.D. degree in physical optic is necessary to
write a pattern/shader patch
> The rewrite thingy is the major problem. As outlined above, ray-tracing
is
> slightly more complicated than a webserver or a kernel. Unfortunately
many
> people think ray-tracing is as trivial as a webserver, which is far, far
> from the truth.
actually the basic algorithm of ray-tracing IS trivial , it's when you add
optimisations with octree, light buffer, or more complex physical
simulations such as radiosity, or photon that it gets non-trivial
> So your argument completely missed the point. If you disagree, ask
yourself
> why the most recent GPL ray-tracer project (I think it was called
Panorama)
> failed so early? According to your theory it should have been more
> successful.....
i've never said that *every* open source project is a success (it's clear
that some may fail)
povray is widely used and known , i think that if it was a more open project
(with a core team that verify and commit patches if you want it this way) it
will attract some talented programmers
(well i can understand your opinion.. may be that if i was in pov team the
idea of people coming to ruin my code will scare me too :)))
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 06 Dec 2001 14:29:04 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> team will start the
> devlopment of POV-Ray 4.0 after POV-Ray 3.5 is out.
Without little vacation under sky_sphere ? ;-)
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 <3c0f8a23$1@news.povray.org> , "Mael" <mae### [at] hotmailcom>
wrote:
> hmmm gcc (the gnu compiler) runs on many platforms,
Don't get me started on gcc and its many, many flaws*, just so much: Their
core developers recently (in a discussion about future of development and
supporting IA-64) criticized the many problems they have in their code and
that nobody wants to commit to fix them, but lots of people porting it here
and there. In summary this looks exactly like POV-Ray would be now if all
the people over the years had had their way.
I am not going to comment on any of the other stuff as it is a different
discussion.....
> (well i can understand your opinion.. may be that if i was in pov team the
> idea of people coming to ruin my code will scare me too :)))
It is not about ruining the code, it is about someone having to fix it. And
if the original author doesn't do it the patch has either to be dropped or
fixed by the POV-Team Now, for the people writing a patch that work may be
fun, but once you had to clean up the mess one or (worse) many people have
created you really loose interest and the "fun" part quickly. And remember,
we are doing it for fun, not because of the big paycheck!
Thorsten
* It is a portable C compiler. It is a great C compiler for embedded
development as commercial compilers for embedded systems or usually very
expensive. However, for any serious work outside the embedded world,
especially on desktop or server systems it is unsuitable. A million monkeys
on a million typewriters won't change that.
____________________________________________________
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: Well... Actually my asm routines tell me something different... Mabye
: you should read something like agner fog asm optimization. Many guys
: think that asm is not useful at all for those things... Well, at last
: on intel plattform you're really wrong...
Tell me one thing: For which processor would you make the asm code?
P-II code is optimized very differently from P4 code. Athlon is also another
different story. So which are you going to optimize for?
And what happens when in the future Intel and AMD make new processors which
may require specific optimization (eg. because they are 64-bit)? Your asm
code will be optimized for the old architecture and the new compiler will
be unable to optimize it for the new processor. Are you going to write the
asm code for the new processor?
--
#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
|
|
| |
| |
|
|
|
|
| |
|
|
