Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: But no professional graphician will
: do a scene using those math primitives. Just take any 3d modelling
: program and try to find a perfect sphere primitive... they will output
: a triangle mesh or a nurbs surface... :P
: Of course all the features I added in my wish list where intended to
: make povray a "professional" level raytracer.

  I don't understand why making a program "professional" means in practice
removing 90% of its functionality, devolving it to a degree that no-one can
use it directly.
  POV-Ray supports very fast meshes. What else do you want? Use your bloody
modeller and make all the meshes you want, then render them with povray. What
else do you want?

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

> nowdays everything is modelled with nurbs,
> subdivision surfaces and polygons

All of which get broken down into triangles so graphic accelerators can show
you a fast preview.  If you had ever looked at more than just the absolute
basic parts of POV-Ray you would have noticed blobs, sors and other more
complex object types that are far superior when modeling organic shapes than
any kind/implementation of nurbs.

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

> So such a plugin-modular architecture will only make povray better for
> some plattforms, but you won't notice any difference because, actually
> you just can't add a new shader without recompiling. The point is, if
> U don't complain about this problem now, why should U complain about
> it later? And btw using a modular design, adding shaders will be
> easier with the static-linked-model too. Also if U plan to add a new
> shader every day (but I don't think so, so U should not recompile pov
> so often) you can just do an incremental build, and U won't spend
> 15-20 minutes every time...

If you had ever looked at the source code you would know that it is fairly
modular (well, as modular as a 1980s C program could be)...

    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 <3c0e86ee@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> : speed==quality
>
>   You still haven't explained this. What the h*** has speed to do with image
> quality?

I think his idea is that a good raytracer should be faster at a potentially
lower quality of the resulting image; contrary to POV-Ray's philosophy of
allowing (optional) maximum quality at the any expense of render time.  Of
course POV-Ray isn't like BMRT, so such a suggestion is pointless as the
resulting program would no longer be POV-Ray and that is why it doesn't make
sense to you (nor does it make much sense to me, my explanation is only a
guess)...

    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 Wed, 05 Dec 2001 22:10:48 +0100, Thorsten Froehlich wrote:
> In article <3c0e86ee@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
> 
>> : speed==quality
>>
>>   You still haven't explained this. What the h*** has speed to do with image
>> quality?
> 
> I think his idea is that a good raytracer should be faster at a potentially
> lower quality of the resulting image

I think he's saying that the faster the raytracer, the more image quality 
you can get in a given amount of time.  For example, if POV were twice as
fast, you could crank down the AA threshold a bit and still keep a comparable
render time.

But then, I'm not reading his posts as Vanna has stopped selling me vowels
to go with them.

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

On 5 Dec 2001 15:31:00 -0500, Warp <war### [at] tagpovrayorg> wrote:

>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>: Because it seems that ppl here don't like the idea...
>
>  Who doesn't like the idea?
>
>  What people don't like is the idea of replacing *everything* with tesselated
>meshes.
>  Tesselating has its uses, but it should be *optional*. And optional in
>a per-object basis.
Well, if U want to keep the normal object and add a jolly-good support
for tesselated meshes, that's really fine!!! :))

Post a reply to this message

On Wed, 05 Dec 2001 22:00:08 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>In article <3c0e7c89.599326@news.povray.org> , ken### [at] uniplanit (Angelo 
>'kENpEX' Pesce) wrote:
>
>> nowdays everything is modelled with nurbs,
>> subdivision surfaces and polygons
>
>All of which get broken down into triangles so graphic accelerators can show
>you a fast preview.  If you had ever looked at more than just the absolute
>basic parts of POV-Ray you would have noticed blobs, sors and other more
>complex object types that are far superior when modeling organic shapes than
>any kind/implementation of nurbs.

I'll reply to you and to warp here, about this question...
You're really, really, really, really wrong if U think that organic
shapes or anything above amatorial level graphics is made with such
primitives. I know that there are many *FINE* images done with that
stuff. I agree that there are many *FINE* artists that use that tools.
But this is not what high-end graphician want. Why? I can tell you
why...
Such primitives are impossible or really difficoult to animate, are
really difficoult to control and require too much time, experience and
experiments to get them look right. If U don't have any schedule you
can affod doing a fine image with only spheres, but if so U can even
do an image with an hex-editor... The main mistake between what I say
and what many ppl here think is that we are thinking of two different
scenarios. I want to say it again, I'm not saying that IRTC artists
are lame or something like that. In fact, if you're really trying to
make some art, it does not matter how do U make it, and my favourite
3d artist (not modeller not graphician, artist) is gilles Tran, who as
you will surely know, is a povray user. What I'm trying to say is that
povray could be well suited for high-end gfx too if someone will add
support for a few things...
Now, again about primitives. You can think everything you want about
this, but I can tell you that 99% of the organic models in high-end
gfx is made with nurbs or subdivision surfaces (subdivision surfaces
are "new", mhm no they are not "new" but only recently they have seen
implementation in 3d modellers, and they are really better than
nurbs). Having a raytracer without support for those stuff is really a
mistake imho, supporting this stuff means more or less supporting
tesselated meshes (I know that it's possible to raytrace nurbs
directly but I think it's slow), that's why most of high-end
raytracers (where for high-end I mean something that's used in real,
professional, productions) just support triangle meshes...
Of course supporting both stuff will not hurt at all... :)

