mgf2inv VRML export

radiance-dev
1

Hi Greg, hi list,

from time to time I am using mgf2inv with the "-vrml" option to export and
view my models.

This time I wanted to do the conversion with rad2mgf and mgf2inv -vrml on
Windows using the
NREL binaries. However, the resulting files are corrupt due to bad number
representations and
normal descriptions.

For example the description of a face in the VRML-file created with the
Linux binaries is:*

DEF ceil_fac_001 Group {
  Separator {
    USE ceil_mat
    Coordinate3 {
      point [ -2.000000000e+00 +4.500000000e+00 +2.162119874e+00,
              -1.500000000e+00 +4.500000000e+00 +3.000000000e+00,
              -1.500000000e+00 +5.000000000e+00 +1.461123454e+00,
              -2.000000000e+00 +5.000000000e+00 +6.232433278e-01 ]
    }
    IndexedFaceSet {
      coordIndex [ 0, 1, 2, 3 ]
    }
  }
}

···

*

In the files created with the Windows version the same face is described as:
*
DEF ceil_fac_001 Group {
  Separator {
    USE ceil_mat
    Coordinate3 {
      point [ -2.000000000e+000 +4.500000000e+000 +2.162119874e+,
              -1.500000000e+000 +4.500000000e+000 +3.000000000e+,
              -1.500000000e+000 +5.000000000e+000 +1.461123454e+,
              -2.000000000e+000 +5.000000000e+000 +6.232433278e- ]
    }
    Normal {
      vector [ 00
+0.000 +0.000 +0.0-1.500000000e+000 +4.500000000e+000 +3.000000000e+,
               00
+0.000 +0.000 +0.0-1.500000000e+000 +5.000000000e+000 +1.461123454e+,
               00
+0.000 +0.000 +0.0-2.000000000e+000 +5.000000000e+000 +6.232433278e-,
               01
+0.000 +0.000 +0.000 ]
    }
    IndexedFaceSet {
      coordIndex [ 0, 1, 2, 3 ]
      normalIndex [ 0, 1, 2, 3 ]
    }
  }
}

*Obviously, two things are corrupt:
- the z-coordinates are missing their exponents
- the normal vector coordinates are messed up

Moreover, for me it's unclear why normal vectors are written (needed ??) in
the Windows version, while
they are completely missing in the Linux version.

I believe that all this has something to do with de definition of VERTFMT
in src/cv/mgf2inv.c
*#define VERTFMT "%+16.9e %+16.9e %+16.9e\n%+6.3f %+6.3f %+6.3f"*

Any ideas how to solve that for both platforms??

Cheers,
David

2

Hi David,

AFAIK, the sources for those two programs were not touched in the Windows binary project. I don't fully understand the behavior of this program right now. I will check with Kitware to see if any changes were in fact made to that source in order to get it to work on Windows.

Rob Guglielmetti IESNA, LEED AP
Commercial Buildings Research Group
National Renewable Energy Laboratory
15013 Denver West Parkway MS:RSF202
Golden, CO 80401
303.275.4319
[email protected]

···

On 4/30/12 6:35 AM, "David Geisler-Moroder" <[email protected]<mailto:[email protected]>> wrote:

Hi Greg, hi list,

from time to time I am using mgf2inv with the "-vrml" option to export and view my models.

This time I wanted to do the conversion with rad2mgf and mgf2inv -vrml on Windows using the
NREL binaries. However, the resulting files are corrupt due to bad number representations and
normal descriptions.

For example the description of a face in the VRML-file created with the Linux binaries is:

DEF ceil_fac_001 Group {
  Separator {
    USE ceil_mat
    Coordinate3 {
      point [ -2.000000000e+00 +4.500000000e+00 +2.162119874e+00,
              -1.500000000e+00 +4.500000000e+00 +3.000000000e+00,
              -1.500000000e+00 +5.000000000e+00 +1.461123454e+00,
              -2.000000000e+00 +5.000000000e+00 +6.232433278e-01 ]
    }
    IndexedFaceSet {
      coordIndex [ 0, 1, 2, 3 ]
    }
  }
}

In the files created with the Windows version the same face is described as:

