While it is a point somewhat related to a few already mentioned, I would
add that Pov-Ray runs on many operating systems and platforms where
alternatives often do not.

Post a reply to this message

On Wed, 31 Jul 2002 19:11:36 +0200, "Gilles Tran" <tra### [at] inapginrafr> wrote:
> Disadvantages
> - requires basic programming/scripting talent

disadvantage ? it is the most funny thing for some :-)

> - raytracing is still too slow for professional animation purposes

watching can be considered as type of meditation

> - no native support for usual industry 3d file formats ; script not readable
>   by other apps

I agree about import but is script export so important ? so often repeated
'POV is raytracer not modeler' suggest the way how files should flow :-)

> - no native support for advanced modelling/animation features like inverse
>   kinematics or particle systems

yes

> - no native support for advanced shading, like cell shading or subsurface
>   scattering.

I hope there is some knowledge in community and we can wait for some patches
around it.

ABX

Post a reply to this message

in news:dcjlkus5pqib9qki580u4062matoh3atbl@4ax.com ABX wrote:

>> - raytracing is still too slow for professional animation purposes
> 
> watching can be considered as type of meditation
> 

And your boss accepts that excuse ?
;)

Ingo

Post a reply to this message

I was shocked to hear ABX say:

>watching can be considered as type of meditation

Not when you turn on 3 area lights and focal_blur.  Then it's actually
painful to watch.  Well it is on my comp anyway (PII 350, I gotta
upgrade, but I need to find a job first).

- Tim

Post a reply to this message

In article <dcjlkus5pqib9qki580u4062matoh3atbl@4ax.com>,
 ABX <abx### [at] babilonorg> wrote:

> On Wed, 31 Jul 2002 19:11:36 +0200, "Gilles Tran" <tra### [at] inapginrafr> wrote:
> > Disadvantages
> > - requires basic programming/scripting talent
> 
> disadvantage ? it is the most funny thing for some :-)

That it requires it? Yes, that is a definite disadvantage. Fortunately, 
it is fairly easy to learn.


> > - raytracing is still too slow for professional animation purposes
> 
> watching can be considered as type of meditation

Most people don't get paid to meditate...


> > - no native support for usual industry 3d file formats ; script not readable
> >   by other apps
> 
> I agree about import but is script export so important ? so often repeated
> 'POV is raytracer not modeler' suggest the way how files should flow :-)

"importing" isn't a problem, it is quite easy to automatically write POV 
script. The problem is finding tools to do so. It would be nice if some 
of the more standard formats were supported directly, though. It's just 
a lot of work to implement...

Agreed about export...it just isn't needed much.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

dcjlkus5pqib9qki580u4062matoh3atbl@4ax.com...
> watching can be considered as type of meditation

I once stayed an hour in front of the screen watching the render progress.
After a while people started poking me in the ribs because they thought I
was dead.
It's certainly a mystical experience, but it's bad for private life.

> I agree about import but is script export so important ? so often repeated
> 'POV is raytracer not modeler' suggest the way how files should flow :-)

I don't think that's important either for today's Povray users, but I can
see that in a production environment people could be interested in Povray's
scripting abilities and still want to be able to render the created scene in
another app.

> > - no native support for advanced shading, like cell shading or
subsurface
> >   scattering.
> I hope there is some knowledge in community and we can wait for some
patches
> around it.
The problem with the current implementation is that it's done by adding
features and therefore it tends to create a bloated SDL with lots of more or
less stable and meaningful keywords, as we've seen in Megapov. I really
liked Vahur Krouverk's Povman and its implementation of Renderman shaders
because it opens lots of opportunities, even though writing shaders is
definitely something for programmers. Now, in 3.5, we have uvmapping and the
possibility of tweaking functions to create patterns, but the manipulation
of finish and interior properties has limitations that still make difficult
the rendering of common real-life effects, such as blurred translucency.
This question would be better solved by a shader approach than by adding
keywords... particularly since there are many shaders already available.

G.

Post a reply to this message

Gilles Tran wrote:
> 
> I once stayed an hour in front of the screen watching the render progress.
> After a while people started poking me in the ribs because they thought I
> was dead.

:-)

