POV-Ray : Newsgroups : povray.pov4.discussion.general : Reviving some pov4 discussion : Re: Reviving some pov4 discussion Server Time
23 Feb 2024 18:29:44 EST (-0500)
  Re: Reviving some pov4 discussion  
From: clipka
Date: 31 Jul 2015 11:52:08
Message: <55bb99a8@news.povray.org>
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 

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

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