Running Lux 0.8 in quiet mode. How?

[pciccone]

Hi.

As Lux 0.8 has changed command-line parameters I'm not able to suppress the "inconsistent normals" messages, which I used to do by using 0.7's "-V 2"
I tried the --quiet option and it doesn't quiet Lux enough. Is there a way of suppressing all those warnings?

Thanks in advance.

[jeanphi]

Hi,

You can give the --quiet or -q option twice to suppress warnings too.

Jeanphi

[dougal2]

Hi,

You can give the --quiet or -q option twice to suppress warnings too.

Jeanphi

Actually, that's not true - boost::program_options was unable to detect/parse giving the same option twice. We probably need another option like --very-quiet.

[pciccone]

Yes, I asked here after looking at the latest code. I saw the comment in it but using the option twice shorts with a "multiple instances" message.
Here is another issue. When people run Lux from Reality everything is ok, the messages are suppressed and life is peachy . If they run the network render or redraft the rendering they get a flood of those messages in the log window. I answered dozens of tech support questions about it. It keeps popping up in the forums alarming people that some could be wrong in their scenes.

I don't want to start an argument, I don't have the math skills to sustain it, but practice and hundreds of renders have shown that those messages are out of place. The models provided from Studio render perfectly ok and there are no practical issues with the normals. I appreciate the reason behind the warning but I believe that the default should be to have them off and have the warning show only if a given flag is used. Would you consider this option? I'm not asking to remove them but to simply need an option to show them.
The advantages of that approach are multiple. Start time is reduced, those messages take time to be added to the log. Important messages become visible as Hundreds of messages about the normals make it very hard to find other information. And lastly, for the majority of the cases, there is no alarm for the users. Suppressing them by default would be a big usability improvement.
Please consider this option.

Thanks!

[jeanphi]

Hi,

I think I've found a workaround to be able to specify options twice.

Jeanphi

[dougal2]

I'm just lagging a bit behind jeanphi ....


I've just added the -x/--very-quiet option as a workaround for the time being. Usage:

Code: Select all

>>> luxconsole.exe --help
[Lux 2011-Jan-06 16:14:07 ERROR : 2] Usage: luxconsole [options] file...
Allowed options:

Generic options:
  -v [ --version ]            Print version string
  -h [ --help ]               Produce help message
  -r [ --resume ] arg         Resume from FLM
  -R [ --overrideresume ] arg Resume from specified FLM
  -s [ --server ]             Launch in server mode
  -b [ --bindump ]            Dump binary RGB framebuffer to stdout when
                              finished
  -d [ --debug ]              Enable debug mode
  -f [ --fixedseed ]          Disable random seed mode
  -e [ --minepsilon ] arg     Set minimum epsilon
  -E [ --maxepsilon ] arg     Set maximum epsilon
  -V [ --verbose ]            Increase output verbosity (show DEBUG messages)
  -q [ --quiet ]              Reduce output verbosity (hide INFO messages)
  -x [ --very-quiet ]         Reduce output verbosity even more (hide WARNING
                              messages)

Configuration:
  -t [ --threads ] arg        Specify the number of threads that Lux will run
                              in parallel.
  -u [ --useserver ] arg      Specify the adress of a rendering server to use.
  -i [ --serverinterval ] arg Specify the number of seconds between requests to
                              rendering servers.
  -p [ --serverport ] arg     Specify the tcp port used in server mode.
  -W [ --serverwriteflm ]     Write film to disk before transmitting in server
                              mode.


You don't need to specify -q and -x, just -x alone will do and it should behave the same as the old -V 2 option.

[pciccone]

Thank you Doug, very much appreciated.

[jeanphi]

Hi,

After lots of testing, I abandon. Let's keep this -x flag.
However I don't remember the rationale behind the -V option behaviour change. It might be even better to revert to the previous scheme.

Jeanphi

[dougal2]

I felt that the -V <number> option was cryptic and unintuitive. It worked in reverse, such that a large 'verbosity' value would produce less output, and the numbering was more or less arbitrary (derived from LUX_* constants, but meaningless to end-users).

[jeanphi]

Hi,

Ok so changing the behaviour of the numeric value to be consistent would have been a suprise.
Maybe this is still what we should do? Keep the old option scheme but increase verbosity with increasing values?

Jeanphi