> The problem with the current implementation is that it's done by adding
> features and therefore it tends to create a bloated SDL with lots of more or
> less stable and meaningful keywords, as we've seen in Megapov. I really
> liked Vahur Krouverk's Povman and its implementation of Renderman shaders
> because it opens lots of opportunities, even though writing shaders is
> definitely something for programmers. Now, in 3.5, we have uvmapping and the
> possibility of tweaking functions to create patterns, but the manipulation
> of finish and interior properties has limitations that still make difficult
> the rendering of common real-life effects, such as blurred translucency.
> This question would be better solved by a shader approach than by adding
> keywords... particularly since there are many shaders already available.

I agree that shaders are a great addition to POV-Ray's texturing
possibilities, but i don't think they could be a replacement.  With
POV-Ray's current abilities you can achieve a lot of things that would
take even an experienced shader programmer quite some time.  Of course the
possibility to use the intersection information for the resulting color is
a great advantage of shaders.  

I did not look into the 3.5 source yet, but i guess using functions for
finish manipulation should be possible without fundamental changes, making
trace() etc. available in functions would be a great improvement too. 
With these blurred translucency and anisotropic highlights would no more
be beyond the scope of POV-SDL.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 15 Jul. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

3D4B9F18.B1CC85DF@gmx.de...
> I agree that shaders are a great addition to POV-Ray's texturing
> possibilities, but i don't think they could be a replacement.

Obviously. As I said, programming shaders is something for programmers or at
least very advanced users. The regular way of doing things in Povray works
well enough for most tasks. The ability of reading shaders would be a plus,
and a facility for regular users (who would not have to learn the shading
language to use them of course). What amazed me with Vahur's implementation,
even limited as it was, is that it expanded greatly Povray's abilities
without overloading the SDL, thus making things more simple.

> I did not look into the 3.5 source yet, but i guess using functions for
> finish manipulation should be possible without fundamental changes, making
> trace() etc. available in functions would be a great improvement too.
> With these blurred translucency and anisotropic highlights would no more
> be beyond the scope of POV-SDL.

Sounds great. A more general approach like this should be preferable to the
"hey I'm going to implement this little cool function and add a few more
keywords" that was prevalent in Megapov patches. That was nice enough of
course (and fun to implement for the programmers), but not so valuable in
the long run.

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Gilles Tran wrote:
> The problem with the current implementation is that it's done by adding
> features and therefore it tends to create a bloated SDL with lots of more or
> less stable and meaningful keywords, as we've seen in Megapov. I really
> liked Vahur Krouverk's Povman and its implementation of Renderman shaders
> because it opens lots of opportunities, even though writing shaders is
> definitely something for programmers.

You don't have to write shaders. It is sufficient, if there is someone, 
who can write. Or one can use some visual tools to compose shaders and 
let machine to do everything other. I browsed caligari newsgroups and 
found pretty impressive shaders for TrueSpace, created with visual 
composing program ShaderMagic (http://software.gallo.sk/shadermagic/). 
With such tool one can play like with lego. And there are similar tools 
for RenderMan shaders (e.g. Puzikov's ShaderMan 
http://www.dream.com.ua/thetool.html).
Oh, those impressive shaders for TrueSpace fake subsurface scattering 
and global illuminance, great interest topics here some time ago. Some 
examples:
http://forum.caligari.com/discus/messages/1585/8423.html?1028518917
http://www.geocities.com/herbie_west/shaders.html
http://forum.caligari.com/discus/messages/1585/8091.html?1027695614
http://forum.caligari.com/discus/messages/1585/7545.html?1022101597

Post a reply to this message

3D5### [at] comtradeee...
> You don't have to write shaders. It is sufficient, if there is someone,
who can write.

Yes of course. What I meant is that with the regular povray texture model
anyone can create textures, even complex ones.  With shaders, most people
are dependent on other people's shaders because they're too complex to
create (you really need to understand the theory behind). I know this in
Bryce, for instance, where there's an engine to create shaders that 's quite
powerful but much too hard to use for regular users. Of course, in the event
of Povray RM shaders, we'd keep the regular Povray textures so we'd get the
best or both worlds...

G.

--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message