POV-Ray : Newsgroups : povray.pov4.discussion.general : Reviving some pov4 discussion Server Time
29 Mar 2024 10:24:51 EDT (-0400)
  Reviving some pov4 discussion (Message 11 to 20 of 35)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Anthony D  Baye
Subject: Re: Reviving some pov4 discussion
Date: 4 Aug 2015 21:05:00
Message: <web.55c1610f8cd067d52aaea5cb0@news.povray.org>
"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> 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.

Of course, using a shader with a patterned texture doesn't make a lot of sense,
so shaders could be used as alternatives to textures.

Then too, if we end up with an OO SDL, would the shader become an object?
Perhaps a subclass of texture... or maybe a superclass... sibling?

At any rate, my point is why make the job more difficult by designing two
complete languages, when we can use one that's already made.

Regards,
A.D.B.


Post a reply to this message

From: clipka
Subject: Re: Reviving some pov4 discussion
Date: 5 Aug 2015 02:42:41
Message: <55c1b061$1@news.povray.org>
Am 05.08.2015 um 03:04 schrieb Anthony D. Baye:

>> 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/

Uh... "simply"?

Maybe because we'd need to...

- design the new SDL in such a way that the OSL can be embedded therein 
without conflict;

- design the new SDL parser in such a way that the OSL can be plugged 
into it;

- design a layer that provides the exact features exposed to the user by 
the OSL;

- prepare for a never-ending struggle to explain to users why feature X 
is part of OSL but not supported by POV-Ray; and

- prepare for a never-ending struggle to explain to users why syntax Y 
in the SDL doesn't do the same as in the OSL.


Thanks, but no thanks.

/Maybe/ OSL will be supported by some POV-Ray 4.5, as an /alternative/ 
to the native shader definition syntax. But not in POV-Ray 4.0, and 
certainly not as the primary language for user-defined extensions.


> Then too, if we end up with an OO SDL, would the shader become an object?
> Perhaps a subclass of texture... or maybe a superclass... sibling?

Exactly that.


> At any rate, my point is why make the job more difficult by designing two
> complete languages, when we can use one that's already made.

Because (A) one of those two languages needs to be designed from scratch 
anyway, in order to be suitable as a Scene Description Language for 
users who don't want to be programmers.

I don't want users to have to write

      MySphere = new sphere;
      MySphere.center.x = 2.0;
      MySphere.center.y = 1.0;
      MySphere.center.z = 5.0;
      MySphere.radius = 0.5;
      MyScene.add(MySphere);

when a specially-designed language could make it a one-liner, like it is 
in the current SDL. I've yet to see a language other than SDL 3.x that 
fits the bill; but I know that a language can be designed to achieve 
that goal.

And (B) because the two complete languages will be just one. With a 
different set of objects to manipulate, but the same underlying language 
nonetheless.


Post a reply to this message

From: Warp
Subject: Re: Reviving some pov4 discussion
Date: 5 Aug 2015 13:29:42
Message: <55c24806@news.povray.org>
Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> 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/

The "shader" language would need to be able to do a lot more than just
get some values and input and return a color.

For example, it ought to be possible for it to say "shoot a ray starting
from this point towards this direction, and gimme all the info about
the object that the ray hits". (This kind of functionality could be
used, for instance, to create a "portal" shader. In other words, a
surface that shows a completely different part of the scene, as if
the suface were a "portal". Rather than this being a hardcoded feature,
the user ought to easily write such functionality as a "shader". As
such, it's then easy to create a myriad of variants with little effort.)

-- 
                                                          - Warp


Post a reply to this message

From: Nekar Xenos
Subject: Re: Reviving some pov4 discussion
Date: 25 Aug 2015 14:07:41
Message: <op.x3xra0gmufxv4h@xena>
On Wed, 05 Aug 2015 19:29:42 +0200, Warp <war### [at] tagpovrayorg> wrote:

> Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
>> 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/
>
> The "shader" language would need to be able to do a lot more than just
> get some values and input and return a color.
>
> For example, it ought to be possible for it to say "shoot a ray starting
> from this point towards this direction, and gimme all the info about
> the object that the ray hits". (This kind of functionality could be
> used, for instance, to create a "portal" shader. In other words, a
> surface that shows a completely different part of the scene, as if
> the suface were a "portal". Rather than this being a hardcoded feature,
> the user ought to easily write such functionality as a "shader". As
> such, it's then easy to create a myriad of variants with little effort.)
>