Post a reply to this message

On Wed, 05 Dec 2001 22:01:00 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>In article <3c0e7d94.866669@news.povray.org> , ken### [at] uniplanit (Angelo 
>'kENpEX' Pesce) wrote:
>
>> So such a plugin-modular architecture will only make povray better for
>> some plattforms, but you won't notice any difference because, actually
>> you just can't add a new shader without recompiling. The point is, if
>> U don't complain about this problem now, why should U complain about
>> it later? And btw using a modular design, adding shaders will be
>> easier with the static-linked-model too. Also if U plan to add a new
>> shader every day (but I don't think so, so U should not recompile pov
>> so often) you can just do an incremental build, and U won't spend
>> 15-20 minutes every time...
>
>If you had ever looked at the source code you would know that it is fairly
>modular (well, as modular as a 1980s C program could be)...
Yep. So you can agree that it will not be a big mistake if a support
for dynamic module loading is added, where possible...

Post a reply to this message

On 5 Dec 2001 16:15:10 -0500, Ron Parker <ron### [at] povrayorg>
wrote:

>On Wed, 05 Dec 2001 22:10:48 +0100, Thorsten Froehlich wrote:
>> In article <3c0e86ee@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
>> 
>>> : speed==quality
>>>
>>>   You still haven't explained this. What the h*** has speed to do with image
>>> quality?
>> 
>> I think his idea is that a good raytracer should be faster at a potentially
>> lower quality of the resulting image
>
>I think he's saying that the faster the raytracer, the more image quality 
>you can get in a given amount of time.  For example, if POV were twice as
>fast, you could crank down the AA threshold a bit and still keep a comparable
>render time.
>
>But then, I'm not reading his posts as Vanna has stopped selling me vowels
>to go with them.
This is actually the point. Again, I'm thinking about povray as a
renderer that professional 3d gfxers can work. Now such a gfxer, that
has to finish a project in a tight schedule, can't wait a night for
every rendering. And is this is slightly possible for still images,
for animations speed is really really equal to image quality as you
know that you'll have only a fixed amount of time per frame (for
example, 3 mins) for rendering, and then you have to adjust your scene
complexity to fit this requirement... Now, I'm not telling you, remove
quality from povray!!! This is stupid. I'm not telling you make a bad
renderer, the only thing that means to me is speed... But I'm trying
to say that if I have to spend x hours to add a new fancy quality
option (for example, a new caustic method that is hard to implement
and boosts quality in almost no image at the expense of a lot of
rendering time), mabye this time can be re-invested into optimizing
povray... It's only a matter of priority, it seems to me that povray
is focusing a lot into adding fancy rendering options (ok, but tell me
what movie you've seen with radiosity and caustics... again I have to
tell that most stuff is made with photorealistic renderman, a tool
that is not capable of doing correct reflections!!! Why??? Because
most people believe that they can live even without this stuff, if
without it I can have a blazing fast render that lets me use a 10mb
nurbs model in my scene) and not into optimizing rendering speed...

So again, quality is good, but who cares about blurred reflections and
distribuited raytracing with radiosity and photonmapping, if I can
apply it only to spheres???

Post a reply to this message

On 5 Dec 2001 15:47:23 -0500, Warp <war### [at] tagpovrayorg> wrote:

>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>: But no professional graphician will
>: do a scene using those math primitives. Just take any 3d modelling
>: program and try to find a perfect sphere primitive... they will output
>: a triangle mesh or a nurbs surface... :P
>: Of course all the features I added in my wish list where intended to
>: make povray a "professional" level raytracer.
>
>  I don't understand why making a program "professional" means in practice
>removing 90% of its functionality, devolving it to a degree that no-one can
>use it directly.
Read my previous post... I'm not telling you to remove anything, just
to switch the priority list...

>  POV-Ray supports very fast meshes. What else do you want? Use your bloody
>modeller and make all the meshes you want, then render them with povray. What
>else do you want?
Meshes are really not enough... At least I should have nurbs surfaces
(yep it's different, as having direct nurb support in the renderer
means that it will adjust tessellation adaptively, I can't
retessellate my model every frame if it's near or far from the
camera...)

Post a reply to this message