Le 04/08/2020 à 10:26, Le_Forgeron a écrit :
> Ok, I note there is one remaining point that could be interesting:
> getting the current number of parsed tokens.
> Does not seem so urgent as a change.

For the curious, the value is in parser/parser.h : mTokenCount

Now, can someone provide a good name for the SDL to return that value ?

Post a reply to this message

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 04/08/2020 à 10:26, Le_Forgeron a écrit :
> > Ok, I note there is one remaining point that could be interesting:
> > getting the current number of parsed tokens.
> > Does not seem so urgent as a change.
>
> For the curious, the value is in parser/parser.h : mTokenCount
>
> Now, can someone provide a good name for the SDL to return that value ?

some new function modelled on 'sysconf(3)' would be cool, with 'mTokenCount'
just one of the argument values, perhaps.


regards, jr.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> Now, can someone provide a good name for the SDL to return that value ?

token_count
tokens_current
parsed_tokens
object_tokens
parser_tokens
current_tokens
tokens_now()

HowMuchStuffIHaveParsedSoFar

:D

Post a reply to this message

Le 20/08/2020 à 00:22, Bald Eagle a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> Now, can someone provide a good name for the SDL to return that value ?
> 
> token_count
> tokens_current
> parsed_tokens
> object_tokens
> parser_tokens
> current_tokens
> tokens_now()
> 
> HowMuchStuffIHaveParsedSoFar
> 
> :D
> 
Adopted "parsed_tokens"


=======
#version 3.8;
global_settings {assumed_gamma 1.0}
#include "colors.inc"
#default{ finish{ ambient 0.1 diffuse 0.9 }}


light_source { <100,1000,-1000>, White}

camera { location <0,-1,-16>
         right    x*image_width/image_height
         angle 35
         look_at <0,-1,0>
       }

plane{-z,-10  pigment{checker color rgb<1,1,1>*0.8 color rgb<1,1,1>} }

#declare String1=concat("parsed_tokens =", str(parsed_tokens,0,0));


text{ internal 1, "Parser info", 0.3, 0 pigment{Blue*0.7} translate
-4.5*x+1.5*y }
text{ internal 1, String1, 0.3, 0 pigment{Red*0.7} translate -4.5*x }
#declare String2=concat("parsed_tokens =", str(parsed_tokens,0,0));
#declare String3=concat("parsed_tokens =", str(parsed_tokens,0,0));
text{ internal 1, String2, 0.3, 0 pigment{Red*0.7} translate -4.5*x -1.5*y }
text{ internal 1, String3, 0.3, 0 pigment{Red*0.7} translate -4.5*x -3*y }

Post a reply to this message

Le 19/08/2020 à 21:27, jr a écrit :
> hi,
> 
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 04/08/2020 à 10:26, Le_Forgeron a écrit :
>>> Ok, I note there is one remaining point that could be interesting:
>>> getting the current number of parsed tokens.
>>> Does not seem so urgent as a change.
>>
>> For the curious, the value is in parser/parser.h : mTokenCount
>>
>> Now, can someone provide a good name for the SDL to return that value ?
> 
> some new function modelled on 'sysconf(3)' would be cool, with 'mTokenCount'
> just one of the argument values, perhaps.
> 
> 

You know what is bad with such idea ?
1. Look at the map type in image_map: using number instead of explicit
good name is painful, even when Constants.inc provides some name afterward.

http://wiki.povray.org/content/Reference:Image_Map

2. sysconf is a pain to use: you always need to be on the local system
to be sure to get what you ask (the man page of sysconf is using
symbolic constants, which do not translate at all between systems once
compiled). Initially I thought you wanted access to sysconf, but it
seems to only be a model.

3. it is too open: there is no usable specification.
It is like "add a foo(bar) function which return mTokenCount when bar is 3"
Why having such function ? What would be the common part with the value
returned when bar is 5 ?
Also Povray loves floating point values, and hates integer, so what is
the meaning of foo(3.4) ?
It reminds me far too much of the poke & peek tables in the 80's computers.

To misname things is to add to the unhappiness of the world.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> You know what is bad with such idea ?
> 1. Look at the map type in image_map: using number instead of explicit
> good name is painful, even when Constants.inc provides some name afterward.

