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

"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote in message 
news:web.46fbd573e7dc7428e8ba46670@news.povray.org...

<snipped but read with enthusiasm>

   Excellent post Bruno! That brought it all together for *me* as it was 
getting a little confusing!   ;)


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


   If there's any modelling that needs doing, I'm all for it. I think I'm 
getting to be a dab-hand with Wings now, (and so are others, I've noticed), 
and I know I can do what's asked for.

    Anyway, I'm here if needed, no problem.

      ~Steve~




>    Bruno

Post a reply to this message

Le 27.09.2007 18:41, St. nous fit lire :
> "Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote in message 
> news:web.46fbd573e7dc7428e8ba46670@news.povray.org...
> 
> <snipped but read with enthusiasm>
> 
>    Excellent post Bruno! That brought it all together for *me* as it was 
> getting a little confusing!   ;)
> 
> 
>> Every one can contribute (stupids/newbies/advanced/gurus).

I'm always afraid of "designed by committee"

http://en.wikipedia.org/wiki/Design_by_committee

pov SDL is not that orthodox (a little bit more of absolut orthodoxy
in its concept could really help the learning curve of beginners),
but I have always ponders that issue with backward compatibility.

If I was to change the parser and the data structure, I would limit
myself to make the same capability for finish than for normal and
pigment, and drop the texture. And change the model for color
(separating filtering pigment from ray-data, so as to be able to
process ray's color with a matrix [changing the wavelength when
hitting a surface, in any way you can thing of]) to an open-model
which could play Grey-only, RGBa, as well as discret spectrum (or
anything you can thing of).


All the details at http://jgrimbert.free.fr/crayon.pdf
(in french, have a look at the UML if you cannot read it...most
complex is on page 40.)

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

Warp wrote:

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

The point on which we disagree is the nature of convenience or 
usability. The relationship between feature expansion and usability has 
been argued a thousand times - there's no point in continuing to repeat 
it. If you think a large expansion of the (already buggy) procedural 
portion of POV SDL is the most convenient (to users) way to accomplish a 
job like format conversion, then so be it. I think you're nuts. I say, 
learn a little Perl (that's what it's there for), or even better, 
hard-code format conversion into the POV source code. I guess that 
sounds nutty to you.

  -Shay

Post a reply to this message

Warp wrote:
Warp, thanks for the well thought out and measured set of suggestions.
   If nothing else you put the discussion on a more organized plane with 
a good marriage
of abstract concepts and specific examples




> 
> #macro M(a, b)
>   , a, b>
> #end
> 
> sphere { <1 M(2, 3), 4 }
> 
>   This just doesn't fit in for byte-compiled code (at least not with very,
> very ugly hacks which would only burden and slow down the VM interpreting
> the bytecode).
>   The vast majority of #macros out there already work as pure functions,
> though, so only the "ugliest" ones would break.

I gotta laugh, naturally *I* do those sorts of ugly things all the time. 
  But hey, I wince when I do it.  Guess I could live with a little more 
enforced rigor.
( I usually find I reach for the #macro command and get into that kind 
of trouble when I am looking for some way to introduce rand() into the 
works. But I digress)




> 
> * Existing data containers, namely arrays and strings (which are special
> arrays of characters), should be enhanced and new data containers introduced.

> For example the current array could be internally implemented as a C++ deque,
> which would make it work like the current one plus you can freely resize it
> (larger or smaller), append elements at the beginning and at the end, and
> you can still access any element fast, and none of these operations will be
> slow (eg. resizing does not require copying/moving any existing elements).
> Even inserting or removing elements from the middle of the array would be
> possible, although it would not be a constant-time operation.
>   Strings could also be internally implemented as C++ strings. This would
> also allow easy resizing and appending. Also any byte values should be
> supported so that strings could also be used as raw byte arrays (for example
> for reading and writing files in binary mode). More operators and functions
> for accessing and manipulating strings should be added.

That would be *Wonderful!*




> 
>   Some syntactical technique should be introduced which would allow handling
> and accessing other types of data containers as well, such as lists and
> sets (balanced binary trees). Using the same idea as with C++ iterators for
> this could be one possibility. This would allow offering the C++ data
> containers at the SDL level.

