Mesh2 character animation imaged in povray:
http://pterandon.blogspot.com/2007/10/gmesh-49-animation.html

Blob character animation imaged in povray:
http://youtube.com/watch?v=9AT_7nAr99A

David Buck's pencil imaged in povray:
http://news.povray.org/povray.binaries.images/thread/%3C47ae71f3%40news.povray.org%3E/

David Buck's car imaged in povray:
http://news.povray.org/povray.binaries.images/thread/%3C47ae6a7a%40news.povray.org%3E/

Norbert Kern's trees imaged in povray:
http://hof.povray.org/Boreal_big.html


Q: What created the mathematical constructs that were imaged in povray in each
of these cases?
Q: What do you call creation of mathematical constructs that can then be imaged
in a raytracer?


In the FLOSS podcast, the guys were intrigued about how in the image, "Boreal,"
povray algorithms were used to position all the leaves on the trees. In an
recording addressed to programmers, these programmers were intrigued that
povray could create mathematical constructs that could then be imaged in a
raytracer.

Should you use povray for modeling? Some say no, it's as obtuse as using an axe
to open a can.  There are some scenarios where povray's modeler could be
interesting, if not more efficient, than in a GUI system. For one, you don't
need a good graphics card: blender, on the other hand, won't work with some
live Linux distros because the distro doesn't come with graphics drivers.   For
another, you don't need gobs and gobs of memory:  I opened an "Elephant's Dream"
scene in blender on a 2.0 Gb memory Linux PC and the system slowed to a halt.
You don't need lots of HDD space: I've done more complex objects with a little
SDL modeling with 2-5 kB of SDL that would take MB's of meshes: this can add up
over time. (I've yet to fill up a CD-ROM with a career's worth of SDL modeling).

To say, "Povray is a renderer, not a modeler," inherently limits the imagination
of the users and the number of new users who will want to come to it.  I know
that when I thought it was merely for ekeing out some more exhaustive
photorealism from models created in $$-ware, I wasn't interested.   The
oft-repeated statement is also flatly untrue.

Post a reply to this message

Disclaimer: I do 99% of my work directly in Pov SDL, and I like it that 
way. However, you force me to play the devil's advocate. :-)

gregjohn wrote:
> Q: What do you call creation of mathematical constructs that can then be imaged
> in a raytracer?

"Coding" or "scripting".

> There are some scenarios where povray's modeler could be
> interesting, if not more efficient, than in a GUI system. For one, you don't
> need a good graphics card: blender, on the other hand, won't work with some
> live Linux distros because the distro doesn't come with graphics drivers.

In all fairness, you can get quite a bit done in Blender without 
hardware acceleration if you edit with only the mesh outlines turned on.

> For
> another, you don't need gobs and gobs of memory:  I opened an "Elephant's Dream"
> scene in blender on a 2.0 Gb memory Linux PC and the system slowed to a halt.

And I have seen recursive Povray scenes do the same. :-)

> To say, "Povray is a renderer, not a modeler," inherently limits the imagination
> of the users and the number of new users who will want to come to it.

The issue is not that you can't build scenes with Pov SDL--you can.

The issue is that the word "modeler" usually refers specifically to a 
graphical user interface where shapes can be manipulated in real-time in 
a point-and-click manner. The term implies a certain workflow similar to 
physically modelling an object in, say, clay. If you tell a bunch of 
"mainstream" 3D artists that Povray is a 3D modeller, they will be 
*very* disappointed when they actually see the software.

I might also point out that many Povray users, Linux/Unix-heads in 
particular, do their SDL coding in an external editor. Povray itself 
simply parses that code and renders it.

> I know
> that when I thought it was merely for ekeing out some more exhaustive
> photorealism from models created in $$-ware, I wasn't interested.   The
> oft-repeated statement is also flatly untrue.

If it makes you feel better to say that Povray is a modeler, but not a 
*GUI* modeler, then fine.

I'm not trying to argue against what seems to be your real claim--that 
Povray is useful for creating art without additional third-party 
applications. I'm trying to stop you from being counterproductive. :-)