Yes.  I would agree that a good (but SHORT) name would be best.
But I have also come to value the ability to refer to things numerically, so
that I can loop through a collection of things easily - we people love
descriptive, meaningful names - computers love numbers.

Wih respect to image_map specifically, any guesses as to what the missing map
types were supposed to be?  :D

> Initially I thought you wanted access to sysconf, but it
> seems to only be a model.

I think he was interested in having a "povray system function" that would be
able to return a number of different system / environment / configuration values
- LIKE sysconf.
So perhaps some of the internal epsilon values, memory available, threads used,
etc.   Someone might want to annotate their render or generate a text file that
gets post-render bundled with their render for documentation purposes.
Development, debugging, documenting - and they may want/need to do that with a
programmable function - like if they have 3000 frames - and avoid having to drag
another software/OS tool (and learning curve) into the mix.

> To misname things is to add to the unhappiness of the world.

Yeah, brother.  No truer words were ever spoken.  Say what you mean, and mean
what you say. (Or at least try as much as possible/practical)

Post a reply to this message

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> ...
> 2. sysconf .... Initially I thought you wanted access to sysconf, but it
> seems to only be a model.

yes, just a function with an interface like 'sysconf()'.  Bald Eagle put it
better than I could.

> ...
> To misname things is to add to the unhappiness of the world.

agree, and yet, finding "good" descriptive names is never easy (for me, anyway).


regards, jr.

Post a reply to this message

On 8/23/20 1:38 PM, Bald Eagle wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
...
> 
> Wih respect to image_map specifically, any guesses as to what the missing map
> types were supposed to be?  :D
> 

I ran across the following in the v1.0 source code the other day while 
trying to understand the history of something:

/* Image/Bump Map projection methods */
#define PLANAR_MAP      0
#define SPHERICAL_MAP   1
#define CYLINDRICAL_MAP 2
#define PARABOLIC_MAP   3
#define HYPERBOLIC_MAP  4
#define TORUS_MAP       5
#define PIRIFORM_MAP    6
#define OLD_MAP         7

I guess v3.8's type 7 (angular light probe?) took OLD_MAP's slot :-).

The documentation has forever said types 3 & 4 are under development, 
but I've never spotted any actual code indicating this ever true beyond 
an intent. FWIW.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> I ran across the following in the v1.0 source code the other day while
> trying to understand the history of something:
>
> /* Image/Bump Map projection methods */
> #define PLANAR_MAP      0
> #define SPHERICAL_MAP   1
> #define CYLINDRICAL_MAP 2
> #define PARABOLIC_MAP   3
> #define HYPERBOLIC_MAP  4
> #define TORUS_MAP       5
> #define PIRIFORM_MAP    6
> #define OLD_MAP         7

VERY cool  :)
It's more than clipka uncovered.
So at least that answers a 6-year-old question.  :D

http://news.povray.org/povray.binaries.images/message/%3C5438051b%241%40news.povray.org%3E/#%3C5438051b%241%40news.povr
ay.org%3E

Are these mapping types still in need of development?

Post a reply to this message

On 8/24/20 1:35 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
...
> 
> Are these mapping types still in need of development?
> 

None can be that important given how long they've not been done! :-)

Guessing a  at meaning/application, the parabolic I suppose might 
occasionally be of use - parabolas. Taking the hyperbolic to mean 
non-linear in some aspect of other usually linear mappings, that I guess 
that would end up as a set of 'hyper' mappings for linear, spherical, 
etc. Piriform suppose might have been aimed at two element blobs or 
something?

My up front issue with all more complicated mappings - and with the more 
complicated shape uv_mapping options - is one should first and foremost 
work out how the maps can easily be created in POV-Ray(1). Or, know of 
some standard external 'standard' like the light probe angular mapping 
added to v3.8. Otherwise, you've got some feature you can 'advertise' 
and which might look great for a demo or two, but in the end it's a 
feature pretty much nobody uses.

(1) - Matching cameras, an interactive painting capability, ...

Aside: Most any complicated mapping can be accomplished today via 
functions - though it might not be easy to get right, as you well know.

Bill P.

Post a reply to this message