DEF ceil_fac_001 Group {
  Separator {
    USE ceil_mat
    Coordinate3 {
      point [ -2.000000000e+000 +4.500000000e+000 +2.162119874e+,
              -1.500000000e+000 +4.500000000e+000 +3.000000000e+,
              -1.500000000e+000 +5.000000000e+000 +1.461123454e+,
              -2.000000000e+000 +5.000000000e+000 +6.232433278e- ]
    }
    Normal {
      vector [ 00
+0.000 +0.000 +0.0-1.500000000e+000 +4.500000000e+000 +3.000000000e+,
               00
+0.000 +0.000 +0.0-1.500000000e+000 +5.000000000e+000 +1.461123454e+,
               00
+0.000 +0.000 +0.0-2.000000000e+000 +5.000000000e+000 +6.232433278e-,
               01
+0.000 +0.000 +0.000 ]
    }
    IndexedFaceSet {
      coordIndex [ 0, 1, 2, 3 ]
      normalIndex [ 0, 1, 2, 3 ]
    }
  }
}

Obviously, two things are corrupt:
- the z-coordinates are missing their exponents
- the normal vector coordinates are messed up

Moreover, for me it's unclear why normal vectors are written (needed ??) in the Windows version, while
they are completely missing in the Linux version.

I believe that all this has something to do with de definition of VERTFMT in src/cv/mgf2inv.c
#define VERTFMT "%+16.9e %+16.9e %+16.9e\n%+6.3f %+6.3f %+6.3f"

Any ideas how to solve that for both platforms??

Cheers,
David

3

Hi David,

I found the problem, and can figure out how to fix it. The code assumes that exponents have two digits only, which is still true on most Unix machines. I guess they're making room for "long double's" (128-bit IEEE float) and don't have different code for that than the "regular" doubles.

I will check in a fix later today -- thanks so much for spotting this.

Cheers,
-Greg

···

From: "Guglielmetti, Robert" <[email protected]>
Date: April 30, 2012 8:41:17 AM PDT

Hi David,

AFAIK, the sources for those two programs were not touched in the Windows binary project. I don't fully understand the behavior of this program right now. I will check with Kitware to see if any changes were in fact made to that source in order to get it to work on Windows.

Rob Guglielmetti IESNA, LEED AP

On 4/30/12 6:35 AM, "David Geisler-Moroder" <[email protected]<mailto:[email protected]>> wrote:

Hi Greg, hi list,

from time to time I am using mgf2inv with the "-vrml" option to export and view my models.

This time I wanted to do the conversion with rad2mgf and mgf2inv -vrml on Windows using the
NREL binaries. However, the resulting files are corrupt due to bad number representations and
normal descriptions.

For example the description of a face in the VRML-file created with the Linux binaries is:

DEF ceil_fac_001 Group {
Separator {
   USE ceil_mat
   Coordinate3 {
     point [ -2.000000000e+00 +4.500000000e+00 +2.162119874e+00,
             -1.500000000e+00 +4.500000000e+00 +3.000000000e+00,
             -1.500000000e+00 +5.000000000e+00 +1.461123454e+00,
             -2.000000000e+00 +5.000000000e+00 +6.232433278e-01 ]
   }
   IndexedFaceSet {
     coordIndex [ 0, 1, 2, 3 ]
   }
}
}

In the files created with the Windows version the same face is described as:

DEF ceil_fac_001 Group {
Separator {
   USE ceil_mat
   Coordinate3 {
     point [ -2.000000000e+000 +4.500000000e+000 +2.162119874e+,
             -1.500000000e+000 +4.500000000e+000 +3.000000000e+,
             -1.500000000e+000 +5.000000000e+000 +1.461123454e+,
             -2.000000000e+000 +5.000000000e+000 +6.232433278e- ]
   }
   Normal {
     vector [ 00
+0.000 +0.000 +0.0-1.500000000e+000 +4.500000000e+000 +3.000000000e+,
              00
+0.000 +0.000 +0.0-1.500000000e+000 +5.000000000e+000 +1.461123454e+,
              00
+0.000 +0.000 +0.0-2.000000000e+000 +5.000000000e+000 +6.232433278e-,
              01
+0.000 +0.000 +0.000 ]
   }
   IndexedFaceSet {
     coordIndex [ 0, 1, 2, 3 ]
     normalIndex [ 0, 1, 2, 3 ]
   }
}
}

Obviously, two things are corrupt:
- the z-coordinates are missing their exponents
- the normal vector coordinates are messed up

