Jim Henderson wrote:
> On Wed, 26 Sep 2007 08:57:39 -0400, Alain wrote:
> 
>> Positive point: this simplify things for some peoples. Negative point:
>> this imply several HUGE libraries of premade shapes, textures,
>> environments, models,...
>> Another negative point: Humongous code bloat. How about a 5+ Gb
>> download?
> 
> Bottom line point:  I think it's safe to assume that Bryan was making a 
> joke. ;-)
> 
> Jim

LOL - absolutely.  POV is not about making beautiful images easily. 
It's about empowering people who have no ability to paint or draw to 
make art!


I personally sketch like a 4th grader - and I find that my perceptual 
mind cannot flatten itself to make a 2D image out of what is really a 3D 
object such as a face, a car, a flower, etc.

Just to emphasize: I have never seen a great piece of POVray art that 
could not have been done in far less time by an accomplished painter.

But you're right - I was joking.  Art can never be generalized enough to 
make it like my example.  It it ever did get like that, it would no 
longer be art.

---
Bryan Valencia

- I'd rather live with false hope than with false despair.

Post a reply to this message

Jim Henderson wrote:
> 
> What I want to know is why he only went a 9.5 on sexiness....
> 
> Jim

Because I'm not a big Bo Derek Fan.

-- 
---
Bryan Valencia

- I'd rather live with false hope than with false despair.

Post a reply to this message

On Wed, 26 Sep 2007 13:34:22 -0700, Bryan Valencia wrote:

> Jim Henderson wrote:
>> 
>> What I want to know is why he only went a 9.5 on sexiness....
>> 
>> Jim
> 
> Because I'm not a big Bo Derek Fan.

Well, I wouldn't rate her a 10. ;-)

Jim

Post a reply to this message

On Wed, 26 Sep 2007 15:10:26 -0500, Ger wrote:

> Any value higher then 9.5 could be considered by some as being of a too
> profound sexual nature, and this is still a public access server.

Hmm, that's a fair point. :_)

Jim

Post a reply to this message

>> Shay:
>> All of this would add piles of pages to the documentation
>> (a bad thing), 

> Warp:
 > A bad thing why? You don't have to read those parts of
> the documentation if you don't want to.

Because it will make it more difficult for an average user to find tools 
which may be of critical use to him. There are many great features of 
POV-Ray which a person would never know to look for - luckily the entire 
index of the POV-Ray documentation is still small enough to browse, so 
these features are not "lost."

> Warp:
> You don't have to use  the extra features if you don't want
> to. But why would you want  to remove the extra features from
> people who could create awesome  things with them?

I do want extra features. I don't want to clutter up the SDL with 
shortcuts. I don't want POV-Ray to become the Emacs of renderers. I do 
believe in adding what is absolutely needed for bi-directionality. I 
don't believe that the ability to make pretty subdivision macros or text 
converters in SDL is worth the cost.

"Yes!" to all that is necessary; "No!" to all that is merely convenient.

> Warp:
> Imagine you could write this scene in POV-Ray:
> 
> #include "import3ds.inc"
> import3ds("myscene.3ds");
> 
> And that's it. Nothing more. And the scene renderes beautifully.
> 
> But no, you don't want this. <snip>  When some newbie asks "can I
> convert a 3DS file to povray" you will answer the old same "try
> this converter software which does a half-assed job and might work
> or not".

And by what magic will a converter written in SDL be less half-assed?

> Warp:
 > How would you generate a shader which accesses a data container
> with an external programming language if povray does not support
> that?

from the post to which you are replying:
"Any addition to the procedural part of POV SDL must either be necessary 
to create a scene, ..."

I am not advocating not expanding the language.

> Warp:
> Why keep it needlessly simple<snip>?

If you're going to make a program capable of producing print-quality 
work, then you'll want as many people as possible using the program for 
that purpose. I'm sure you'll agree that there is a point of diminishing 
return...

> Warp:
> What if you wanted to write a shader which, for example, spawns
> additional rays?

...The question is whether such ability lies before or after that point.

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shay wrote:
> I do want extra features. I don't want to clutter up the SDL with
> shortcuts. I don't want POV-Ray to become the Emacs of renderers.

Pov-Ray became the Emacs of renderers a long, long time ago. :-)

God knows that I am not a fan of syntactic sugar, but what Warp is
suggesting is not syntactic sugar. He is suggesting making it *possible*
to do things in Pov that currently have to be done in an ad-hoc way
outside of Pov before/after a render. Unless you run an operating system
Designed The Way Operating Systems Should Be Designed (Unix or Linux),
automating this stuff is a royal pain.

Honestly, that's how I see Pov: an environment for automating and
scripting graphics creation. Take that away, and it's just one of the
many, many raytracing packages out there.

...On the other hand, I will lart anyone who suggests adding a mail
reader to Pov. :-P

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

