"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

Jim Charter <jrc### [at] msncom> wrote:
> 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'

  Shaders are not inherent to scanline-renderers, even though the vast
majority of shaders are used in scanline-renderers (most notably modern
3D acceleration cards support shaders).

  The idea of shaders is that instead of having a limited set of hard-coded
algorithms for calculating surface texturing (which was the case with older
renderers, older 3D acceleration cards, and closest to home, is the case
with POV-Ray), the engine offers an efficient language which can be used to
add new algorithms used to determine the color of the surface.

  Let's take, for example, the 'finish' block of POV-Ray. While there are
quite many parameters to fine-tune, it's still a fixed amount of possible
parameters. As an example, fresnel reflection is available only because
it has been added to the core code. However, if you would want to test
with some other type of reflection algorithm there just isn't an easy
way (the only way is to modify the source code and recompile the program).

  A shader language allows you to create new types of algorithms to calculate
reflection, or almost anything else related to the surface coloring.

  There are many nice tricks which can be relatively easily achieved with
shaders (which would otherwise require specific hard-coded support in the
core code) such as furry texturing, subsurface scattering, etc.

  Of course it's not like this feature was mandatory for povray, but it
would be nice to have.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Jim Charter <jrc### [at] msncom> wrote:
>> I hit a bump, conceptually, when I see the term 'shader language'.
> 
>   The idea of shaders is that instead of having a limited set of
> hard-coded algorithms for calculating surface texturing <snip>
> the engine offers an efficient language which can be used to
> add new algorithms used to determine the color of the surface.

Just to add a bit to what Warp has said.

A shader language would allow a user of SDL access to more of what 
POV-Ray knows abut a surface, light_source, etc.

An example is the calculation of a specular highlight which requires 
knowledge of the angle of incidence of a light_source to a surface. 
Bringing that information to the user on a ray by ray basis would allow 
for things like:

#if AOI > SomeNumber color_it_this_way #else color_it_another_way

or

pigment { AOI * Something + SomethingElse color_map { ...

A possibly more exciting example to a traditional media artist like 
yourself: You'll be familiar with the concept of shading and tinting 
paint. POV-Ray (effectively) shades colors as they darken, with access 
to the illumination of a ray intersection, you could instead tint colors 
as they lighten.

  -Shay

Post a reply to this message

Warp and Shay, Thanks and thanks.

I think it is always good to expose internal functionality to the 
artists, where possible. I will always remember the creative spurt that 
accompanied the introduction of the trace() and eval_pigment() functions 
which I saw in just that way, as exposing internals to the user.

Post a reply to this message

FYI I will this weekend attempt to get a wiki set up on povray.org.

-- Chris

Post a reply to this message