Ooo portals! I like portals =D

-- 
-Nekar Xenos-


Post a reply to this message

From: Benjamin Chambers
Subject: Re: Reviving some pov4 discussion
Date: 16 Sep 2015 14:02:50
Message: <55f9aeca$1@news.povray.org>
On 8/5/2015 11:29 AM, Warp wrote:
> For example, it ought to be possible for it to say "shoot a ray starting
> from this point towards this direction, and gimme all the info about
> the object that the ray hits". (This kind of functionality could be
> used, for instance, to create a "portal" shader. In other words, a
> surface that shows a completely different part of the scene, as if
> the suface were a "portal". Rather than this being a hardcoded feature,
> the user ought to easily write such functionality as a "shader". As
> such, it's then easy to create a myriad of variants with little effort.)
>

It would also allow all kinds of tricks involving translucency, 
reflections, etc. For instance, the example of blurred reflection you 
gave in the first post.


Post a reply to this message

From: Mr
Subject: Re: Reviving some pov4 discussion
Date: 17 Sep 2015 04:30:01
Message: <web.55fa79128cd067d516086ed00@news.povray.org>
"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> 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.


As a beginner, When I considered options of free renderers to learn, I chose
POV-Ray over Aqsis and other RIB like alternatives. One of the reasons was that
it had one language to learn instead of two, and this also felt a relief later
when deciding to script for an exporter, which had to be written in yet another
language (Python) (by the way Mitsuba has a full Python API/SDL which makes it
very attractive in this regard but it does miss a lot of the POV-Ray features)

Also I get the point that externalizing development by relying on solid
standards like the OSL you suggest allows developers to focus on more important
things, but the SDL is really central and one of the biggest selling point of
POV-Ray. It made me chose it not because it was standard, but because I trusted
it had the potential to be better than standard.


Post a reply to this message

From: Mike Horvath
Subject: Re: Reviving some pov4 discussion
Date: 10 Dec 2015 19:20:33
Message: <566a16d1$1@news.povray.org>
On 7/30/2015 6:15 AM, Warp 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 think basing things of SVG would be a good idea. I.e. XML + SMIL + 
JavaScript.


Mike


Post a reply to this message

From: clipka
Subject: Re: Reviving some pov4 discussion
Date: 11 Dec 2015 10:04:05
Message: <566ae5e5$1@news.povray.org>
Am 11.12.2015 um 01:20 schrieb Mike Horvath:
> On 7/30/2015 6:15 AM, Warp 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 think basing things of SVG would be a good idea. I.e. XML + SMIL +
> JavaScript.

Abso-bloody-lutely not.

XML is quite useful for the static description of purely hierarchical
structures comprised mainly of textual information; for anything else,
it is overly verbose and/or excessively difficult to employ.

A POV-Ray scene is indeed, in essence, a description of purely
hierarchical structures; however, that's where the applicability of XML
ends:

- The information in a POV-Ray scene is mostly non-textual, which means
that much of the overhead XML introduces is entirely unnecessary (such
as the enclosing of tags in angular brackets, or of attribute values in
double quotes).

- POV-Ray's current SDL excels (arguably not in speed, but certainly in
flexibility) in the dynamic generation of scenes; its description of
information is non-static, and a successor to its SDL should indeed
provide the same feature with similar ease. XML is poorly suited for
that: XML-based notations for control structures tend to be excessively
complicated.

The grafting of JavaScript on top of XML (or, more precisely, into its
bowels) does provide a way of generating information dynamically with
more ease than XML alone would allow; however, this is nothing more than
a makeshift solution -- one that has caught on, I give you that, but
that doesn't mean it's anywhere close to elegant: You do need to learn
two entirely different languages, XML and JavaScript.

In fact, the fusing of XML and JavaScript is as ugly a chimera as it can
possibly get: Some valid (and in fact pretty much essential) JavaScript
operators are invalid as XML content; as a matter of fact, /all/
characters that are invalid in XML content may occur as operators in
JavaScript. Thus, embedding arbitrary JavaScript into XML is only
possible via a workaround that hijacks XML comments - which should
normally be ignored - to contain relevant content. And even then, it is
possible to write JavaScript code snippets that break the mechanism by
which they are embedded into XML.

The only clean solution to this problem is to let the JavaScript
portions reside in entirely different files; but that defies the whole
purpose of having a unified language to describe content in a dynamic
fashion.


