 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/23/20 2:25 PM, Bald Eagle wrote:
>
...
>
Aside: I see my response is one where the formatting got wonky. Unsure
why it happens. I've looked for offending settings in thunderbird. Maybe
particular newsgroups or original quoted text with certain characters a
trigger? I don't know. Apologies, but I don't see the issue on sending.
-----------
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.
--- The _<lowercase> arguments would be the way to avoid parameter
collisions. Nothing required, but if you don't want trouble...
--- On the idea of per include file generated unique names(1) and
sorting on include order as a way to decide which 'Thing1' you want.
Includes very often include other files. It can be an unstable tangle.
The 'topological sort' can change relative to low level includes based
on adding other includes, user settings, macro settings, etc. We
struggle with these same ordering issues in c, c++ header files as jr
pointed out. Most programming languages have collision issues / scope
issues which you have to understand(2) - even with namespace support(3).
(1) - In my tcl library I have a UniqueName command which uses a global
counter to create unique names. The counter value gets used as a suffix
to create, say, 'Union_0123' and there are options for padding and
delimiting characters. This generated unique id approach works well in
languages with good 'list' (c++ std::vector) support. It has the
exposure things can blow up storage wise if you aren't careful. I've
found it easy to duplicate. Today, POV-Ray internally flattens /
duplicates - excepting meshes and a few other things. Perhaps, not a bad
approach practically - if we had the list support.
(2) - Excepting those languages which never allow re-definition/undef
within any given scope. This is the central concept used in functional
programming languages. I'm toying with povr working in this way - for
non SDL programming elements (objects, textures, macros, functions).
Namely all name collisions and undefs being illegal for classes of
things not needed for program control. Toying != knowing how. :-)
(3) - Most namespace languages to which I've been exposed support a
'using <namespace>::min' sort of declaration. These often get used -
because people don't like to type - but, allowing the shorthand can
weaken the namespace protections.
--- On jr's point about no type checking. I think we are not too
exposed. While there is no strict up front type checking, it looks to me
like the parser tracks the current id types so you cannot incorrectly
use the wrong type due a bad/unfortunate assignment somewhere.
--- On making the lower case named functions in math.inc inbuilt. I
might with some/all. I'm ever refining. Everything takes time and nearly
always more than I first imagine. Step one for me was just getting clear
what they really were and moving them to functions.inc where I've
already slowly been changing f_agate and similar wrappers to inbuilt
functions.
--- On eval_pigment / Eval_Pigment (and alias capability). I've never
liked eval_pigment! It's not inbuilt, but we talk about it like it is.
The functionality is already inbuilt. It's this:
#include "strings.inc"
#declare Vec = <1,2,3>; // *** ***
#declare FnPig00 = function { pigment { rgb <0,1,0,0.2,0.3> } }
#declare Rslt = FnPig00(Vec.x,Vec.y,Vec.z);
#debug concat(" ",CRGBFTStr(Rslt,2,2),"\n")
The problem with things like eval_pigment and alias capability is they
hide the actual code/functionality mostly on the argument of less
typing(4). If you want to type less, add hot key sequences to your
editor to insert code templates. There's a place for the ability to
alias or redefine inbuilt functionality in a language, but it should not
be generally used. It makes things harder to learn and harder to debug.
I was once handed code to debug where the user had, almost completely,
redefined the actual input language with aliases.
I cannot add Eval_Pigment to texture.inc. The only include files
currently packaged with povr are:
arraycoupleddf3s.inc functions.inc rand.inc strings.inc
arrays.inc math.inc shapes.inc transforms.inc
My povr approach is includes will be in their own code repository.
Except rarely where what's in the include is essential to core
functionality. I've moved Eval_Pigment to math.inc for now as core
functionality, but it's on my 'maybe it should just go away' list.
(4) - And, yep. I don't like the DBL, SNGL in our source code since
v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request
years back which then never got adopted. PRECISE_FLOAT now needs to be
yanked at some point from povr and I'd like to drop DBL and SNGL too.
Today you can find the bare 'foat/double' declarations in the source
code depending on who wrote what. This makes it unlikely we can really
ever change DBL to be anything but double, for example. Certainly not
without a lot of type conversions even if, by some chance, everything
works correctly.
--- On additional lower case constants becoming in-built. I'm not
opposed so long as they are very common. V38 added tau.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymous org> wrote:
> On 6/23/20 2:25 PM, Bald Eagle 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?!
not knowing the codebase[*], but if the "SDL" was simply a (Tcl) "safe
interpreter", with all the SDL language constructs as commands, then we could
write something like:
set version 3.8
array set global_settings {
assumed_gamma 1
}
light_source {-1 0 -1 10e5} {color {1 1 1} parallel}
:-)
[*] assuming that the source except 'frontend' and 'parser' stuff would be
(relatively) unaffected.
added, potential, incentives: storing the distribution .inc files,
pre-processed, in a Sqlite db; using a zip VFS for managing/distributing
projects with many files; "reflected channel" to read compressed .inc files (for
large meshes, or Hilbert curves :-)).
flights of fancy..
> ...
> (1) ... if we had the list support.
would be built in. ;-)
> ...
> (3) - Most namespace languages to which I've been exposed support a
> 'using <namespace>::min' sort of declaration. These often get used -
> because people don't like to type - but, allowing the shorthand can
> weaken the namespace protections.
a typical "Problem Exists Between Chair And Keyboard" problem.
> --- On jr's point about no type checking. I think we are not too
> exposed. While there is no strict up front type checking, it looks to me
> like the parser tracks the current id types so you cannot incorrectly
> use the wrong type due a bad/unfortunate assignment somewhere.
sure, I just think that, just like for regular arrays, when an identifier has
been "cast" to type A, a subsequent assigning of type B should output a warning
(preferably cause an error). because, in all likelihood, it'll be a typo or
logic error.
> ...
> --- On eval_pigment / Eval_Pigment (and alias capability). I've never
> liked eval_pigment! It's not inbuilt, but we talk about it like it is.
naive question. calling the macro returns the colour in pigment at given point.
but what good is that information, given that lighting is not part of the
process?
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> so, it is late and I had too much coffee, probably.. :-)
Too much _something.
WTH is "too much coffee?" :P
> how about replacing the SDL, wholesale?!
That has its merits, and may be a method of addressing all of the double/single
issues in the process...
> sure, I just think that, just like for regular arrays, when an identifier has
> been "cast" to type A, a subsequent assigning of type B should output a warning
> (preferably cause an error). because, in all likelihood, it'll be a typo or
> logic error.
Could be. But I like the flexibility afforded by re-casting things on the fly.
Learning good coding practices aside, allowing scenes to WORK (newbies to
POV-Ray in mind) is something we should encourage.
Issue warnings and suggestions - but full stop halts of parsing can be a real
bummer.
> > --- On eval_pigment / Eval_Pigment (and alias capability). I've never
> > liked eval_pigment! It's not inbuilt, but we talk about it like it is.
I like the capability, but I agree with the obfuscation. I've learned SO much
from WP and the do-it-from-scratch ShaderToy community. Perhaps eval pigment
should be an example scene illustrating how to write functions that process
patterns.
But also, given that we often use it with things like ("large") images in
image_pattern, I'd like to see a speed improvement by moving something like that
to source, so that an array of RGB values can be accessed and acted upon
speedily, via compiled code.
> naive question. calling the macro returns the colour in pigment at given point.
> but what good is that information, given that lighting is not part of the
> process?
Because you're not trying to jump ahead in time beyond when the lighting and
ambient occlusion get applied. You're looking to inspect the "color
composition" of the base object.
perhaps for pattern purposes.
http://news.povray.org/povray.binaries.images/thread/%3Cweb.52ede41cd6fcc84f7a3e03fe0@news.povray.org%3E/?mtop=391443&m
off=7
http://news.povray.org/povray.binaries.images/message/%3C3b8946fd%40news.povray.org%3E/#%3C3b8946fd%40news.povray.org%3
E
http://news.povray.org/povray.binaries.images/thread/%3C5078802b%40news.povray.org%3E/
or for use as a map to place objects
http://www.povcomp.com/entries/124.php
http://news.povray.org/povray.binaries.images/message/%3C409135b4%40news.povray.org%3E/
Similar questions have been raised:
http://news.povray.org/povray.general/thread/%3C5be81e8e%241%40news.povray.org%3E/
If you want lighting, you can render, and then use eval pigment on the rendered
image, which obviously has the lighting effects in the final computation of the
pixel color value.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > so, it is late and I had too much coffee, probably.. :-)
>
> Too much _something.
> WTH is "too much coffee?" :P
</grin>
> > ... because, in all likelihood, it'll be a typo or logic error.
>
> Could be. But I like the flexibility afforded by re-casting things on the fly.
> Learning good coding practices aside, allowing scenes to WORK (newbies to
> POV-Ray in mind) is something we should encourage.
> Issue warnings and suggestions - but full stop halts of parsing can be a real
> bummer.
the flip side is, every such "flexibility" comes, somewhere down the line, at
some cost. for instance, allowing:
#declare A = "foo";
....
#declare A = <1,2,3>;
gives flexibility, but also means that (automatically) optimising code has
become too costly (in time), if not impossible altogether.
> > > --- On eval_pigment / Eval_Pigment (and alias capability).
> Similar questions have been raised: ...
interesting thread, thanks.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> the flip side is, every such "flexibility" comes, somewhere down the line, at
> some cost. for instance, allowing:
> #declare A = "foo";
> ....
> #declare A = <1,2,3>;
>
> gives flexibility, but also means that (automatically) optimising code has
> become too costly (in time), if not impossible altogether.
I don't know how it gets optimized, or why allowing recasting would break that.
If I can envision a macro that checks if an identifier that I'm trying to use is
defined - and if it is, then first I undefine it, and then proceed as usual -
then I would imagine that such a thing could be done in C / c++.
It would be very nice indeed if we had a way in SDL (or povr) to determine the
type of an identifier. This would be _extremely_ useful when importing data
with #read and probably other cases as well.
As much as I like the programming aspect of POV-Ray, it is of course, a
raytracer, and the point is to make renders, not pedantically ram "best coding
practices" down some newbie doodler's throat.
At that point, perfect becomes the mortal enemy of good, and we lose a lot of
otherwise new USERS - which POV-Ray will die without. Having recently been
thrust into coding the Arduino, which is supposed to be designed for "beginners"
and kids - dealing with all of the esoteric BS involved with strings and serial
input, buffers, types, etc --- it's a REAL PITA to even perform otherwise simple
tasks. And I'll bet some people simply give up out of frustration.
Do we really want to repel people with an even steeper learning curve?
I mean, I see us stuck between accessibility, speed, and accuracy.
And the multithreaded source code has already become a vast, organically
interwoven behemoth. It's hard to say what the best route to take is.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24.06.2020 19:53, William F Pokorny wrote:
> (4) - And, yep. I don't like the DBL, SNGL in our source code since
> v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request
> years back which then never got adopted. PRECISE_FLOAT now needs to be
> yanked at some point from povr and I'd like to drop DBL and SNGL too.
> Today you can find the bare 'foat/double' declarations in the source
> code depending on who wrote what. This makes it unlikely we can really
> ever change DBL to be anything but double, for example. Certainly not
> without a lot of type conversions even if, by some chance, everything
> works correctly.
Except, that is not why they are there: DBL is in the source code
because there was a time when you could not depend on "double" actually
doing what you wanted it to do. A time when certain CPUs had 80 bit
floating point numbers, and other odd things with software emulated
floating-point. In this world it was essentially that the floating-point
representation could be changed. These days are long over, but the code
just happens to be so old that it still has these leftovers.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> 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... :-)
:-)
> ...
> 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.
thanks for giving me/us some insight in to your "personal" tools.
on parser replacement, I guess that's what I meant by a "safe" interpreter
pre-loaded with commands; the example was just off the top the head. in fact,
had I thought ahead, I'd written:
set version 3.8
include colors.inc
array set global_settings {...}
light_source location {-1 1 -1 10e5} color white mods {parallel shadowless}
ie use 'dict' style lists as arguments, throughout.
anyway, personally, I look forward to more Tcl .. influence on development.
(re lists. I think a distribution .inc file implementing an i/f similar to Tcl
lists would (could?) be sufficient/"good enough")
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/26/20 1:43 AM, Thorsten wrote:
> On 24.06.2020 19:53, William F Pokorny wrote:
>> (4) - And, yep. I don't like the DBL, SNGL in our source code since
>> v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request
>> years back which then never got adopted. PRECISE_FLOAT now needs to be
>> yanked at some point from povr and I'd like to drop DBL and SNGL too.
>> Today you can find the bare 'foat/double' declarations in the source
>> code depending on who wrote what. This makes it unlikely we can really
>> ever change DBL to be anything but double, for example. Certainly not
>> without a lot of type conversions even if, by some chance, everything
>> works correctly.
>
> Except, that is not why they are there: DBL is in the source code
> because there was a time when you could not depend on "double" actually
> doing what you wanted it to do. A time when certain CPUs had 80 bit
> floating point numbers, and other odd things with software emulated
> floating-point. In this world it was essentially that the floating-point
> representation could be changed. These days are long over, but the code
> just happens to be so old that it still has these leftovers.
>
Yes, thanks. A good point.
It's easy to forget while playing with code today that those who created
POV-Ray were working in a much tougher, unstable environment. Plus we
now have ready access to so much more information - Wikipedia, papers,
on line code, etc.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Yes, thanks. A good point.
>
> It's easy to forget while playing with code today that those who created
> POV-Ray were working in a much tougher, unstable environment. Plus we
> now have ready access to so much more information - Wikipedia, papers,
> on line code, etc.
Ah, the same things existed back then. They were called books ;-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