Moreover, for me it's unclear why normal vectors are written (needed ??) in the Windows version, while
they are completely missing in the Linux version.

I believe that all this has something to do with de definition of VERTFMT in src/cv/mgf2inv.c
#define VERTFMT "%+16.9e %+16.9e %+16.9e\n%+6.3f %+6.3f %+6.3f"

Any ideas how to solve that for both platforms??

Cheers,
David

4

Hi Greg, Rob,

thanks a lot for the quick responses and for the fix!

However, I need to wait for the new NREL-binaries to use the fixed version
(or maybe finally step into the CMake thing to get the Windows bins
compiled by myself... :wink: ).

Cheers,
David

···

2012/4/30 Gregory J. Ward <[email protected]>

Hi David,

I found the problem, and can figure out how to fix it. The code assumes
that exponents have two digits only, which is still true on most Unix
machines. I guess they're making room for "long double's" (128-bit IEEE
float) and don't have different code for that than the "regular" doubles.

I will check in a fix later today -- thanks so much for spotting this.

Cheers,
-Greg

> From: "Guglielmetti, Robert" <[email protected]>
> Date: April 30, 2012 8:41:17 AM PDT
>
> Hi David,
>
> AFAIK, the sources for those two programs were not touched in the
Windows binary project. I don't fully understand the behavior of this
program right now. I will check with Kitware to see if any changes were in
fact made to that source in order to get it to work on Windows.
>
> Rob Guglielmetti IESNA, LEED AP
>
>
> On 4/30/12 6:35 AM, "David Geisler-Moroder" <[email protected] > <mailto:[email protected]>> wrote:
>
> Hi Greg, hi list,
>
> from time to time I am using mgf2inv with the "-vrml" option to export
and view my models.
>
> This time I wanted to do the conversion with rad2mgf and mgf2inv -vrml
on Windows using the
> NREL binaries. However, the resulting files are corrupt due to bad
number representations and
> normal descriptions.
>
> For example the description of a face in the VRML-file created with the
Linux binaries is:
>
> DEF ceil_fac_001 Group {
> Separator {
> USE ceil_mat
> Coordinate3 {
> point [ -2.000000000e+00 +4.500000000e+00 +2.162119874e+00,
> -1.500000000e+00 +4.500000000e+00 +3.000000000e+00,
> -1.500000000e+00 +5.000000000e+00 +1.461123454e+00,
> -2.000000000e+00 +5.000000000e+00 +6.232433278e-01 ]
> }
> IndexedFaceSet {
> coordIndex [ 0, 1, 2, 3 ]
> }
> }
> }
>
>
> In the files created with the Windows version the same face is described
as:
>
> DEF ceil_fac_001 Group {
> Separator {
> USE ceil_mat
> Coordinate3 {
> point [ -2.000000000e+000 +4.500000000e+000 +2.162119874e+,
> -1.500000000e+000 +4.500000000e+000 +3.000000000e+,
> -1.500000000e+000 +5.000000000e+000 +1.461123454e+,
> -2.000000000e+000 +5.000000000e+000 +6.232433278e- ]
> }
> Normal {
> vector [ 00
> +0.000 +0.000 +0.0-1.500000000e+000 +4.500000000e+000 +3.000000000e+,
> 00
> +0.000 +0.000 +0.0-1.500000000e+000 +5.000000000e+000 +1.461123454e+,
> 00
> +0.000 +0.000 +0.0-2.000000000e+000 +5.000000000e+000 +6.232433278e-,
> 01
> +0.000 +0.000 +0.000 ]
> }
> IndexedFaceSet {
> coordIndex [ 0, 1, 2, 3 ]
> normalIndex [ 0, 1, 2, 3 ]
> }
> }
> }
>
>
> Obviously, two things are corrupt:
> - the z-coordinates are missing their exponents
> - the normal vector coordinates are messed up
>
> Moreover, for me it's unclear why normal vectors are written (needed ??)
in the Windows version, while
> they are completely missing in the Linux version.
>
> I believe that all this has something to do with de definition of
VERTFMT in src/cv/mgf2inv.c
> #define VERTFMT "%+16.9e %+16.9e %+16.9e\n%+6.3f %+6.3f %+6.3f"
>
> Any ideas how to solve that for both platforms??
>
> Cheers,
> David

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
DI Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck

5

Hi David,

