![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Wed, 31 Jul 2002 19:11:36 +0200, "Gilles Tran" <tra### [at] inapg inra fr> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <dcjlkus5pqib9qki580u4062matoh3atbl@4ax.com>,
ABX <abx### [at] babilon org> wrote:
> On Wed, 31 Jul 2002 19:11:36 +0200, "Gilles Tran" <tra### [at] inapg inra fr> 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] mac com>
POV-Ray TAG e-mail: chr### [at] tag povray org
TAG web site: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
3D5### [at] comtrade ee...
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |