On 2/4/24 16:17, Kenneth wrote:
> Although you mentioned running 3.8 beta 2, I decided to test your examples plus
> your command-line  +mv3.7 additions in 3.8 beta 1 (Windows)-- just to see if the
> behavior and returned parse warnings are the same. They all are-- except for the
> 'extra' warnings you mentioned "after bounding completes, the following
> happens..." Those do not appear. I guess that's a slight change between beta 1
> and beta 2.

Hmm. The yuqk fork 'branched off' in early 2019. The v3.8 beta 2 code 
and yuqk both have this code in the common to all executable(s) in the 
source/frontend/renderfrontend.h file. So, I'd bet against a code change 
being the reason you don't see the additional warning, but?

When running in a unix / linux terminal all the output comes back to the 
terminal where it's perhaps separated in the windows interface? <-- My 
only guess is the output is going somewhere unexpected or going 'poof' 
on windows.

> 
> [BTW: I noticed that your command-line switch for #version has an extra period
> or decimal point--  +mv.3.7  -- whereas the documentation says  +mv3.7. But
> either one seems to work OK, which surprised me.]

That's me making a typo. I checked my command history and the extra '.' 
isn't there in what I ran.

Aside: Using +mv.3.7 doesn't come back with an error (neither does 
version=.3.7). It, rather, sets the version to 1.0. Probably because a 
simple atof() is being used and the value comes in at 0.3 or similar.
Looks like the upper range isn't protected either.

I tried version=999 and surprisingly things run quickly:

"AI active. Quantum computing virtual machine version 77.3.5.1.
...
All scenes you've ever written or imagined have been rendered with every 
possible advanced option on. Output images and animations have been 
saved to your google cloud drive. Please login into your google account 
for a chat with AI_LittleIcePick12. Storage charges have exceeded 
existing credit limits and an immediate payment is due."

More seriously, I'll look at at least clamping the version range to 
something more reasonable in yuqk. Maybe extend the trial c+11 regexp 
flag checker to do more - but I've not played with that code now in years...

> 
> Actually, the ini/command-line switches for a scene's #version (and/or
> assumed_gamma) is something that I have never used; instead, I always explicitly
> state those in my scenes. But from what you mentioned here and in another recent
> thread, I get the feeling that the switches are the 'proper' way to do it-- to
> override(?) what might already be in a scene, and to avoid any possible (or
> difficult-to-track-down) problems that might crop up. Are my assumptions
> correct?
> 

If things were only black and white...

It's the direction in which I'm trying to push yuqk. For v3.8 beta 2, 
probably, it's safer to specify as a command line flag or ini option 
with the same version specified as the first line #version of your scene 
file than not. I've yet to see any evidence doing it hurts and it 
sometimes helps.

Another place the +mv sort of version spec is necessary is with the 
unspecified default camera. Meaning with the following sort of set up:

//---
#version 3.7;
global_settings { assumed_gamma 1.0 }
plane { -z, -1 pigment {rgb <1,1,0>} }
//...
#version 3.5;
sphere { <0,0,1.0> , 0.1
     pigment { rgb <0,0,1> }
     finish { emission 1 } // Yes, this generates a warning.
}
// camera {} // Specified default camera grabs current version defaults
//---        // and its use is what is seen in the right three columns

Without writing a small chapter, the second and third columns of the 
attached test image show that the ini / flag version setting is used 
when there is a leading #version statement in the scene code - over the 
version specified in that #version statement (or defaulted version).

> If so, I am curious about your c.pov example:
> 
> // c.pov file
> #version 3.7;
> global_settings { assumed_gamma 1.0 }
> //...
> #version 3.5;
> sphere { 0, 1 }
> 
> Does adding a command-line switch like +mv3.8 override BOTH of the explicit
> #version settings there? 

Certainly not for most things, but for some smaller set things / 
situations, yes.

> I have to admit that I am rather naive about all of
> this #version business and the various possible interactions.
> 

Me too! :-)

Bill P.

Post a reply to this message

Attachments:
Download 'storyverflag.jpg' (36 KB)

Preview of image 'storyverflag.jpg'