I am trying to sort out two other issues with the Windows binaries, but I can push out a new Windows installer tomorrow morning for you with this fix. We can talk offline if you want to talk about getting up and running with CMake, too.

Rob Guglielmetti IESNA, LEED AP
Commercial Buildings Research Group
National Renewable Energy Laboratory
15013 Denver West Parkway MS:RSF202
Golden, CO 80401
303.275.4319
[email protected]

Hi Greg, Rob,

thanks a lot for the quick responses and for the fix!

However, I need to wait for the new NREL-binaries to use the fixed version (or maybe finally step into the CMake thing to get the Windows bins compiled by myself... :wink: ).

Cheers,
David

2012/4/30 Gregory J. Ward <[email protected]<mailto:[email protected]>>
Hi David,

I found the problem, and can figure out how to fix it. The code assumes that exponents have two digits only, which is still true on most Unix machines. I guess they're making room for "long double's" (128-bit IEEE float) and don't have different code for that than the "regular" doubles.

I will check in a fix later today -- thanks so much for spotting this.

Cheers,
-Greg

···

On 4/30/12 2:11 PM, "David Geisler-Moroder" <[email protected]<mailto:[email protected]>> wrote:

From: "Guglielmetti, Robert" <[email protected]<mailto:[email protected]>>
Date: April 30, 2012 8:41:17 AM PDT

Hi David,

AFAIK, the sources for those two programs were not touched in the Windows binary project. I don't fully understand the behavior of this program right now. I will check with Kitware to see if any changes were in fact made to that source in order to get it to work on Windows.

Rob Guglielmetti IESNA, LEED AP

On 4/30/12 6:35 AM, "David Geisler-Moroder" <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote:

Hi Greg, hi list,

from time to time I am using mgf2inv with the "-vrml" option to export and view my models.

This time I wanted to do the conversion with rad2mgf and mgf2inv -vrml on Windows using the
NREL binaries. However, the resulting files are corrupt due to bad number representations and
normal descriptions.

For example the description of a face in the VRML-file created with the Linux binaries is:

DEF ceil_fac_001 Group {
Separator {
   USE ceil_mat
   Coordinate3 {
     point [ -2.000000000e+00 +4.500000000e+00 +2.162119874e+00,
             -1.500000000e+00 +4.500000000e+00 +3.000000000e+00,
             -1.500000000e+00 +5.000000000e+00 +1.461123454e+00,
             -2.000000000e+00 +5.000000000e+00 +6.232433278e-01 ]
   }
   IndexedFaceSet {
     coordIndex [ 0, 1, 2, 3 ]
   }
}
}

In the files created with the Windows version the same face is described as:

DEF ceil_fac_001 Group {
Separator {
   USE ceil_mat
   Coordinate3 {
     point [ -2.000000000e+000 +4.500000000e+000 +2.162119874e+,
             -1.500000000e+000 +4.500000000e+000 +3.000000000e+,
             -1.500000000e+000 +5.000000000e+000 +1.461123454e+,
             -2.000000000e+000 +5.000000000e+000 +6.232433278e- ]
   }
   Normal {
     vector [ 00
+0.000 +0.000 +0.0-1.500000000e+000 +4.500000000e+000 +3.000000000e+,
              00
+0.000 +0.000 +0.0-1.500000000e+000 +5.000000000e+000 +1.461123454e+,
              00
+0.000 +0.000 +0.0-2.000000000e+000 +5.000000000e+000 +6.232433278e-,
              01
+0.000 +0.000 +0.000 ]
   }
   IndexedFaceSet {
     coordIndex [ 0, 1, 2, 3 ]
     normalIndex [ 0, 1, 2, 3 ]
   }
}
}

Obviously, two things are corrupt:
- the z-coordinates are missing their exponents
- the normal vector coordinates are messed up

Moreover, for me it's unclear why normal vectors are written (needed ??) in the Windows version, while
they are completely missing in the Linux version.

I believe that all this has something to do with de definition of VERTFMT in src/cv/mgf2inv.c
#define VERTFMT "%+16.9e %+16.9e %+16.9e\n%+6.3f %+6.3f %+6.3f"

Any ideas how to solve that for both platforms??

Cheers,
David

_______________________________________________
Radiance-dev mailing list
[email protected]<mailto:[email protected]>
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
DI Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck

6