Over my head but still sounds great.  What I like about Python, what 
ever its weaknesses, is the easy string handling.


> 
> * The language should be enhanced in such a way that you can create your
> own (efficient) data containers. For this it may be necessary to introduce
> the concept of modules (ie. classes without inheritance) or classes (with
> perhaps a simple inheritance support) and references. These modules or
> classes could have member variables and perhaps even member functions.
> Accessing the elements could be done with the dot operator.

Over my head, but if it would keep the heavy tech boys interested, I'm 
all for it.  We need to keep you guys interested.


> 
> * Many of the existing features of the current SDL, such as the camera,
> global_settings, etc, could be enhanced to behave like such modules/classes.
> For example, I envision this kind of code being possible:
> 
> #if(global_settings.max_trace_level < 10)
>   global_settings { max_trace_level 10 }
>   // or alternatively: global_settings.max_trace_level = 10
> #end
> 
> #declare CameraAngle = camera.angle;
> 
>   Perhaps even objects could behave like modules/classes like this, so
> you could do something like:
> 
> #declare S = sphere { 0, 1 };
> #declare R = S.radius;
> 
>   This could be especially useful for writing SDL libraries which modify
> triangle meshes (eg. subdivision, smoothing...)

This would be great.


> 
> * There should be support for binary reading and writing of files (into
> strings, which have been enhanced to support raw byte data). Maybe other
> methods of reading and writing files could be introduced as well (in order
> to make it easier to write file format parsers).
> 
> * If possible, introduce alternative ways of handling identifiers/variables
> so that all of these lines are valid:
> 
> #declare Var = Var + 1;
> Var = Var + 1;
> #declare Var += 1;
> Var += 1;

Could make for a debugging nightmare... Gestalt psychology, training the 
'eye' and all that. Your eye is used to C++ so naturally you would like 
to gravitate there.  I find the limited, though admittedly cumbersome, 
POV look reassuring when I am about to tackle reams of code looking for 
my one typo. But then again, most of us shift between languages where 
that other syntax is supported so it may be a lame concern on my part.


> 
> * The most difficult thing of all: Some kind of shader language, and deciding
> if this will be a completely separate language from the SDL (in the same
> way as current user-defined functions are) or if it will be the same.
> Perhaps a limited set of the SDL itself could be used as a shader language
> (for example a shader would be a macro/function which takes certain
> parameters and only uses a subset of the whole SDL, and which has access
> to certain special functions not accessible normally; the parser would check
> that this is so).
>   Ideally such shader function could do things like trace additional rays,
> read information from objects, textures, etc.
> 

Since we are undertaking the conversation.  I would enjoy having you 
sketch this out a little more.   I hit a bump, conceptually, when I see 
the term 'shader language'.  I am not really sure what it means in 
relation to the texturing that POV uses.  You are usually pretty good at 
sorting out these kind of semantic/conceptual tangles for us that are 
less technical.  For instance I thought that 'shader language' went 
along with 'scanline rendering'


-Jim

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> Warp wrote:
>
> >
> > Well, then let's remove every "convenient" thing there is in povray and
> > make it as hard to use as possible.
>
> The point on which we disagree is the nature of convenience or
> usability. The relationship between feature expansion and usability has
> been argued a thousand times - there's no point in continuing to repeat
> it. If you think a large expansion of the (already buggy) procedural
> portion of POV SDL is the most convenient (to users) way to accomplish a
> job like format conversion, then so be it. I think you're nuts. I say,
> learn a little Perl (that's what it's there for), or even better,
> hard-code format conversion into the POV source code. I guess that
> sounds nutty to you.
>
>   -Shay

I have to say I like the direction Warp wants SDL to go...  Most of my POV
coding is in the procedural portion and there are a lot MORE things I'd
like to be able to do directly in SDL. That's what makes POV-Ray useful to
me as opposed to *having* to turn to external things.  The idea of making
source SDL which is usable to anybody who has POV-Ray is appealing.  When a
project starts to require multiple languages, the number of people who'll be
able to use it starts to drop.

