User changes. yuqk / v4. Options re-work status.

The current output related option(s):

declare=<name>= <float or string> value only

become(s):

+-ub_   user_bool_filename=    string value only
+-ui_   user_int_filename=     string value only
+-uf_   user_flt_filename=     string value only
+-us_   user_str_filename=     string value only
+-uv2f_ user_vec2d_filename=   string value only
+-uv3f_ user_vec3d_filename=   string value only
+-uv4f_ user_vec4d_filename=   string value only
+-uv5f_ user_vec5d_filename=   string value only
+-um_   user_matrix_filename=  string value only

Add set of standard user boolean switch names.
  +-uof_00  user_on_off_00=   on|off

+-ux_    user_execute_filename= string value only
          (Thought is to let users create user input files
           with whatever scripting, programming language
           they wish during options parsing)

Only the rough outline above. No integrated code. (I have a couple 
standalone test file parsing programs running)

I'll mention here, one of the aims of these option updates is to make 
nearly all (all?) option settings available via new inbuilt functions in 
the parser(*). An option name string being passed as the query key. In 
limited testing this works, but I've not implemented / tried the vectors 
or matrix stuff above. Those will need more code to truly be integrated 
during parsing.

The overall thinking is to implement something more powerful than 
'declare=...'.

The filenames used would be space delimited and use ascii-string(fast) 
(or maybe std::string utf8) keys. The same inbuilt functions used as 
option settings at parse time would be used to access these values by 
key(**), while new inbuilt functions would be required to support vector 
/ matrix input (or direct use?).

Aside: Values set with these user files would be guaranteed, top level, 
read only, 'globals'. There are outstanding issues with the v3.8 global 
dictionary implementation that I've never gotten sorted. (I believe the 
local dictionary implementation in V3.8 is OK / clean.)

Bill P.

(*) - The declare feature identifiers, image_width, image_height and 
maybe a half dozen more 'apparent keywords' are, internally, unprotected 
identifiers. This is an opening for difficult SDL bugs. This said, I 
don't plan to delete these 'apparent keywords' any time soon. I do plan 
to remove the declare option.

(**) - Yes, need sanity checking to be sure users don't try to set 
'option strings' via any of these user input files...

Post a reply to this message

On 12.06.2025 05:21, William F Pokorny wrote:
> (*) - The declare feature identifiers, image_width, image_height and 
> maybe a half dozen more 'apparent keywords' are, internally, unprotected 
> identifiers. This is an opening for difficult SDL bugs. This said, I 
> don't plan to delete these 'apparent keywords' any time soon. I do plan 
> to remove the declare option.

There is a good reason these are identifiers and not keywords (any 
more). The architecture had a lot of separation issues in POV-Ray 3.6, 
MegaPOV and before that kept getting worse, and prohibited a lot of 
features that are useful.

The most notable is that the scene and the rendering can be separated. 
That is, you do not need to re-parse a potentially complex scene for 
hours just the render it in a higher resolution. There isn't even a 
reason to not move the camera after parsing (as the real-time 
ray-tracing feature shows).

The main problem has always been that a GUI was never developed for 
these features. So the question you probably want to ask yourself it if 
it really makes sense to throw all this overboard for an extremely 
complex command-line interface...?

Post a reply to this message

On 6/13/25 07:38, Thorsten wrote:
> There is a good reason these are identifiers and not keywords (any 
> more). The architecture had a lot of separation issues in POV-Ray 3.6, 
> MegaPOV and before that kept getting worse, and prohibited a lot of 
> features that are useful.
> 
> The most notable is that the scene and the rendering can be separated. 
> That is, you do not need to re-parse a potentially complex scene for 
> hours just the render it in a higher resolution. There isn't even a 
> reason to not move the camera after parsing (as the real-time ray- 
> tracing feature shows).
> 
> The main problem has always been that a GUI was never developed for 
> these features. So the question you probably want to ask yourself it if 
> it really makes sense to throw all this overboard for an extremely 
> complex command-line interface...?

As always thank you for the background. I think I followed most of what 
you wrote. I expect my inability to write clearly has led to some 
confusion too. I'm sure too, I don't see all the obstacles I might 
encounter or introduce as I try and complete this re-work...

It's also true my ideas for the user command-lind / ini 'options' in 
this thread are some of the least developed / refined of my re-work effort.

As you know, the only method which doesn't require near-complete 
re-parsing of scenes for each frame today is the rtr camera list one. It 
might be the view internal code aspect is further along that my quick 
read-overs have led me to think, but it's not something working today 
for users beyond setting up an initial 'view' / camera view.

