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