My thinking and my hope for in an updated SDL are largely what Warp
mentioned.  Specifically, more use of the dot operator (even adding .xy
..xyz etc to for vectors), user definable data structures again with more
use of dot operators, more control, i/o for arbitrary binary files, and
better string manipulation.

One really specific thing I'd like:  The currently-'experimental' but often
used feature, splines, I think would benefit from a new syntax - I think
that splines
should be treated as a basically/almost-normal array of 4d vectors.
MySpline(Value) would return a 3d vector point along a spline like is done
now.  MySpline[Value] would return a 4d vector control point of the given
array-position in the form <x,y,z,t> where t is the float-position along
the spline's length.  MySpline[Value].xyz would return a 3d version of the
control point. Transformations would apply to all values on the 'spline
array' except for the t values unless specifically called for by use of dot
operators.

Charles

PS (Woohoo! I was able to log on today from home with my high latency
connection!)

Post a reply to this message

"Charles C" <nomail@nomail> wrote:
> Shay <Sha### [at] cccc> wrote:
> > Warp wrote:
> >
> > >
> > > Well, then let's remove every "convenient" thing there is in povray and
> > > make it as hard to use as possible.
> >
> > The point on which we disagree is the nature of convenience or
> > usability. The relationship between feature expansion and usability has
> > been argued a thousand times - there's no point in continuing to repeat
> > it. If you think a large expansion of the (already buggy) procedural
> > portion of POV SDL is the most convenient (to users) way to accomplish a
> > job like format conversion, then so be it. I think you're nuts. I say,
> > learn a little Perl (that's what it's there for), or even better,
> > hard-code format conversion into the POV source code. I guess that
> > sounds nutty to you.
> >
> >   -Shay
>
> I have to say I like the direction Warp wants SDL to go...  Most of my POV
> coding is in the procedural portion and there are a lot MORE things I'd
> like to be able to do directly in SDL. That's what makes POV-Ray useful to
> me as opposed to *having* to turn to external things.  The idea of making
> source SDL which is usable to anybody who has POV-Ray is appealing.  When a
> project starts to require multiple languages, the number of people who'll be
> able to use it starts to drop.
>
> My thinking and my hope for in an updated SDL are largely what Warp
> mentioned.  Specifically, more use of the dot operator (even adding .xy
> ..xyz etc to for vectors), user definable data structures again with more
> use of dot operators, more control, i/o for arbitrary binary files, and
> better string manipulation.
>
> One really specific thing I'd like:  The currently-'experimental' but often
> used feature, splines, I think would benefit from a new syntax - I think
> that splines
> should be treated as a basically/almost-normal array of 4d vectors.
> MySpline(Value) would return a 3d vector point along a spline like is done
> now.  MySpline[Value] would return a 4d vector control point of the given
> array-position in the form <x,y,z,t> where t is the float-position along
> the spline's length.  MySpline[Value].xyz would return a 3d version of the
> control point. Transformations would apply to all values on the 'spline
> array' except for the t values unless specifically called for by use of dot
> operators.
>
> Charles
>
> PS (Woohoo! I was able to log on today from home with my high latency
> connection!)

Well, I consider all these features as being 'low_level' and 'detailed
design'. If we say that the new SDL will be more or less object-oriented,
we involve most of those features you and others have mentionned.
Object-orientedness can be implemented in quite a heavy way (eg Java, Ada),
or more 'light'. But in any case we have the dot operator, structures,
modules + visibility rules, attributes & methods etc .. etc ...

My opinion is that we have to make higher-level and main orientations
choices now before anything else. Some people are capable of envisionning
high levels of a system, some can extract general features from a messy
list of collected requirements of all kinds (there are structured methods
for that), etc ...

It is important to me that we have to focus on 'WHAT' (and why) rather than
'HOW'.

And my feeling is that the new SDL should be object-oriented yet
user-friendly and inherit POV syntax for what POV is VERY efficient for:
describing objects and textures.


Bruno

Post a reply to this message