Does this mean the Radiance CMake environment is available for general consumption?

Palbinder Sandher
Software Platform Engineer
T:+44 (0) 141 945 8500
F:+44 (0) 141 945 8501
http://www.iesve.com

**Design, Simulate + Innovate with the <Virtual Environment>**
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP
Email Disclaimer

···

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]]
Sent: 30 April 2012 22:28
To: code development
Subject: Re: [Radiance-dev] mgf2inv VRML export

Hi David,

I am trying to sort out two other issues with the Windows binaries, but I can push out a new Windows installer tomorrow morning for you with this fix. We can talk offline if you want to talk about getting up and running with CMake, too.

Rob Guglielmetti IESNA, LEED AP
Commercial Buildings Research Group
National Renewable Energy Laboratory
15013 Denver West Parkway MS:RSF202
Golden, CO 80401
303.275.4319
[email protected]

On 4/30/12 2:11 PM, "David Geisler-Moroder" <[email protected]<mailto:[email protected]>> wrote:

Hi Greg, Rob,

thanks a lot for the quick responses and for the fix!

However, I need to wait for the new NREL-binaries to use the fixed version (or maybe finally step into the CMake thing to get the Windows bins compiled by myself... :wink: ).

Cheers,
David

2012/4/30 Gregory J. Ward <[email protected]<mailto:[email protected]>>
Hi David,

I found the problem, and can figure out how to fix it. The code assumes that exponents have two digits only, which is still true on most Unix machines. I guess they're making room for "long double's" (128-bit IEEE float) and don't have different code for that than the "regular" doubles.

I will check in a fix later today -- thanks so much for spotting this.

Cheers,
-Greg

From: "Guglielmetti, Robert" <[email protected]<mailto:[email protected]>>
Date: April 30, 2012 8:41:17 AM PDT

Hi David,

AFAIK, the sources for those two programs were not touched in the Windows binary project. I don't fully understand the behavior of this program right now. I will check with Kitware to see if any changes were in fact made to that source in order to get it to work on Windows.

Rob Guglielmetti IESNA, LEED AP

On 4/30/12 6:35 AM, "David Geisler-Moroder" <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote:

Hi Greg, hi list,

from time to time I am using mgf2inv with the "-vrml" option to export and view my models.

This time I wanted to do the conversion with rad2mgf and mgf2inv -vrml on Windows using the
NREL binaries. However, the resulting files are corrupt due to bad number representations and
normal descriptions.

For example the description of a face in the VRML-file created with the Linux binaries is:

DEF ceil_fac_001 Group {
Separator {
   USE ceil_mat
   Coordinate3 {
     point [ -2.000000000e+00 +4.500000000e+00 +2.162119874e+00,
             -1.500000000e+00 +4.500000000e+00 +3.000000000e+00,
             -1.500000000e+00 +5.000000000e+00 +1.461123454e+00,
             -2.000000000e+00 +5.000000000e+00 +6.232433278e-01 ]
   }
   IndexedFaceSet {
     coordIndex [ 0, 1, 2, 3 ]
   }
}
}

In the files created with the Windows version the same face is described as:

DEF ceil_fac_001 Group {
Separator {
   USE ceil_mat
   Coordinate3 {
     point [ -2.000000000e+000 +4.500000000e+000 +2.162119874e+,
             -1.500000000e+000 +4.500000000e+000 +3.000000000e+,
             -1.500000000e+000 +5.000000000e+000 +1.461123454e+,
             -2.000000000e+000 +5.000000000e+000 +6.232433278e- ]
   }
   Normal {
     vector [ 00
+0.000 +0.000 +0.0-1.500000000e+000 +4.500000000e+000 +3.000000000e+,
              00
+0.000 +0.000 +0.0-1.500000000e+000 +5.000000000e+000 +1.461123454e+,
              00
+0.000 +0.000 +0.0-2.000000000e+000 +5.000000000e+000 +6.232433278e-,
              01
+0.000 +0.000 +0.000 ]
   }
   IndexedFaceSet {
     coordIndex [ 0, 1, 2, 3 ]
     normalIndex [ 0, 1, 2, 3 ]
   }
}
}

Obviously, two things are corrupt:
- the z-coordinates are missing their exponents
- the normal vector coordinates are messed up

Moreover, for me it's unclear why normal vectors are written (needed ??) in the Windows version, while
they are completely missing in the Linux version.