I've already had similar experiences trying to move people from Windows 
to Linux: You make claims about the software you are trying to "sell" 
that are strictly true, but said claims are misinterpreted, and you wind 
up causing someone to hate the software you are trying to promote ("It 
doesn't work the way he #$%@! said it would!") and possibly even to hate 
*you* for being a "zealot".

Building an image using SDL is a *very* different process from 
interactive modelling, and you need to get that difference across to 
people. You need to communicated the upsides, or they won't be 
interested enough to try it in the first place, and you need to 
communicate the downsides, or they will be disappointed--and they may 
not give you a second chance.

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

These may involve hunting down whoever added whichever thing it is and 
torturing information out of them.
     -- from the GCC Documentation Project's web page

Post a reply to this message

gregjohn <pte### [at] yahoocom> wrote:
> Should you use povray for modeling? Some say no

  Who says no? Saying "povray is not a modeler" is not the same thing as
saying "povray should not be used for modeling".

  In common parlance in the computer graphics community "modeler" means
the same thing as a graphics modeler with a GUI and a real-time preview
of the scene which can be manipulated directly graphically.

  If you are going to call the SDL a "modeler" because of a technicality,
you are going to confuse people. It's not what people understand the word
to mean.

  If you say that the SDL is a "modeler", that's the same thing as saying
that C++ is a "modeler", Haskell is a "modeler" and writing executable
machine code with a hex editor is a "modeler". While you *can* create a
model by writing an executable with a hex editor which will produce the
model, that doesn't make the hex editor a modeler.

  So what if the SDL is not a modeler? Why do you even care? Does that
stop you from creating scenes with SDL? Why does it bother you?

> To say, "Povray is a renderer, not a modeler," inherently limits the imagination
> of the users and the number of new users who will want to come to it.

  If you are going to say "povray is a modeler" you will be effectively
lying, and people are going to get disappointed because they expect a
modeler, which they don't get.

  Assume that POV-Ray was just a C++ library, and to create an image you
would have to write C++ code to create the scene. Would you call C++ a
"modeler" in this case?

  You shouldn't, because it would be wrong. Just because a rendering
library exists for C++ doesn't mean that C++ magically becomes a "modeler".

  If C++ cannot be called a modeler, why the SDL can be? Because it has
a slightly simpler syntax and various shortcuts to do the same things?
There isn't really all that much difference between C++ and the SDL.

-- 
                                                          - Warp

Post a reply to this message

gregjohn wrote:

> Should you use povray for modeling?

1.  Rephrase this as, "Should you use procedural modeling?"

2.  Reflect that Pixar most certainly surely abso****inglutely uses 
procedural modeling when the situation calls for it.

3.  Remember that if your renderer is POV-Ray, using it as the 
implementation language for the procedural modeling eliminates 
difficulties in interfacing your modeling and rendering software.

And you get the obvious response of "why not?"

I used POV-Ray to make the trees in the Petrified Orchard Valley, and to 
position them, to make the height fields for the mountains in the 
background, to make the terrain and trees in other animations, and to 
make and place the stars in the background of those animations with a 
night sky.

Regards,
John

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> 1.  Rephrase this as, "Should you use procedural modeling?"

  "You can perform procedural modeling with POV-Ray" would indeed be a
lot more accurate than saying "POV-Ray is a modeler", which would be
confusing. If someone doesn't understand what "procedural modeling" is,
he can google it.

-- 
                                                          - Warp

Post a reply to this message

> gregjohn <pte### [at] yahoocom> wrote:
>> Should you use povray for modeling? Some say no
> 
>   Who says no? Saying "povray is not a modeler" is not the same thing as
> saying "povray should not be used for modeling".

POV-Ray is a benchmarking tool for multiprocessors systems.  Who needs stinkin'
artists ?

RIP, POV-Ray (1991 - circa 2002), the image-making wonder,
viva POV-Ray (2012 - ...), the arbiter between Intel and AMD.

Given the slow death of IRTC, which no one has the courage to bury once for all,
POV-Ray's clinical death might take long before being acknowledged...

Fabien.

Post a reply to this message

web.47b08e79b78b94b040d56c170@news.povray.org...

> Norbert Kern's trees imaged in povray:
> http://hof.povray.org/Boreal_big.html
>
> In the FLOSS podcast, the guys were intrigued about how in the image, 
> "Boreal,"
> povray algorithms were used to position all the leaves on the trees. In an
> recording addressed to programmers, these programmers were intrigued that
> povray could create mathematical constructs that could then be imaged in a
> raytracer.

The FLOSS podcast was wrong. Norbert used mesh (Xfrog) trees and plants for 
this scene, which is the only way to create large plant populations such as 
these (thanks to mesh instantiation). POV-Ray's algorithms had nothing to do 
with the leaves, or indeed with the plants themselves.

In fact, the points that could be made are a little more complex and 
interesting.

First, Xfrog's method for designing plants is procedural, but it use nodes 
for user input, particularly for the splines and math functions that control 
the shapes and certain behaviours. Of course, the procedural generation 
itself requires something like a gazillion parameters anyway, so that pure 
text-based input would be much impractical.

A second point of interest is that what Norbert invented with the POV-Ray 
SDL for his nature scenes was the planting method. In fact, when I met the 
Xfrog people some years ago, they were really interested in the way we 
(POV-Ray folks) were using the SDL to populate areas with plants, as that's 
an important part of landscape design. Needless to say, any practical 
implementation of that would also require a gazillion parameters, real-time 
previsualisation, and a GUI.

It really should be repeated, again and again, that the script vs GUI 
modelling debate is moot in 2008, and has been so for a while. All high-end 
3D systems (and even specialised software like Poser and Xfrog) include 
scripts or nodes as part of their modelling / texturing / rendering toolset. 
Some stuff is better done with point-and-click mesh/NURBS editing, some 
stuff is easier to do through script or node programming.

G.


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

Post a reply to this message

Gilles Tran <gil### [at] agroparistechfr> wrote:
> It really should be repeated, again and again, that the script vs GUI 
> modelling debate is moot in 2008, and has been so for a while. All high-end 
> 3D systems (and even specialised software like Poser and Xfrog) include 
> scripts or nodes as part of their modelling / texturing / rendering toolset. 
> Some stuff is better done with point-and-click mesh/NURBS editing, some 
> stuff is easier to do through script or node programming.

  But AFAIK in common parlance that means that "renderer X has a modeler
*and* a scripting language for creating objects". Just because renderers
have scripting languages doesn't automatically mean that the scripting
languages are modelers.

-- 
                                                          - Warp

Post a reply to this message

Fa3ien wrote:
> POV-Ray is a benchmarking tool for multiprocessors systems.  Who needs 
> stinkin' artists ?
> 
> RIP, POV-Ray (1991 - circa 2002), the image-making wonder,
> viva POV-Ray (2012 - ...), the arbiter between Intel and AMD.
> 
> Given the slow death of IRTC, which no one has the courage to bury once 
> for all,
> POV-Ray's clinical death might take long before being acknowledged...

harsh words, but with some ringing truth to it...

Post a reply to this message

47b1c875@news.povray.org...
>  But AFAIK in common parlance that means that "renderer X has a modeler
> *and* a scripting language for creating objects". Just because renderers
> have scripting languages doesn't automatically mean that the scripting
> languages are modelers.

The point is that for the user it doesn't matter how it's called. Modern 
modelling applications are big toolboxes with different tools adapted to the 
different tasks.

For instance, for the same model, you will use mesh tools to create some 
shapes, NURBS tools to create others, subpolygonal displacement to create 
details and then the node or script tools to rig the moving parts, turn 
on/off lights, tune the smoke or fire density etc. If you're an architect 
needing parametrizable objects such as doors and windows, you may be able to 
create those objects from primitives using a script that will take specific 
parameters given by the user. There are specialised libraries for any kind 
of modelling task (Xfrog is such a library actually). Really, what is 
discussed here has little relevance to the way 3D is created today. It's a 
completely different world from the 90s when 3D modelling was a young 
industry.

G.

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

Post a reply to this message