In other words, I'm not aware of any 'working method' to implement your 
example of rendering a scene again at a higher resolution without 
re-running the entire render - including too the cli/ini options parsing(*).

(*) You can distort each animation's frame images by twiddling with the 
image_height and image_width identifier values if, for example, these 
'pretend keywords' have been used to defined the camera. But, this 
capability also touches on the exposure carried with the current 
implementation.

What I'm re-working in these last couple months is setting more things 
up in the options parsing which runs prior to the virtual front end 
(vfe) starting. The 10 or 12 'pretend keywords' / identifiers like 
image_width are set as vfe starts today. Nothing with respect to that 
will change any time soon due the re-worked options.

In aiming to move the global_settings{} block stuff into the 'options' 
cli/ini parsing code, for example, I am pushing more 'keywords' out of 
the parser and into the options parsing as flags / ini-options where 
they'll get digested once rather than for each frame as our code stands 
today.

With respect to this thread in particular and the cli/ini declare=<id>=
option, I'm talking about changing / extending what today might be done 
in an ini file with a set of lines like:

declare=Int00=111
declare=Int01=222
declare=Int02=333.456

and parsed during the options setting phase with, say, 
'include_ini=MyInts.ini'.

With the planned approach in this thread it would become instead a file 
with the lines:

Int00 111
Int01 222
Int02 333.456

and

+-ui_"MyInts.ini"

Except I can now type check the input values and they become something 
read only accessible as global integers inside the parser (via parser 
functions). There is, of course, some effective 'look up the value' 
process whether done via a function call or parser identifier access.

Aside: Though I don't plan to go this way at present, a hybrid approach 
is possible - whether declare=.=. or as this new alternate +-ui_ method 
- nothing stops us from setting identifiers Int00, Int01 and Int02 to 
integer values before the parser runs in addition to enabling the parser 
function accessible method or even in place of it.

Lastly, I've only ever really used POV-Ray on linux/unix/aix systems. 
I'm not familiar with the windows (or osx) POV-Ray GUIs and expect I'm 
largely ignorant of most GUI support implications in general.

A reminder the yuqk fork is a linux/unix only v4 playpen - though 
hopefully mac/osx compiles work too.

Bill P.

Post a reply to this message

On 13.06.2025 22:34, William F Pokorny wrote:
> What I'm re-working in these last couple months is setting more things 
> up in the options parsing which runs prior to the virtual front end 
> (vfe) starting. The 10 or 12 'pretend keywords' / identifiers like 
> image_width are set as vfe starts today. Nothing with respect to that 
> will change any time soon due the re-worked options.

vfe is just a layer over the actual interface needed primarily for 
Windows. The actual main in povmain.cpp contains a minimal viable 
version of what is actually needed based on RenderFrontend, which does 
have all the states needed:

SceneId CreateScene(...) // create as many as you like
   StartParser(SceneId, ...) // run as many as you like
   ViewId CreateView(SceneId, ...) // create as many as you like
     StartRender(ViewId, ...) // run as many as you like

You can run multiple parsers and multiple renders all at the same time.

Chris Cason implemented vfe originally based on my SimpleFrontend, which 
provides a single scene, single render backward-compatible interface 
because at the time we didn't have time to adapt the legacy GUIs.

Thorsten

Post a reply to this message

On 6/18/25 14:46, Thorsten wrote:
> Chris Cason implemented vfe originally based on my SimpleFrontend, which 
> provides a single scene, single render backward-compatible interface 
> because at the time we didn't have time to adapt the legacy GUIs.

Thank you Thorsten!

I'd worked out the SimpleFrontend was mostly not used while working on 
the yuqk fork. However, given ALTMAIN, I took it as a, long ago, 
intended, fall-back build from the platform dependent vfe 
implementations(*).

Aside: The yuqk fork's simplefrontend.h is mostly commented today, but a 
couple parts are necessary for vfe and the unix/linux build.

Bill P.

(*) - I've never gotten around to trying to get a build without vfe --> 
unix & ALTMAIN going. Having a single threaded and minimal, 
text-only(**) build would be useful / good to have.

(**) - 'text' is an option of unix/linux builds, but as the preview display.

Post a reply to this message

On 19.06.2025 13:29, William F Pokorny wrote:
> (*) - I've never gotten around to trying to get a build without vfe --> 
> unix & ALTMAIN going. Having a single threaded and minimal, 
> text-only(**) build would be useful / good to have.

It exists for a simple reason: That is what I used for a lot of early 
development of 3.7, testing on a iBook (MacOS with PowerPC) and Windows 
at the same time (but Chris did most of the Windows work).

Thorsten

Post a reply to this message