POV-Ray : Newsgroups : povray.newusers : Ignorance rules! : Re: Ignorance rules! Server Time
19 Apr 2024 14:52:03 EDT (-0400)
  Re: Ignorance rules!  
From: William F Pokorny
Date: 25 Jun 2020 08:41:19
Message: <5ef49b6f$1@news.povray.org>
On 6/24/20 8:12 PM, jr wrote:
...
>> First, reminding everyone 'povr' is not POV-Ray. I'm combining my
>> responses and when I start to think about major revisions to POV-Ray's
>> SDL, I begin to think seriously about bindings to lua, tcl and python.
> 
> so, it is late and I had too much coffee, probably..  :-)
> 
> how about replacing the SDL, wholesale?!
> 

Suppose the short answer is it's harder than it looks... And I agree 
with Bald Eagle about there never being enough coffee. When did I last 
drink water, straight... :-)

I have a somewhat complete set of tcl wrappers for POV-Ray 'SDL' 
creation which I use about as often as POV-Ray's SDL itself when 
creating scenes. It's an effort started as a small limited utility which 
grew into something to explore what a tcl scene description language 
might be like. It's an experiment so approaches drift and change. Some 
parts are now quite old/dated.

There are a good many subtle things POV-Ray's language (the parser) does 
to help us code that are not easy to replicate even supposing one knows 
what they all are... I guarantee I've still got lots of bugs in this 
aspect of my wrapping.

With respect to actual bindings, the source code is better partitioned 
than it was - thanks mostly to Christoph. Still, any bindings reasonably 
complete are a ways off from doable in my opinion. This doesn't mean 
it's not possible to create particular bindings today. Somewhere I have 
an experiment where I was binding particular shape functions for testing 
purposes. A kind of tcl unit test, but it's work since gone cold.

The aim with what I have is that every scene entity is a definable item 
with an ID. POV-Ray started with this approach and then dropped this 
concept when certain features were added - radiosity, warps, etc. - over 
time. Not sure of all the whys. With define-ability in place you can 
define RadiosityQuick and RadiosityFinal for example and then pick in 
the 'SDL/Tcl' which to use by name.

The start of a scene with my wrappers looks like:

set FID "FIDmain"
DefVersion        Version      $FID "3.8" -unofficial povr
DefGlobalSettings Global00     $FID -assumed_gamma 1.0
DefBackground     Background00 $FID -color Grey50

DefLight Light00 $FID -location 50.0,150.0,-250.0 -color White
#... ending with:
Scene tmp.pov $FID -i Version -i Background00 -i Global00
	-i Camera00 -i Light00

Every command has inbuilt help; fairly extensive checking; most have 
inbuilt examples which can be used for testing and some have specific
test scenes too. Where you see -color the color definition is created on 
the fly when not already done from a large library of color names. What 
gets included in any particular scene/include file is based on 
dependencies from the -i, -d and -c Scene flags.

Anyway. Details not that important. The point is I've been playing with 
a wrapper for a long time (10 years on and off now) - and while 
extensive, it's not complete. Parts of it I look at today and want to 
rework, but where it's mostly working, I leave it. It's an experiment.

It's not quite what you posted example wise, but I do sometimes wonder 
how far one might get creating a tcl intepreter supporting POV-Ray's 
commands as is. Meaning, aiming more for a parser replacement without 
trying to address existing shortcomings from the start.

Bill P.


Post a reply to this message

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