You know you've been raytracing too long when you find yourself having a
Web surfing cycle of two months: http://www.irtc.org/ is what caused that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+tFecCmTzQ++ZncRAo6IAKCwOohDMToH5zsafymY16Kkkn8REwCZAW0/
P0F4p0ndl6jS5hAwtrEX3RA=
=SEjp
-----END PGP SIGNATURE-----

Post a reply to this message

Bryan Valencia wrote:

> Just to emphasize: I have never seen a great piece of POVray art that 
> could not have been done in far less time by an accomplished painter.

I disagree. Although such images may be *copied* in less time in paint 
(and even faster using a camera), most/all of them would never have been 
created if one were restricted to paint only. The whole process of 
creation is totally different. I am not claiming to create art (I even 
have a letter from the arts committee in our hospital that I don't) but 
I know that for me it is impossible to think in only 2 dimensions. So, 
nothing that I created could have been done with either oil on canvas or 
with photoshop.

Post a reply to this message

I used to use POV because it was what was available. Now I use POV because
it's capable of running standalone, it's fast for many things (compared to
much of the competition), the source is available for modification, and the
SDL is nice and straightforward (although some of the workarounds for
rendering problems aren't).
If any of those change, I would have to switch to another renderer.

For me, the main irritations at the moment are: the speed of parsing
triangle meshes and the rendering defects thereof, plus the lack of a
fully-featured shading language. Not really anything to do with the SDL
itself, although I vote for getting rid of the "#" from declarations as
well.

Tom

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> I 
> don't believe that the ability to make pretty subdivision macros or text 
> converters in SDL is worth the cost.

  What cost? I really don't understand you.

  Let's see that I understand you correctly: You abhor the idea of adding
flexibility features in povray which would allow, for example, creating
subdivision libraries, and the reason for this is that this would cause
some new items to be added to the table of contents of the documentation?

  That just doesn't make any sense at all.

> "Yes!" to all that is necessary; "No!" to all that is merely convenient.

  Well, then let's remove every "convenient" thing there is in povray and
make it as hard to use as possible.

> > But no, you don't want this. <snip>  When some newbie asks "can I
> > convert a 3DS file to povray" you will answer the old same "try
> > this converter software which does a half-assed job and might work
> > or not".

> And by what magic will a converter written in SDL be less half-assed?

  Not by magic. By a community.

-- 
                                                          - Warp

Post a reply to this message

I Think there is some confusion between WHAT we want this new SDL to be and
HOW it will take form and be implemented. It is always prematurate to
answer the second question before aswering (more or less) the first. We
should focus on defining WHAT (and WHY) we want this or that feature.

Here are some questions/suggestions that could concern the 'WHAT' and that
pop up in my mind while typing, maybe some are nonsense:

Meta-features
    Would it be rather script-oriented, programming laguage-oriented, or a
whole development environement?
    Modularity/Reusability/Evolutivity
    Interoperability with other systems/formats
    Distributed render
    Collaborative scene development and repository (POV-forge?)
    Documentation
    Debugger
    Preview of object/textures being defined
    Related Tools?
    .../...

Features
    Keep current POV (+MegaPOV?) features
    Improve some (JIT-compiler for isosurface functions?)
    Add some object types (primitive/compound)?
        MegaPOV's (cloth, mechsim, glow, hdr ...)
        Sub-surface scattering
        Landscape-oriented: terrain, skyscape, clouds, sun, rain, snow, ...
        Vegetation-oriented (tree, ivy, flower, grass, ...)
        Characters/Animals/Organic (articulated=> IK?), skin, cloth, hair
        Fires/smokes/explosions
        Particle system (running liquids, ...)
        .../...
    Built-in object placement
        drop_on (Object),
        stick_on (Object),
        throw (Direction),
        .../...
    Animation features
        Paths
        Morphing (meshes)
        Timelines attached to objects
        Collision detection
        Object breaking/explosion
    .../...

Syntax
    Keep syntax for objects/pigments/... nor far from what it is now
    Rather object-oriented or rather functionnal-oriented?
    Get inspired by existing languages? (for me: yes)
    Compact yet readable
    Specialized 'editor' or only syntax-colored text editor?
    .../...


Perhaps we could imagine a way to collect and formalize ideas and
requirements from the community, and then organize/hierarchize, and then
submit/comment.

Some of us can volunteer to help on this task (like some did for TC-RTC).

A new-SDL comitee can be chosen.

Every one can contribute (stupids/newbies/advanced/gurus).

POV-team as main advisor and decision-maker.

I repeat here at the end of this post: WHAT do we want? The 'HOW' should be
answered later, taking into account technical aspects and feasibility,
development cost, time cost, money cost (we will probably have to provide
the
development team with new tools, docs, aspirin, coffee, therapists or
whatsoever :O))


    Bruno

Post a reply to this message