> 
>   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).

We could imagine this :

- a shading language with it's own syntax (it have to be very
"programmatic"), allowing any algorithm one can imagine

- while, in POV-Ray SDL, existing texture/pigment/normal/finish features
are kept mostly as they are currently, but actually (and transparently 
to user) uses stuff defined in the new shading language.

Each existing pattern, reflection algoritm,... has to be transcribed
in shading language, which would form a huge base of sample code to
start writing new shaders.

Users can limit themselves to existing stuff without re-learning
anything.  Those who'd like to get their hands dirty can do it with
a smooth learning curve.

this would also put all texture-related algorithms out of POV-Ray's main
code, and allow people who aren't high-end programmers to contribute
to an important part of POV-Ray (thus less time spent on it by better
programmers in the re-write process).

(light sources and cameras should also become shaders, ideally, BTW)

note : some years ago, someone made a "POV-Man", which was POV-Ray
with the ability to use RenderMan shaders.  It would be interesting
to find it back and have a look.

Fabien.

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
>
> 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.
>
>   -Shay

As an illustration of that, we can 'pigment' and 'normal' our textures with
user-defined functions. Its is highly embryonic, but it already opens
perspectives for those who can imagine functions. I guess some of you have
obtained nice results.

And in addition, POV's principle of having user-modifiable patterns
(including functions) with color_maps or pigment_maps and many
possibilities for 'finish' is so much flexible that all the stuff produced
so far with POV uses it.

This makes me say that, in a way, POV has already some kind of 'shader
language'.

BUT: we can (it's time to) go much further. A true shader language might
open entire worlds for artists and for those who want to ilmitate nature.
Ideas welcome. Can somebody remind us Renderman's approach of shaders? We
can get inspired by existing solutions.

Bruno

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> - while, in POV-Ray SDL, existing texture/pigment/normal/finish features
> are kept mostly as they are currently, but actually (and transparently 
> to user) uses stuff defined in the new shading language.

  That assumes that they will be as fast as they are currently. If changing
them to use the shading language would make them slower then it would be
a setback.

  The purpose of a shading language is to open new options, not to make
existing options worse (ie. slower).

-- 
                                                          - Warp

Post a reply to this message

In general I think that the object definition syntax of the
current SDL should be preserved.  I also agree that the
addition of additional features would be good, though
command-set bloat should be avoided. My wish list includes...

1) An optional "environment {}" command section where
the command line options for a scene can be placed within
the scene file (like the COBOL environment section).
One objection I've read on this is that letting the
environment (image size, animation options, etc.) be set
from inside the scene file breaks compatibility with the old
system, but it would be easy to get around that by just
adding a "default" setting to quick-rez, if it's rendered with
default it reads environment {} otherwise it ignores it.

2) Better medias. IMO fixing this will eventually lead to
re-defining the syntax for medias, and possibly the need
to resort to scan-line like routines, particularly for things
like sub-surface light scattering.  The upside here is the
possibility of describing the way a media should look,
instead of tweaking commands to the routines that are
supposed to get the look, but often don't.  This matches
the original philosophy of SDL, SDL is a description of
a scene, not a description of the algorithms needed to
render a scene.

3) Binary reading from files.

4) Post processing of images. This could fall under something
like a post_process{} section.  One thing that might be nice
here would be the ability to directly produce animation files in a
couple of formats.

5) Allow the linking of external libraries, so that POV can
access custom programming routines from various languages.

Post a reply to this message

> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> - while, in POV-Ray SDL, existing texture/pigment/normal/finish features
>> are kept mostly as they are currently, but actually (and transparently 
>> to user) uses stuff defined in the new shading language.
> 
>   That assumes that they will be as fast as they are currently. If changing
> them to use the shading language would make them slower then it would be
> a setback.
> 
>   The purpose of a shading language is to open new options, not to make
> existing options worse (ie. slower).

If the shaders are compiled on the fly before rendering (which is, IMMSMW,
what POV-Man did), could they really be slower than hard-coded ones ?

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> If the shaders are compiled on the fly before rendering (which is, IMMSMW,
> what POV-Man did), could they really be slower than hard-coded ones ?

  It assumes that the shaders can be compiled and that the compiler will
be able to optimize them in the same way is the C++ compiler optimizes the
current algorithms written in C++.

-- 
                                                          - Warp

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I'd already raised the issue that I felt that a byte-coded (or JIT'd) back-
> end to any SDL was necessary for speed. If this was exposed and formally
> documented then, firstly, more or less any language could be used with it
> (assuming someone wants to write the translator), and secondly, portability
> is at least vaguely possible by providing a reverse-compiler that outputs
> some form of 'standard' SDL (whatever we end up calling 'standard' is up to
> question of course).

Maybe we need something more POV-Ray specific, but I thought I should bring
this up anyway... Have you heard of the Parrot bytecode[1]?

Languages already supported (even if they are incomplete and experimental):
Perl 6, APL, BASIC, Befunge, Brainfuck, Cola, Forth, Jako, Lisp, m4,
Miniperl, Parakeet, OpenComal, PHP, Plot, Pheme, Punie, Python, Ruby,
Scheme, Span, Tcl (aka partcl), URM, YAL, and Zork Z-code.

[1] http://en.wikipedia.org/wiki/Parrot_virtual_machine

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> C coding with a basic understanding of C++ would probably be sufficient for
> many of the tasks in re-writing the code that has to be replaced. Recall that
> all the POV code was originally c, and the fundamental core of the algorithms
> and objects are still readable by a C programmer.

Please don't let POV-Ray be written in "C plus classes". C++ is so much more
than that! :)

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Thorsten Froehlich wrote:
> > The solution to the parse vs render time limits would be to make all
> > features of a scene object replaceable by the user from within the language
> > - i.e. even replace the intersection algorithm or the transformation
> > computations. That would also put POV on-par with Renderman.
>
> That would be rather neat.

I would like to have *everything* easily changed by tweaking the sourcecode.
Say, make a *totally different* renderer like WinOSI [1] while keeping all
the objects and textures that POV-Ray gives. (WinOSI has some great
lighting but it doesn't even have CSG!).

[1] http://www.winosi.onlinehome.de/

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> andrel wrote:
> > Can someone set something up somewhere?
>
> Can someone recommend specific Wiki software?
>
> It'd need to support external authentication (to link in to the POV user
> registration system), and captchas or other anti-spam measures.
>
> Anyone have any experience with this?

Somebody managed to "link" MediaWiki with BOINC accounts, and even with some
features like if somebody gets banned from the BOINC forum, he can't edit
the wiki either. I think there was also some experiments about making page
editing permission dependent on how much CPU time you had contributed to
the project!
http://pirates.spy-hill.net/glossary/

I can give you the admin's email if you want to.

Post a reply to this message