Nicolas George <nicolas$george@salle-s.org> wrote:
> But in the scheme I have described, he would be able to write such a
> function in Lua.

  IMO using an existing scripting language (which is radically different
from the current SDL), which has not been specifically fine-tuned for use
with POV-Ray, should only be done as a last resort, if it becomes clear
that there's no manpower or resources enough to create a designed-for-pov
scripting language.

-- 
                                                          - Warp

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> But if there's a propre shading system, there are chances that someone
> someday will write a GUI system like the one described to help designing
> shaders.
>
> Fabien.

Maybe, depends on the shading language (and on POV4's licensing terms,
although if they do use GPL3 then those will not be an issue). In the
meantime folk'll be stuck writing such things in whatever tertiary language
ends up getting used, under the current plans. I suspect this will annoy
some prospective users of v4, since the one thing that people bother to
mention in the new features of the *renderer* rather than the SDL is more
flexible shading capabilities. If they're inaccessible via the SDL, or at
all inconvenient to use, then many people will think, why bother? Mind you
the suggestions I've seen for the new SDL look so different from the
original SDL that maybe the old user base won't bother with v4 at all.

Tom

Post a reply to this message

"Tom York" <alp### [at] zubenelgenubi34spcom> wrote in message 
news:web.4708ba66bcc3cc027d55e4a40@news.povray.org...
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> But if there's a propre shading system, there are chances that someone
>> someday will write a GUI system like the one described to help designing
>> shaders.
>>
>> Fabien.


 If they're inaccessible via the SDL, or at
> all inconvenient to use, then many people will think, why bother? Mind you
> the suggestions I've seen for the new SDL look so different from the
> original SDL that maybe the old user base won't bother with v4 at all.

      That is exactly what I've been thinking. Yes, whatever 4.0 turns out 
to be, I'll give it a go, but if I, (as a PoV layman), can't get to grips 
with it, then I'll humbly (and proudly), carry on using 3.5 and mlPoV.


       ~Steve~



>
> Tom
>
>

Post a reply to this message

Shaders are widely used in game engines.  They quicken the process of 
shading without the accuracy of actual raytracing.

it's a major component in the ability to render 60fps instead of 1fpd.

It's completely out-of place in POV-Ray because:
1. The math is very mesh-centric
2. There are more photorealistic ways to accomplish the same thing using 
radiosity, ambient, and local lighting.

I may be wrong, but how would you mathematically apply a shader to the 
surface of say a blob, or an isosurface?

Post a reply to this message

Bryan Valencia <no### [at] waycom> wrote:
> Shaders are widely used in game engines.

  They are used in all kinds of renderers. 3D hardware just happens to
have their own standardized (but somewhat limited) shader languages.

>  They quicken the process of 
> shading without the accuracy of actual raytracing.

  That's not actually the purpose of shaders. The purpose of shaders is
to offer a more flexible and powerful way of creating surface texturing.
In other words, instead of having a fixed set of hard-coded texturing
algorithms, a more flexible shader language is offered for creating new
types of texturing.

  As I said, shaders are not used exclusively in 3D hardware. They have
been used for quite a long time in many rendering software.

> it's a major component in the ability to render 60fps instead of 1fpd.

  Not really. It's just a major component in getting nice texturing
effects. 3D hardware just happens to support a (somewhat limited) shader
language which you can use to create some nice texturing effects, and
naturally they render it quite fast.

  However, the images do not render fast *because* of shaders (as you seem
to imply). They render fast *regardless* of shaders. The shaders simply
provide nice texturing effects.

> It's completely out-of place in POV-Ray because:
> 1. The math is very mesh-centric

  Incorrect. Shaders are not necessarily at all related to triangle meshes.
I fact, AFAIK, for example renderman shaders are quite independent of the
rendering model used.

  Intersection points, normal vectors, texture colors, etc. are not
dependent on the object type used.

> 2. There are more photorealistic ways to accomplish the same thing using 
> radiosity, ambient, and local lighting.

  You can't achieve everything with those, which you can achieve with
shaders. Besides, shaders can sometimes "fake" things so that they look
convincing but with the advantage of rendering much faster.

> I may be wrong, but how would you mathematically apply a shader to the 
> surface of say a blob, or an isosurface?

  Easily. Everything a shader needs is information about the intersection
point, normal vector, texture, etc. Nothing of this is dependent on the
type of object used.

-- 
                                                          - Warp

Post a reply to this message

Fa3ien wrote:


> 
> (for those who wonders, there's no difference between data and
>  functions, in LISP)

Your death would be a tragic thing.

Post a reply to this message

nemesis wrote:

> But, what really bothers me is that I'm not sure povray artists bother about
> writing their own SDLs just to render a scene.  I'd be interested to see the
> opinion of guys like Gilles Tran, Jaime Vives, Jim Charter, Tek and other
> advanced SDL users...
> 



I'd be happy to comment but I don't understand the question.

Post a reply to this message

Warp wrote:

>   ... very limited and very slow.
> 
>   Also, from core developement point of view, it's quite horrible.
> For example, why do you think there's no eval() function in POV-Ray?
> That is, a function which takes a string and evaluates this string
> as if it was SDL (similar to how an #include "file" would do, but
> with a string instead)?
>   Answer: Because the parser is a mess, full of kludges, burdened with
> backwards-compatibility. For example, #macros are handy and powerful...
> too powerful for their own good. #macros are one of the major reasons
> why there's no eval() function in POV-Ray.
> 
>   Adding new features to the parser is a real pain sometimes (I have
> recent personal experience), mainly due to how the SDL works and is
> parsed. For example, being able to insert a #declare almost anywhere
> may feel handy, but is a nightmare to parse properly.
>   One thing I recently tried to achieve was string concatenation using
> the + operator (as an alternative to the concat function). In the end
> it seems that this would be really, really difficult to implement in
> the current parser due to how interpreting # commands (which can appear
> almost everywhere) works.
> 


Warp, this sort of input helps us all understand the issues better. 
Thanks for this insight.

Post a reply to this message

> Fa3ien wrote:
> 
> 
>>
>> (for those who wonders, there's no difference between data and
>>  functions, in LISP)
> 
> Your death would be a tragic thing.

??? I don't understand well what you mean...

Fabien.

Post a reply to this message

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

Fa3ien wrote:

>> Your death would be a tragic thing.
> 
> ??? I don't understand well what you mean...

I assume he means that there would be a bad reaction to that big of a
change in the SDL.

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

You know you've been raytracing too long when you can't visit most Web
sites anymore because you're tired of cleaning the vomit off your keyboard.
    -- Taps a.k.a. Tapio Vocadlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDPMGcCmTzQ++ZncRArQEAJ4nL/H4RKDd05KrJxQO6ZAVV7tb6wCgo8zi
AAIqNh3LKC/d20NNKrtbEuE=
=pUBB
-----END PGP SIGNATURE-----

Post a reply to this message