 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Some of these are things I have discussed years ago, but I thought it
could be useful to revive the discussion a bit.
One of the original plans for POV-Ray 4 was to make a complete rehaul
of the SDL from scratch, making it a lot more versatilve, expressive,
powerful and faster (via byte-compilation). This would have been a
completely new input language that's different from the current one
(but with, perhaps, a backwards compatibility mode to support existing
scene files.)
I have no idea what the current plans are, but I have the impression
that the idea of this kind of complete overhaul has been pretty much
scratched, in favor of simply enhancing the current SDL. (If I'm wrong,
I'd love to hear about the current development ideas on this.)
If we are simply going to keep the current SDL and enhance it, rather
than create a completely new input language, perhaps a kind of in-between
solution could be possible.
I really think that the enhancements made to the SDL should use the same
design principle as what happened with graphics accelerator cards.
In the late 90's and very early 2000's, when graphics accelerator cards
were becoming more and more popular, and were becoming more and more
advanced, the manufacturers were doing the same thing as the POV-Ray
SDL has been doing: Piling up individual hard-coded features one on
top of another. Basically everything that graphics cards supported at
the time were such individual hard-coded, inflexible features (such
as lightning, bump maps, vertex transforms, etc.)
Quite soon, however, graphics card manufacturers realized that this is
a completely infeasible design. It needlessly limits what games can do,
it makes the graphical options limited and very rigid, and it stifles
the game developers' options. New graphical effects can't be added to
the game if the graphics card doesn't directly support it.
Thus they went into a rather different direction: Rather than add more
and more fixed features, they instead concentrated their efforts in
implementing an expressive fully-fledged efficient machine code, which
could be run on a vertex-by-vertex and on a pixel-by-pixel basis
(namely, vertex and pixel "shaders"). This machine code could be given
data and parameters both by the running program and the graphics card
itself, and it could do whatever calculations with them (and pass that
data from the vertex shader to the pixel shader as needed) which would
affect the coloration of the final pixels.
Thus, for example, rather than add yet another type of rigid, fixed form
of, say, bump mapping, this machine code system would allow the game
developers to implement their own freely customized version. (This
freely-implementable "bump mapping" could even be algorithmically
generated and even animated, if so desired. There is basically no limit.)
This design has been highly successful. Rather than spend time and effort
on fixed features, they have spent that time and effort in making the
machine code system more efficient and even more flexible. (This is such
a crucial feature of current graphics cards that their prowess is pretty
much solely measured in how many shader operations per second they can do.)
Now, I'm not saying that POV-Ray should implement a "shader" language
that can do absolutely anything (although if well designed and implemented,
that would be great). However, I think that future expansion of the
current SDL should, in my opinion, at least go more into that direction.
A concrete example: I have suggested in the past a new feature for POV-Ray:
A kind of "poor man's blurred reflection" system, where the reflection on
a surface is the more faded the farther away the reflected surface is.
In other words, the strength of the reflected ray's color is inversely
proportional to the length of said ray. (When used properly, this can
give a kind of "blurred reflection" effect, with the advantage over actual
blurred reflection that this would be significantly faster. Imagine, for
example, this effect used on some porcelain object with a weak reflection
to start with.)
However, rather than add this particular effect as a fixed, hard-coded
feature, it would be much better if the user would be given the option
of specifying some kind of function for eg. how the contribution of
reflected rays are calculated on the color of a surface. This way it
would not only be possible to implement this particular feature, but
a myriad of other features. (This user-defined function should, obviously,
get as parameters, or be able to get with special functions, all kinds of
info about the reflected ray, the reflecting object, the reflected object,
and other data.)
This doesn't necessarily have to have an impact on rendering speed when
*not* using the user-defined-function-for-reflections feature. The
implementation could simply check if such a function has been specified,
and if not, then use the old method. This should have a negligible impact
on rendering speed.
These user-defined functions should of course be used in other places
as well, not just in reflected ray calculations.
As said, I think that enhancements made to the current SDL should at
least try to go more into this direction, rather than just keep adding
more and more new fixed hard-coded features.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> wrote:
> Some of these are things I have discussed years ago, but I thought it
> could be useful to revive the discussion a bit.
>
> One of the original plans for POV-Ray 4 was to make a complete rehaul
> of the SDL from scratch, making it a lot more versatilve, expressive,
> powerful and faster (via byte-compilation). This would have been a
> completely new input language that's different from the current one
> (but with, perhaps, a backwards compatibility mode to support existing
> scene files.)
>
> I have no idea what the current plans are, but I have the impression
> that the idea of this kind of complete overhaul has been pretty much
> scratched, in favor of simply enhancing the current SDL. (If I'm wrong,
> I'd love to hear about the current development ideas on this.)
>
If we go this way, I would like to see some object-oriented capabilities (e.g.
the ability to create an object and instantiate it multiple times with different
attributes rather than wrapping it in another object { } block)
I would also like to see recursive function definitions, but not knowing how
complex this is, I consider it secondary.
> If we are simply going to keep the current SDL and enhance it, rather
> than create a completely new input language, perhaps a kind of in-between
> solution could be possible.
>
The problem would be that any major enhancement to the existing system is almost
certain to be a rewrite anyway, so why not use a new language (except that it
would completely break old scenes and necessitate rewriting current projects.)
> Snip (History lesson)
the problem I see with this is that not all of us are good at this sort of
thing. If this is the direction povray were to go, then I think it would be
better to have a plugin system so that, rather than compiling dozens of
unofficial versions of POVRay, we could have One Ring to Rule Them All, and
extra functionality -- even overriding functionality -- could be handled via the
plugin system.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 30.07.2015 um 12:15 schrieb Warp:
> One of the original plans for POV-Ray 4 was to make a complete rehaul
> of the SDL from scratch, making it a lot more versatilve, expressive,
> powerful and faster (via byte-compilation). This would have been a
> completely new input language that's different from the current one
> (but with, perhaps, a backwards compatibility mode to support existing
> scene files.)
>
> I have no idea what the current plans are, but I have the impression
> that the idea of this kind of complete overhaul has been pretty much
> scratched, in favor of simply enhancing the current SDL. (If I'm wrong,
> I'd love to hear about the current development ideas on this.)
The idea is not scratched at all. It's a big endeavour though, compared
to the time available, and some other fancy stuff can't wait to get
included (or, rather, I can't wait to include it ;-)), so it needs to be
woven into the current SDL.
> Now, I'm not saying that POV-Ray should implement a "shader" language
> that can do absolutely anything (although if well designed and implemented,
> that would be great). However, I think that future expansion of the
> current SDL should, in my opinion, at least go more into that direction.
I'm well aware of your wish for this road to be taken, and while it's
currently invisible in the SDL, under the hood things are already moving
in that direction (your past posts have been quite inspirational in this
respect). More and more portions of the code get clearly delineated from
each other, modularized, and shoved into well-defined polymorphic
classes - which will make it a whole lot easier to plug in user-defined
code.
One of the next steps on the agenda, for instance, will be to smash the
basic shading code into handy congruent pieces; under the hood, a single
texture layer will then not have one phong, one blinn-phong and one
diffuse component, but rather just have an arbitrary bunch of basic
shading effects, each of which can be phong, blinn-phong, diffuse, or
any of a number of more sophisticated models yet to be implemented - one
of which could be a wrapper for user-supplied code.
Initially, the parser will limit the power of this change by retaining
the current syntax, and just mapping it to the new internal model behind
the scenes, but I can imagine extending the current SDL syntax to breach
the current limit of number and type of effects soon after.
However, the user-supplied code portion of the scheme - and actually any
user-supplied code - /will/ have to wait for the parser rewrite:
User-supplied code needs /some/ sufficiently expressive syntax, a parser
for that, and a sufficiently powerful VM to run on - and I guess we
agree that it makes perfect sense to make that identical to the new
syntax, parser and VM for the general scene description.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.07.2015 um 06:37 schrieb Anthony D. Baye:
> If we go this way, I would like to see some object-oriented capabilities (e.g.
> the ability to create an object and instantiate it multiple times with different
> attributes rather than wrapping it in another object { } block)
That's what I want (and intend) to see, too.
> I would also like to see recursive function definitions, but not knowing how
> complex this is, I consider it secondary.
Once we throw out our current function VM and replace it with LLVM, that
should be possible.
BTW, one of the most recent changes (1b5aab6) involved abstracting the
current function VM out of the core code. From the render engine's point
of view, LLVM could be introduced any moment now - "only" the parser
would have to be adapted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> the problem I see with this is that not all of us are good at this sort of
> thing. If this is the direction povray were to go, then I think it would be
> better to have a plugin system so that, rather than compiling dozens of
> unofficial versions of POVRay, we could have One Ring to Rule Them All, and
> extra functionality -- even overriding functionality -- could be handled via the
> plugin system.
My suggestion had nothing to do with compiling POV-Ray, or having a plugin
system. It was about enhancing the current scene decription language with
features that are closer to shaders in design.
Current user-defined functions are already a step in that direction.
My suggestion was to expand that idea and make it usable in the actual
rendering (in different parts of it.)
And you wouldn't need to know how to use it, or the full language.
Those who would know, could make easy-to-use library functions that
you can use (in the same way as the current include system works.)
This has many advantages. For instance, if you needed a functionality
that's similar to what somebody else has done, you can just take that
"shader" of theirs and modify it a bit to suit your needs. No need to
recompile POV-Ray or use a complex "plug-in" system. Just write some
SDL and that's it.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> I'm well aware of your wish for this road to be taken, and while it's
> currently invisible in the SDL, under the hood things are already moving
> in that direction (your past posts have been quite inspirational in this
> respect). More and more portions of the code get clearly delineated from
> each other, modularized, and shoved into well-defined polymorphic
> classes - which will make it a whole lot easier to plug in user-defined
> code.
I'm glad to hear that.
> However, the user-supplied code portion of the scheme - and actually any
> user-supplied code - /will/ have to wait for the parser rewrite:
> User-supplied code needs /some/ sufficiently expressive syntax, a parser
> for that, and a sufficiently powerful VM to run on - and I guess we
> agree that it makes perfect sense to make that identical to the new
> syntax, parser and VM for the general scene description.
Do you mean that the "shader" code ought to have identical syntax to
everything else in the input language (rather than them being essentially
two separate and independent languages, one inside the other, like the
current SDL and the user-defined functions are now)?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.08.2015 um 00:43 schrieb Warp:
> I'm glad to hear that.
>
>> However, the user-supplied code portion of the scheme - and actually any
>> user-supplied code - /will/ have to wait for the parser rewrite:
>> User-supplied code needs /some/ sufficiently expressive syntax, a parser
>> for that, and a sufficiently powerful VM to run on - and I guess we
>> agree that it makes perfect sense to make that identical to the new
>> syntax, parser and VM for the general scene description.
>
> Do you mean that the "shader" code ought to have identical syntax to
> everything else in the input language (rather than them being essentially
> two separate and independent languages, one inside the other, like the
> current SDL and the user-defined functions are now)?
Yup.
Note that my goal is for the language /per se/ to have a very simple
syntax, and make it pretty much oblivious to rendering, except for
providing a few special native data types like 3D vectors and colours.
It'll be up to a bunch of predefined classes to fill it with raytracing
life in its scene description role. Such a language should be generic
enough to also be suited for the shader description role, so it would be
rather pointless and user-unfriendly to devise yet another language for
that purpose.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Note that my goal is for the language /per se/ to have a very simple
> syntax, and make it pretty much oblivious to rendering, except for
> providing a few special native data types like 3D vectors and colours.
> It'll be up to a bunch of predefined classes to fill it with raytracing
> life in its scene description role. Such a language should be generic
> enough to also be suited for the shader description role, so it would be
> rather pointless and user-unfriendly to devise yet another language for
> that purpose.
OTOH the "shader" part has to, by necessity, be more limited than the
generic part of the language. It wouldn't make sense, for example, to
be able to create new objects into the scene while evaluating, for
example, the color of a reflected ray. That would mess up things quite
badly, I think.
(Also, the reason why shaders in graphics hardware can be so fast is
that they are highly parallelizable. Modern cards run thousands of
instances of shaders in parallel. Obviously there need to be some
limitations in the shader language for this to be possible. There
can't be inter-dependencies between shader instances being evaluated.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.08.2015 um 16:10 schrieb Warp:
> clipka <ano### [at] anonymousorg> wrote:
>> Note that my goal is for the language /per se/ to have a very simple
>> syntax, and make it pretty much oblivious to rendering, except for
>> providing a few special native data types like 3D vectors and colours.
>> It'll be up to a bunch of predefined classes to fill it with raytracing
>> life in its scene description role. Such a language should be generic
>> enough to also be suited for the shader description role, so it would be
>> rather pointless and user-unfriendly to devise yet another language for
>> that purpose.
>
> OTOH the "shader" part has to, by necessity, be more limited than the
> generic part of the language. It wouldn't make sense, for example, to
> be able to create new objects into the scene while evaluating, for
> example, the color of a reflected ray. That would mess up things quite
> badly, I think.
That's part of the "fill it with raytracing life" thing: To add geometry
to the scene, you'd invoke particular classes (such as a "sphere" class,
a "box" class, and so on), which just won't be available in shaders.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 04.08.2015 um 16:10 schrieb Warp:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Note that my goal is for the language /per se/ to have a very simple
> >> syntax, and make it pretty much oblivious to rendering, except for
> >> providing a few special native data types like 3D vectors and colours.
> >> It'll be up to a bunch of predefined classes to fill it with raytracing
> >> life in its scene description role. Such a language should be generic
> >> enough to also be suited for the shader description role, so it would be
> >> rather pointless and user-unfriendly to devise yet another language for
> >> that purpose.
> >
> > OTOH the "shader" part has to, by necessity, be more limited than the
> > generic part of the language. It wouldn't make sense, for example, to
> > be able to create new objects into the scene while evaluating, for
> > example, the color of a reflected ray. That would mess up things quite
> > badly, I think.
>
> That's part of the "fill it with raytracing life" thing: To add geometry
> to the scene, you'd invoke particular classes (such as a "sphere" class,
> a "box" class, and so on), which just won't be available in shaders.
why not simply add a shader option to the texture block, and use something like
OSL for the shader language?
http://code.google.com/p/openshadinglanguage/
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
