The .met files are the hand-build ASCII originals. The .mta files are the converted binary files needed by the other programs. So, the .met files are sources in other words.
-Greg > From: Georg Mischler <[email protected]> > Subject: Re: [Radiance-dev] Meta files and library > Date: May 10, 2016 1:35:15 PM PDT > > To add to the confusion, the distribution (via CVS) includes two of the > files with a *.met extension in ray/src/meta/. > Makeall installs those in parallel and redundantly to the *.mta files > coming with rad5R0supp.tar.gz. The executables are only looking for the > *.mta versions, though. > > Cheers > -schorsch > > Am 2016-05-10 16:44, schrieb Guglielmetti, Robert: >> I thought this got resolved with the NREL packages, but I guess not. I >> don't see anything in the commit history where I had changed/fixed >> anything in the CMake files so I think we still have an issue here. >> Sarith, what version of the NREL installer are you currently using, where >> objline does not work? >> I agree with Schorsch, if we could use a standard vector format for this >> it would be nice... >> On 5/10/16, 2:02 AM, "Georg Mischler" <[email protected]> wrote: >>> Hi, >>> our volunteer Sarith Subramaniam is currently working on objline.py. >>> When trying to test it, he noticed that the NREL releases do not include >>> the supporting meta files in lib/meta. Since they do include the >>> executables that require those files, that seems slightly suboptimal... >>> But it shouldn't be hard to fix. Just copy over "ray/lib/meta/*.mta". >>> I've found a previous mention of the topic here: >>> http://radiance-online.org/pipermail/radiance-general/2015-October/011273. >>> html >>> Some unsorted thoughts on the topic of meta files in general, given that >>> due to the availability of objline.csh/py, and some newer tutorials, >>> they >>> will inevitably get more attention in times to come: >>> A few messages down the above thread, Greg mentions the undocumented(!) >>> envvar "MLIB". The first thing running through my mind seeing this was: >>> "This must be the worst possible name for an environment variable, ever" >>> (way to generic). >>> I also never quite understood the point of inventing yet another >>> proprietary vector format just for Radiance. Or are such meta files used >>> anywhere else that I'm not aware of? >>> They do not seem to be the same as the ISO standardized "Computer >>> Graphics >>> Meta Files" (http://www.fileformat.info/format/cgm/egff.htm), which >>> would >>> be a possible candidate for something like that. >>> Another possible approach would be SVG (or a suitable subset thereof), >>> which has excellent support libaries available nowadays. >>> Of course, I haven't looked into how much work it would be to use either >>> of those (or yet something else), so this basically just amounts to me >>> ranting at the moment without any real purpose. But I'm still just >>> curious >>> what the motivation behind this format was (or which format it actually >>> is), and what other people are thinking about possible alternatives. >>> Cheers >>> -schorsch >>> -- >>> Georg Mischler -- simulations developer -- schorsch at schorsch com >>> +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ >>> _______________________________________________ >>> Radiance-dev mailing list >>> [email protected] >>> http://www.radiance-online.org/mailman/listinfo/radiance-dev >> _______________________________________________ >> Radiance-dev mailing list >> [email protected] >> http://www.radiance-online.org/mailman/listinfo/radiance-dev > > -- > Georg Mischler -- simulations developer -- schorsch at schorsch com > +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ > > _______________________________________________ > Radiance-dev mailing list > [email protected] > http://www.radiance-online.org/mailman/listinfo/radiance-dev _______________________________________________ Radiance-dev mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/radiance-dev