When it comes to data exchange formats, rather than XML, a much more
suitable candidate for a future POV-Ray SDL would be JSON. But even
then, I think it should only serve as a source for inspiration, rather
than being employed "out of the box".


In my opinion it remains a fact that the best language for POV-Ray would
be a domain-specific language (and by that I don't mean a
domain-specific abuse of an existing language like Apache Camel's DSL,
but a genuine language in its own right).


Post a reply to this message

From: Dick Balaska
Subject: Re: Reviving some pov4 discussion
Date: 11 Dec 2015 11:43:18
Message: <MPG.30d4c73419c41bdd98968e@news.povray.org>
In article <566ae5e5$1@news.povray.org>, ano### [at] anonymousorg says...
> > I think basing things of SVG would be a good idea. I.e. XML + SMIL +
> > JavaScript.
> 
> Abso-bloody-lutely not.

I thought the same thing. XML is a bitch to write by hand. Awesome for 
machine generation, though.

> You do need to learn
> two entirely different languages, XML and JavaScript.

Yeah, but povray is two fused languages now.  The DKBTrace "C" type of 
object definition (which I learned first...) and a perl-ish procedural 
language bolted on top of that.

I thought of JSON when he said XML, but is that really any better than 
what exists? It just replaces the current braces with brackets and 
braces.  One advantage might be, my only complaint about the current 
language is the inconsistent use of semicolons and commas.
#declare SemicolonRequired=1;
#debug "no semicolon here\n"
torus { 1, 0.1 }	// comma please
cone { <0,0,0> 1 <1,1,1> 2 }	// 4 params no commas

dik


Post a reply to this message

From: Le Forgeron
Subject: Re: Reviving some pov4 discussion
Date: 11 Dec 2015 16:37:32
Message: <566b421c$1@news.povray.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 11/12/2015 17:43, Dick Balaska a écrit :
> In article <566ae5e5$1@news.povray.org>, ano### [at] anonymousorg
> says...
>>> I think basing things of SVG would be a good idea. I.e. XML +
>>> SMIL + JavaScript.
>> 
>> Abso-bloody-lutely not.
> 
> I thought the same thing. XML is a bitch to write by hand. Awesome
> for machine generation, though.

writing once xml is not a problem... it's reading it later and trying
to amend it that is really painful.

> 
>> You do need to learn two entirely different languages, XML and
>> JavaScript.
> 
> Yeah, but povray is two fused languages now.  The DKBTrace "C" type
> of object definition (which I learned first...) and a perl-ish
> procedural language bolted on top of that.
> 
> I thought of JSON when he said XML, but is that really any better
> than what exists? It just replaces the current braces with brackets
> and braces.  One advantage might be, my only complaint about the
> current language is the inconsistent use of semicolons and commas. 
> #declare SemicolonRequired=1; #debug "no semicolon here\n" torus {
> 1, 0.1 }	// comma please cone { <0,0,0> 1 <1,1,1> 2 }	// 4 params
> no commas
> 
> dik
> 

If I was crazy, I would use C++ and a compiler as the parser, filling
a scene object with other objects... a rendering would be the
interaction of a camera with a scene. The only problem I would
foresee: the dynamic generation of code ... you know, the first part
of the parsing generate an include file to be included later... but do
we really need that ?(I'm afraid someone will want it).

Animation ? well, just a matter of looping...

Povray 3D objects, and all others aspects, just a library within a
dedicated namespace.

usual functions : just native coding.

Remaining problem: new users have to learn C++ and get a C++ compiler,
linking with the povray library.

Povray::Torus obj1(1,0.1);
// texturing can be a post constructor operation
Povray::Cone obj2( Povray::3DVector(0,0,0), 1, Povray::3DVector(), 2);
Povray::Scene take1;
take1 += obj1;
take1 += obj2;

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlZrQhsACgkQhKAm8mTpkW0UCQP/Qe5KVy5Jm+Owwm8iCWRtcE1w
6rYxFlWFbmfHrsKzJLnZmbsyNPpYikd/cY1TU9mZ6JSZbuB19od+2XDs1wgYs+CF
SfADG628Gty79WXKueVPjdIv0q60jxNw8tDR+3GfjtJxMmN3xKGcZMn1rCnV1nYg
kkZ/flue97VAFzYnRmo=
=BKtc
-----END PGP SIGNATURE-----


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.