 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> wrote:
:> The ***trick*** is to use averaged textures with differing normals:
: I think he won that argument, Warp ;-)
Actually I originally used the word "trick" with the meaning "a not so
obvious way of doing it".
: While we are at it, I also noticed you sometimes use the politically
: incorrect term "source code" for what should be called "scene description"
: in your FAQ:
Hmm? I can correct those if you give me some references.
--
#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 6 Dec 2001 11:19:05 -0500, Warp <war### [at] tagpovrayorg> wrote:
>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?
Of course there will always be the plain c code for the processors
that are not supported
For now let's support the most widespread processors
The only real problem with intel 80x86 compatible processors is the
p4, that is really different (and it's really a piece of shit).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: The only real problem with intel 80x86 compatible processors is the
: p4, that is really different (and it's really a piece of shit).
At last we agree in *something*.
--
#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 Thu, 06 Dec 2001 14:50:36 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>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.
you can't compare the stability of a portable os kernel to the
stability of a raytracing program. It's really hard to make it stable,
because of hardware support.
>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.
Of course big development projects have to be steadly controlled. But
I don't think that apache is the only opensource project that is
comparable to povray
>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.
Slightly more complicated? When you write a webserver or a kernel you
have to really care about stability and security issues (expecially if
they are so widespread as apache and linux are), it's very hard to
keep track of all the work. Who cares is a raytracer crashes or if it
has a bug? The next release will fix them... I'm not saying that's ok
to have bugs in povray, I'm just saying that integrating patches in
povray is easier than in linux or apache as you don't have to care soo
much about those problems (noone will kill you for that... :P). There
are many many opensource projects that are more critical than povray,
for example atlas (blas implementation), or openpgp, almost every
linux server... And some raytracers too :P
>Unfortunately many
>people think ray-tracing is as trivial as a webserver, which is far, far
>from the truth.
I'm not experienced with webserver programming, but I don't think it's
a "trivial" task at all.
>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.....
1 fail does not make a law
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0f9af2@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Hmm? I can correct those if you give me some references.
At least in
File Formats
- Saving the image to disk.
I didn't check again, but I remember seeing it somewhere else in there,
too...
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 16:54:38 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
> Who cares is a raytracer crashes or if it
> has a bug?
Admin of render-farm ? Graphician preparing images to print ?
> The next release will fix them...
That's why there is so many Windows...
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 6 Dec 2001 11:43:25 -0500, Warp <war### [at] tagpovrayorg> wrote:
>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>: The only real problem with intel 80x86 compatible processors is the
>: p4, that is really different (and it's really a piece of shit).
>
> At last we agree in *something*.
Yeah, hehe... And most ppl out there will continue buying the new 2ghz
P4... Bleah, well they where not stupid, as most ppl know only of
processor frequency but it's really a pain to code for a p4 and it's
really slow, so I will NEVER support p4 in a project of mine (well
this is not a problem as currently I'm coding in java... :P)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0fa0b2.20451405@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
>>Unfortunately many
>>people think ray-tracing is as trivial as a webserver, which is far, far
>>from the truth.
>
> I'm not experienced with webserver programming, but I don't think it's
> a "trivial" task at all.
It is not hard. And not only that, but there are also plenty of books you
can just open that explain how to write a good server for anything.
>>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.....
>
> 1 fail does not make a law
Indeed, it does not. But the lack of *any* other similar project does.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<abx### [at] babilonorg> wrote:
>On Thu, 06 Dec 2001 16:54:38 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
>> Who cares is a raytracer crashes or if it
>> has a bug?
>Admin of render-farm ? Graphician preparing images to print ?
Mhm, it's more severe a crash of a rendering farm (rendering farm?
povray does not *officialy* support distribuited rendering... well
mabye you was thinking of a screamernet rendering farm :P) or a crash
of a web-shopping server?
>> The next release will fix them...
>That's why there is so many Windows...
So it seems that opensource development is not the problem, as a
commercial program like windows, developed by some of the best coders
around is still buggy... Mabye the problem is that developing an os
kernel really is harder than developing a raytracer...
>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 Thu, 06 Dec 2001 18:07:06 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>In article <3c0fa0b2.20451405@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>>>Unfortunately many
>>>people think ray-tracing is as trivial as a webserver, which is far, far
>>>from the truth.
>>
>> I'm not experienced with webserver programming, but I don't think it's
>> a "trivial" task at all.
>
>It is not hard. And not only that, but there are also plenty of books you
>can just open that explain how to write a good server for anything.
>
>>>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.....
>>
>> 1 fail does not make a law
>
>Indeed, it does not. But the lack of *any* other similar project does.
Well, ok you won on this. In fact I don't know any other decent
raytracer that is opensource.
Mentalray,Lightflow,Brazil,VirtuaLight,Photorealistic
Renderman,Entropy,Lightwave (those are the best renderers that I know
of) are all commercial or closed-source projects
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