I believe that all this has something to do with de definition of VERTFMT in src/cv/mgf2inv.c
#define VERTFMT "%+16.9e %+16.9e %+16.9e\n%+6.3f %+6.3f %+6.3f"

Any ideas how to solve that for both platforms??

Cheers,
David

_______________________________________________
Radiance-dev mailing list
[email protected]<mailto:[email protected]>
http://www.radiance-online.org/mailman/listinfo/radiance-dev

--
DI Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

7

It does indeed, Pally. I just announced I on radiance-general, and was
planning an update on how to use the Cmake system on your own system, to
be posted to tis dev list. In the meantime, you can check out what we have
on offer at:

https://openstudio.nrel.gov/getting-started-developer/getting-started-radia
nce

There are still a couple of issues (typically Windows issues) cropping up
(like the one David discovered recently) that Greg is actively fixing and
pushing into HEAD, but we are currently updating the HEAD installers every
two weeks. So, for the latest-greatest Radiance, you'll want to get up to
speed with Cmake.

- Rob

···

On 5/1/12 10:35 AM, "Pally Sandher" <[email protected]> wrote:

Does this mean the Radiance CMake environment is available for general
consumption?

8

Excellent Rob, I'm a bit busy with an impending software release right now but I'll definitely have a go later this month.

Thanks for all the hard work (and I really should get on the radiance-general list as I seem to miss a lot of announcements only being on here).

Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com

**Design, Simulate + Innovate with the <Virtual Environment>**
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP
Email Disclaimer

···

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]]
Sent: 01 May 2012 17:43
To: code development
Subject: Re: [Radiance-dev] mgf2inv VRML export

On 5/1/12 10:35 AM, "Pally Sandher" <[email protected]> wrote:

Does this mean the Radiance CMake environment is available for general
consumption?

It does indeed, Pally. I just announced I on radiance-general, and was
planning an update on how to use the Cmake system on your own system, to
be posted to tis dev list. In the meantime, you can check out what we have
on offer at:

https://openstudio.nrel.gov/getting-started-developer/getting-started-radia
nce

There are still a couple of issues (typically Windows issues) cropping up
(like the one David discovered recently) that Greg is actively fixing and
pushing into HEAD, but we are currently updating the HEAD installers every
two weeks. So, for the latest-greatest Radiance, you'll want to get up to
speed with Cmake.

- Rob

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

9

My pleasure Pally (actually it was (is) a giant PITA, and Greg Ward, Axel
Jacobs and the Kitware guys deserve a lot of the credit for making this a
success)!

And yeah, -general and -dev are a package deal, you need to monitor both
lists to get the full monty.

Rob Guglielmetti IESNA, LEED AP
Commercial Buildings Research Group
National Renewable Energy Laboratory
15013 Denver West Parkway MS:RSF202
Golden, CO 80401
303.275.4319
[email protected]

···

On 5/1/12 10:54 AM, "Pally Sandher" <[email protected]> wrote:

Excellent Rob, I'm a bit busy with an impending software release right
now but I'll definitely have a go later this month.

Thanks for all the hard work (and I really should get on the
radiance-general list as I seem to miss a lot of announcements only being
on here).

Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com

**Design, Simulate + Innovate with the <Virtual Environment>**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]]
Sent: 01 May 2012 17:43
To: code development
Subject: Re: [Radiance-dev] mgf2inv VRML export

On 5/1/12 10:35 AM, "Pally Sandher" <[email protected]> wrote:

Does this mean the Radiance CMake environment is available for general
consumption?

It does indeed, Pally. I just announced I on radiance-general, and was
planning an update on how to use the Cmake system on your own system, to
be posted to tis dev list. In the meantime, you can check out what we have
on offer at:

https://openstudio.nrel.gov/getting-started-developer/getting-started-radi
a
nce

There are still a couple of issues (typically Windows issues) cropping up
(like the one David discovered recently) that Greg is actively fixing and
pushing into HEAD, but we are currently updating the HEAD installers every
two weeks. So, for the latest-greatest Radiance, you'll want to get up to
speed with Cmake.

- Rob

_______________________________________________
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

10

I'm sure it's appreciated though Rob =)
Certainly for anyone like myself who has to build Radiance on Windows as trying to use the old Scons system was also a massive PITA but at least this is something which can be maintained and is cross platform.

