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

>>>>> "gregjohn" == gregjohn  <pte### [at] yahoocom> writes:

gregjohn> In an recording addressed to programmers,

That's not strictly the audience.  The audience includes FLOSS users, not just
programmers.  The people I bring to the show tend to be programmers, because
I'm more comfortable interviewing people more like me. :) But as a
counter-example, review the episode with Fernanda Weiden: hardly a mention of
coding at all.

gregjohn> these programmers

Again, while I'm a programmer by trade, Leo certainly is not.  He's a
journalist and broadcaster with a technical passion.  And Leo was the one that
was gushing amazement at the ability for the programming to do such a job.  I
was also amazed, but on a level recognizing how much work it was. :)

gregjohn> were intrigued that povray could create mathematical constructs that
gregjohn> could then be imaged in a raytracer.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer### [at] stonehengecom> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> 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.
>

Amen! I wish everyone who wants to give a 20 word description of povray would
say, "Povray is a renderer.  It is not a GUI modeler, but has tremendous
procedural modeling capabilities in its scripting language."


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

Because I know I have never been interested in eke-ing out the last possible
drop of photorealism possible models made with $$-ware applications. I think
potential users such as myself would turn away from the program if they thought
its only use were such.

Post a reply to this message