Signing myself up to Radiance-general now :wink:

Again thanks to everyone involved for all the time, effort, blood, sweat, tears & anything else required to get this up & running.

Palbinder Sandher
Software Platform Engineer
T:+44 (0) 141 945 8500
F:+44 (0) 141 945 8501
http://www.iesve.com

**Design, Simulate + Innovate with the <Virtual Environment>**
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP
Email Disclaimer

···

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]]
Sent: 01 May 2012 18:04
To: code development
Subject: Re: [Radiance-dev] mgf2inv VRML export

My pleasure Pally (actually it was (is) a giant PITA, and Greg Ward, Axel
Jacobs and the Kitware guys deserve a lot of the credit for making this a
success)!

And yeah, -general and -dev are a package deal, you need to monitor both
lists to get the full monty.

Rob Guglielmetti IESNA, LEED AP
Commercial Buildings Research Group
National Renewable Energy Laboratory
15013 Denver West Parkway MS:RSF202
Golden, CO 80401
303.275.4319
[email protected]

On 5/1/12 10:54 AM, "Pally Sandher" <[email protected]> wrote:

Excellent Rob, I'm a bit busy with an impending software release right
now but I'll definitely have a go later this month.

Thanks for all the hard work (and I really should get on the
radiance-general list as I seem to miss a lot of announcements only being
on here).

Palbinder Sandher
Software Platform Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com

**Design, Simulate + Innovate with the <Virtual Environment>**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-----Original Message-----
From: Guglielmetti, Robert [mailto:[email protected]]
Sent: 01 May 2012 17:43
To: code development
Subject: Re: [Radiance-dev] mgf2inv VRML export

On 5/1/12 10:35 AM, "Pally Sandher" <[email protected]> wrote:

Does this mean the Radiance CMake environment is available for general
consumption?

It does indeed, Pally. I just announced I on radiance-general, and was
planning an update on how to use the Cmake system on your own system, to
be posted to tis dev list. In the meantime, you can check out what we have
on offer at:

https://openstudio.nrel.gov/getting-started-developer/getting-started-radi
a
nce

There are still a couple of issues (typically Windows issues) cropping up
(like the one David discovered recently) that Greg is actively fixing and
pushing into HEAD, but we are currently updating the HEAD installers every
two weeks. So, for the latest-greatest Radiance, you'll want to get up to
speed with Cmake.

- Rob

_______________________________________________
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

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

11

Hi Greg,

the last mgf2inv update fixed the problem with the tree digit exponents.
However, on Windows (thanks again Rob for providing the new binaries!)
the normals are still messed up -- see below.

The strange thing is that using the Windows binaries normals are printed
whereas in Linux the normals are not printed at all.

The output in Windows is:

*DEF ceil_fac_001 Group {
  Separator {
    USE ceil_mat
    Coordinate3 {
      point [ -2.000000000e+000 +4.500000000e+000 +2.853170182e+000,
              -1.500000000e+000 +4.500000000e+000 +3.000000000e+000,
              -1.500000000e+000 +5.000000000e+000 +2.544315366e+000,
              -2.000000000e+000 +5.000000000e+000 +2.397485548e+000 ]
    }
    Normal {
      vector [ +0.000 +0.000 +0.0-1.500000000e+000 +4.500000000e+000
+3.000000000e+000,
               +0.000 +0.000 +0.0-1.500000000e+000 +5.000000000e+000
+2.544315366e+000,
               +0.000 +0.000 +0.0-2.000000000e+000 +5.000000000e+000
+2.397485548e+000,
               +0.000 +0.000 +0.000 ]
    }
    IndexedFaceSet {
      coordIndex [ 0, 1, 2, 3 ]
      normalIndex [ 0, 1, 2, 3 ]
    }
  }
}

···

*
It seems the vlist[] is corrupt under Win because in line 546 of mgf2inv.c
the strcmp is
nonzero. To me it seems that from the the second vertex on the vertices are
written 3 bytes
left of where they should be -- these could be just the bytes that Win (or
any system with
3 digit exponents) needs more?!

All in all it's probaly the VFLEN that is correct for a 2 digit exponent
(72 = VSEPPOS (50) +
space (1) + len(VZVECT) (20) + len(\0) (1)) but not for a 3 digit exponent.

Cheers,
David