Compiling Radiance for Windows

[Victor_LRG]

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation finished
with no errors (although some 1700 warnings), but when I am trying a simple
test I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
0
9 -0.833925170898 0.506038208008 0.096073600769
   -0.819481933594 0.473128112793 0.0903565139771
   -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to erf.c
as well? Actually, this warning also appears for most projects. I've
compiled and used the same package in linux before with no problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

[Guglielmetti_Robert]

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:

Changes to compile under Windows

d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

···

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
finished with no errors (although some 1700 warnings), but when I am
trying a simple test
I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
0
9 -0.833925170898 0.506038208008 0.096073600769
  -0.819481933594 0.473128112793 0.0903565139771
  -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to
erf.c as well? Actually, this warning also appears for most projects.
I've compiled and used the same package in linux before with no problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

[Jan_Wienold]

Hi Rob,

just a short question : is the evalglare-compilation bug for windows solved for the 5.0.a.12 ?

if not, just let me know if you need help for solving. Also give me a hint when a new "big" release is planned.

FYI: I away from 29.12 to 15.12 without access to email

best,

Jan

···

On 22/12/16 15:39, Guglielmetti, Robert wrote:

What�s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12� tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6
-win32.exe

I also �get� wanting to roll your own, though. Again you�d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f4680c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren�t bulletproof, I�m finding, but xform and oconv
seem to work fine. It�d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
finished with no errors (although some 1700 warnings), but when I am
trying a simple test
I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
9 -0.833925170898 0.506038208008 0.096073600769
   -0.819481933594 0.473128112793 0.0903565139771
   -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to
erf.c as well? Actually, this warning also appears for most projects.
I've compiled and used the same package in linux before with no problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

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

--
Dr.-Ing. Jan Wienold
Ecole Polytechnique F�d�rale de Lausanne (EPFL)
EPFL ENAC IA LIPID

http://people.epfl.ch/jan.wienold
LE 1 111 (Office)
Phone +41 21 69 30849

[Victor_LRG]

Rob,

I have tried the last official release, so just 5.0. I'll try 5.0.a.12 to
see what happens. I have used the NREL Windows installers before and I had
no issues.

The reason I wanted to compile Radiance myself is that I was playing around
with the source code and I wanted to try the changes. So far I have
incorporated an equirectangular view to rpict (see Radiance General October
2016 Creating new view types for Radiance) and an additional option for
pextrem. They do seem to work fine in Linux, but unfortunately I not always
have access to a Linux machine. Therefore, it would be great to be able to
compile it for Windows.

I'll have a look at the link to the commit. For now a was using the
CMakeLists.txt that came with the source code package with the following
modifications:

cmake_policy(SET CMP0045 OLD)
SET(CMAKE_PREFIX_PATH “C:/Qt/5.7/msvc2015_64/lib/cmake/Qt5Widgets”)
SET(TIFF_INCLUDE_DIR “C:/Program Files (x86)/GnuWin32/include”)

I'll try using the CMake/MSVC/libtiff/Qt versions you suggest to see if
that makes a difference.

Many thanks,

Victor

···

On 22 December 2016 at 14:39, Guglielmetti, Robert < [email protected]> wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.
0.a.6/radiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.
0.a.6/radiance-5.0.a.6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f
4680c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

>Dear all,
>
>I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
>MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
>finished with no errors (although some 1700 warnings), but when I am
>trying a simple test
> I get the following error with ovonv: fatal - (!xform
>objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
>object has the following description, which seems right to me:
>
>
>cage_sphere polygon 311s1m134f
>0
>0
>9 -0.833925170898 0.506038208008 0.096073600769
> -0.819481933594 0.473128112793 0.0903565139771
> -0.853187255859 0.492587890625 0.0980178833008
>
>
>
>In VS I can see the following warnings regarding oconv and xform:
>
>
>C4273 'erf': inconsistent dll linkage
>C4273 'erfc': inconsistent dll linkage
>
>
>
>They both refer to rtmath.h file, which I guess they should refer to
>erf.c as well? Actually, this warning also appears for most projects.
>I've compiled and used the same package in linux before with no problem.
>
>
>Any ideas?
>
>
>Thanks
>
>
>Victor Lopez-Rioboo Gil
>

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

[Nathaniel_Jones]

"Roll your own" has been working fine for me with the GitHub combined
branch head, VS2013, CMake 3.3.1, Qt 5.5, and the libtiff rolled from the
source files included in the repo. I haven't seed any problems with
evalglare, and I believe the erf and erfc warnings were fixed a few months
ago. I do get this warning with all the projects now:

1>D:\nljones\Radiance\src\common\platform.h(24): warning C4005: 'fseeko' :
macro redefinition
1> command-line arguments : see previous definition of 'fseeko'

Nathaniel

···

On Thu, Dec 22, 2016 at 10:00 AM, Jan Wienold <[email protected]> wrote:

Hi Rob,

just a short question : is the evalglare-compilation bug for windows
solved for the 5.0.a.12 ?

if not, just let me know if you need help for solving. Also give me a hint
when a new "big" release is planned.

FYI: I away from 29.12 to 15.12 without access to email

best,

Jan

On 22/12/16 15:39, Guglielmetti, Robert wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/
radiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.0.a.6/
radiance-5.0.a.6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0e
a42963ea8f4680c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
finished with no errors (although some 1700 warnings), but when I am
trying a simple test
I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
0
9 -0.833925170898 0.506038208008 0.096073600769
   -0.819481933594 0.473128112793 0.0903565139771
   -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to
erf.c as well? Actually, this warning also appears for most projects.
I've compiled and used the same package in linux before with no problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

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

--
Dr.-Ing. Jan Wienold
Ecole Polytechnique Fédérale de Lausanne (EPFL)
EPFL ENAC IA LIPID

http://people.epfl.ch/jan.wienold
LE 1 111 (Office)
Phone +41 21 69 30849

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

[Victor_LRG]

Nathaniel/Robert,

I've tried compiling 5.0.a.12 and I also get the same C4005 'fseeko' macro
definition warning (no more erf/erfc warnings though). Annoyingly,
xform/oconv are still giving me the same problems, but I'am not sure if
that is related to these warnings.

For now I am still using MVSC2015 and Cmake 3.7.1. I wonder if it is worth
trying the older versions you are using. It is a bit of work to remove and
reinstall MVSC...

Cheers,

Victor

···

On 22 December 2016 at 15:11, Nathaniel Jones <[email protected]> wrote:

"Roll your own" has been working fine for me with the GitHub combined
branch head, VS2013, CMake 3.3.1, Qt 5.5, and the libtiff rolled from the
source files included in the repo. I haven't seed any problems with
evalglare, and I believe the erf and erfc warnings were fixed a few months
ago. I do get this warning with all the projects now:

1>D:\nljones\Radiance\src\common\platform.h(24): warning C4005: 'fseeko'
: macro redefinition
1> command-line arguments : see previous definition of 'fseeko'

Nathaniel

On Thu, Dec 22, 2016 at 10:00 AM, Jan Wienold <[email protected]> wrote:

Hi Rob,

just a short question : is the evalglare-compilation bug for windows
solved for the 5.0.a.12 ?

if not, just let me know if you need help for solving. Also give me a
hint when a new "big" release is planned.

FYI: I away from 29.12 to 15.12 without access to email

best,

Jan

On 22/12/16 15:39, Guglielmetti, Robert wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag
that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/r
adiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.0.a.6/r
adiance-5.0.a.6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0e
a42963ea8f4680c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your
test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
finished with no errors (although some 1700 warnings), but when I am
trying a simple test
I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
0
9 -0.833925170898 0.506038208008 0.096073600769
   -0.819481933594 0.473128112793 0.0903565139771
   -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to
erf.c as well? Actually, this warning also appears for most projects.
I've compiled and used the same package in linux before with no problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

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

--
Dr.-Ing. Jan Wienold
Ecole Polytechnique Fédérale de Lausanne (EPFL)
EPFL ENAC IA LIPID

http://people.epfl.ch/jan.wienold
LE 1 111 (Office)
Phone +41 21 69 30849

_______________________________________________
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

[Nathaniel_Jones]

Well, the fseeko macro is only used by rcontrib, even though it appears in
a header that gets used almost everywhere. So that's unlikely to be the
problem.

For what it's worth, I had no problem running that triangle through my
compiled oconv. The error seems to indicate some problem reading the real
arguments. Does everything work if you remove that triangle from the model?
Or is this a problem with reading all polygons?

It's hard to imagine that something like this would change depending on the
MVSC version, but I guess if you've eliminated all the other
possibilities...

Nathaniel

···

On Thu, Dec 22, 2016 at 11:08 AM, Victor LRG <[email protected]> wrote:

Nathaniel/Robert,

I've tried compiling 5.0.a.12 and I also get the same C4005 'fseeko' macro
definition warning (no more erf/erfc warnings though). Annoyingly,
xform/oconv are still giving me the same problems, but I'am not sure if
that is related to these warnings.

For now I am still using MVSC2015 and Cmake 3.7.1. I wonder if it is worth
trying the older versions you are using. It is a bit of work to remove and
reinstall MVSC...

Cheers,

Victor

On 22 December 2016 at 15:11, Nathaniel Jones <[email protected]> > wrote:

"Roll your own" has been working fine for me with the GitHub combined
branch head, VS2013, CMake 3.3.1, Qt 5.5, and the libtiff rolled from the
source files included in the repo. I haven't seed any problems with
evalglare, and I believe the erf and erfc warnings were fixed a few months
ago. I do get this warning with all the projects now:

1>D:\nljones\Radiance\src\common\platform.h(24): warning C4005: 'fseeko'
: macro redefinition
1> command-line arguments : see previous definition of 'fseeko'

Nathaniel

On Thu, Dec 22, 2016 at 10:00 AM, Jan Wienold <[email protected]> >> wrote:

Hi Rob,

just a short question : is the evalglare-compilation bug for windows
solved for the 5.0.a.12 ?

if not, just let me know if you need help for solving. Also give me a
hint when a new "big" release is planned.

FYI: I away from 29.12 to 15.12 without access to email

best,

Jan

On 22/12/16 15:39, Guglielmetti, Robert wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag
that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/r
adiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.0.a.6/r
adiance-5.0.a.6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0e
a42963ea8f4680c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to
try
the NREL package on your input and see what happens. Or, send me your
test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86
and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
finished with no errors (although some 1700 warnings), but when I am
trying a simple test
I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
0
9 -0.833925170898 0.506038208008 0.096073600769
   -0.819481933594 0.473128112793 0.0903565139771
   -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to
erf.c as well? Actually, this warning also appears for most projects.
I've compiled and used the same package in linux before with no
problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

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

--
Dr.-Ing. Jan Wienold
Ecole Polytechnique Fédérale de Lausanne (EPFL)
EPFL ENAC IA LIPID

http://people.epfl.ch/jan.wienold
LE 1 111 (Office)
Phone +41 21 69 30849

_______________________________________________
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

[Greg_Ward]

I just checked in a fix for the fseeko macro warning, but I doubt it's related to the errors you're seeing.

Did you run xform on its own to see what it spits out for this file? We should figure out if it's xform rather than oconv that is screwing up.

Cheers,
-Greg

···

From: Nathaniel Jones <[email protected]>
Date: December 22, 2016 8:42:49 AM PST

Well, the fseeko macro is only used by rcontrib, even though it appears in a header that gets used almost everywhere. So that's unlikely to be the problem.

For what it's worth, I had no problem running that triangle through my compiled oconv. The error seems to indicate some problem reading the real arguments. Does everything work if you remove that triangle from the model? Or is this a problem with reading all polygons?

It's hard to imagine that something like this would change depending on the MVSC version, but I guess if you've eliminated all the other possibilities...

Nathaniel

On Thu, Dec 22, 2016 at 11:08 AM, Victor LRG <[email protected]> wrote:
Nathaniel/Robert,

I've tried compiling 5.0.a.12 and I also get the same C4005 'fseeko' macro definition warning (no more erf/erfc warnings though). Annoyingly, xform/oconv are still giving me the same problems, but I'am not sure if that is related to these warnings.

For now I am still using MVSC2015 and Cmake 3.7.1. I wonder if it is worth trying the older versions you are using. It is a bit of work to remove and reinstall MVSC...

Cheers,

Victor

On 22 December 2016 at 15:11, Nathaniel Jones <[email protected]> wrote:
"Roll your own" has been working fine for me with the GitHub combined branch head, VS2013, CMake 3.3.1, Qt 5.5, and the libtiff rolled from the source files included in the repo. I haven't seed any problems with evalglare, and I believe the erf and erfc warnings were fixed a few months ago. I do get this warning with all the projects now:

1>D:\nljones\Radiance\src\common\platform.h(24): warning C4005: 'fseeko' : macro redefinition
1> command-line arguments : see previous definition of 'fseeko'

Nathaniel

On Thu, Dec 22, 2016 at 10:00 AM, Jan Wienold <[email protected]> wrote:
Hi Rob,

just a short question : is the evalglare-compilation bug for windows solved for the 5.0.a.12 ?

if not, just let me know if you need help for solving. Also give me a hint when a new "big" release is planned.

FYI: I away from 29.12 to 15.12 without access to email

best,

Jan

On 22/12/16 15:39, Guglielmetti, Robert wrote:
What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f4680c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
finished with no errors (although some 1700 warnings), but when I am
trying a simple test
I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
0
9 -0.833925170898 0.506038208008 0.096073600769
   -0.819481933594 0.473128112793 0.0903565139771
   -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to
erf.c as well? Actually, this warning also appears for most projects.
I've compiled and used the same package in linux before with no problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

[Victor_LRG]

Greg,

I've tried xform and oconv and they do seem to work on their own. However,
the problem is still happening when I try to oconv a scene file with xform,
which I always use for convenience:

!xform materials\mat.rad
!xform objects\cage_sphere.rad

I never had problems with that before, so I'm quite puzzled. I get bad
arguments for polygon... and then it looks like sometimes I get a random
polygon and sometimes the same one.

I have tried the same oconv and xform files in another computer and it says
VCRUNTIME140D.dll is missing...

Best,

Victor

···

On 22 December 2016 at 17:15, Gregory J. Ward <[email protected]> wrote:

I just checked in a fix for the fseeko macro warning, but I doubt it's
related to the errors you're seeing.

Did you run xform on its own to see what it spits out for this file? We
should figure out if it's xform rather than oconv that is screwing up.

Cheers,
-Greg

*From: *Nathaniel Jones <[email protected]>

*Date: *December 22, 2016 8:42:49 AM PST

Well, the fseeko macro is only used by rcontrib, even though it appears in
a header that gets used almost everywhere. So that's unlikely to be the
problem.

For what it's worth, I had no problem running that triangle through my
compiled oconv. The error seems to indicate some problem reading the real
arguments. Does everything work if you remove that triangle from the model?
Or is this a problem with reading all polygons?

It's hard to imagine that something like this would change depending on
the MVSC version, but I guess if you've eliminated all the other
possibilities...

Nathaniel

On Thu, Dec 22, 2016 at 11:08 AM, Victor LRG <[email protected]> wrote:

Nathaniel/Robert,

I've tried compiling 5.0.a.12 and I also get the same C4005 'fseeko'
macro definition warning (no more erf/erfc warnings though). Annoyingly,
xform/oconv are still giving me the same problems, but I'am not sure if
that is related to these warnings.

For now I am still using MVSC2015 and Cmake 3.7.1. I wonder if it is
worth trying the older versions you are using. It is a bit of work to
remove and reinstall MVSC...

Cheers,

Victor

On 22 December 2016 at 15:11, Nathaniel Jones <[email protected]> >> wrote:

"Roll your own" has been working fine for me with the GitHub combined
branch head, VS2013, CMake 3.3.1, Qt 5.5, and the libtiff rolled from the
source files included in the repo. I haven't seed any problems with
evalglare, and I believe the erf and erfc warnings were fixed a few months
ago. I do get this warning with all the projects now:

1>D:\nljones\Radiance\src\common\platform.h(24): warning C4005:
'fseeko' : macro redefinition
1> command-line arguments : see previous definition of 'fseeko'

Nathaniel

On Thu, Dec 22, 2016 at 10:00 AM, Jan Wienold <[email protected]> >>> wrote:

Hi Rob,

just a short question : is the evalglare-compilation bug for windows
solved for the 5.0.a.12 ?

if not, just let me know if you need help for solving. Also give me a
hint when a new "big" release is planned.

FYI: I away from 29.12 to 15.12 without access to email

best,

Jan

On 22/12/16 15:39, Guglielmetti, Robert wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag
that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/r
adiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.0.a.6/r
adiance-5.0.a.6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0e
a42963ea8f4680c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to
try
the NREL package on your input and see what happens. Or, send me your
test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86
and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
finished with no errors (although some 1700 warnings), but when I am
trying a simple test
I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f".
This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
0
9 -0.833925170898 0.506038208008 0.096073600769
   -0.819481933594 0.473128112793 0.0903565139771
   -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to
erf.c as well? Actually, this warning also appears for most projects.
I've compiled and used the same package in linux before with no
problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

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

[Greg_Ward]

This sounds like a popen() i/o error. We've seen these in the past under Windows, and I have no idea about their cause or remedy. Is this just a problem with the binaries you've compiled, or does it also happen with the package distribution?

-Greg

···

From: Victor LRG <[email protected]>
Date: December 22, 2016 9:38:15 AM PST

Greg,

I've tried xform and oconv and they do seem to work on their own. However, the problem is still happening when I try to oconv a scene file with xform, which I always use for convenience:

!xform materials\mat.rad
!xform objects\cage_sphere.rad

I never had problems with that before, so I'm quite puzzled. I get bad arguments for polygon... and then it looks like sometimes I get a random polygon and sometimes the same one.

I have tried the same oconv and xform files in another computer and it says VCRUNTIME140D.dll is missing...

Best,

Victor

On 22 December 2016 at 17:15, Gregory J. Ward <[email protected]> wrote:
I just checked in a fix for the fseeko macro warning, but I doubt it's related to the errors you're seeing.

Did you run xform on its own to see what it spits out for this file? We should figure out if it's xform rather than oconv that is screwing up.

Cheers,
-Greg

From: Nathaniel Jones <[email protected]>
Date: December 22, 2016 8:42:49 AM PST

Well, the fseeko macro is only used by rcontrib, even though it appears in a header that gets used almost everywhere. So that's unlikely to be the problem.

For what it's worth, I had no problem running that triangle through my compiled oconv. The error seems to indicate some problem reading the real arguments. Does everything work if you remove that triangle from the model? Or is this a problem with reading all polygons?

It's hard to imagine that something like this would change depending on the MVSC version, but I guess if you've eliminated all the other possibilities...

Nathaniel

On Thu, Dec 22, 2016 at 11:08 AM, Victor LRG <[email protected]> wrote:
Nathaniel/Robert,

I've tried compiling 5.0.a.12 and I also get the same C4005 'fseeko' macro definition warning (no more erf/erfc warnings though). Annoyingly, xform/oconv are still giving me the same problems, but I'am not sure if that is related to these warnings.

For now I am still using MVSC2015 and Cmake 3.7.1. I wonder if it is worth trying the older versions you are using. It is a bit of work to remove and reinstall MVSC...

Cheers,

Victor

On 22 December 2016 at 15:11, Nathaniel Jones <[email protected]> wrote:
"Roll your own" has been working fine for me with the GitHub combined branch head, VS2013, CMake 3.3.1, Qt 5.5, and the libtiff rolled from the source files included in the repo. I haven't seed any problems with evalglare, and I believe the erf and erfc warnings were fixed a few months ago. I do get this warning with all the projects now:

1>D:\nljones\Radiance\src\common\platform.h(24): warning C4005: 'fseeko' : macro redefinition
1> command-line arguments : see previous definition of 'fseeko'

Nathaniel

On Thu, Dec 22, 2016 at 10:00 AM, Jan Wienold <[email protected]> wrote:
Hi Rob,

just a short question : is the evalglare-compilation bug for windows solved for the 5.0.a.12 ?

if not, just let me know if you need help for solving. Also give me a hint when a new "big" release is planned.

FYI: I away from 29.12 to 15.12 without access to email

best,

Jan

On 22/12/16 15:39, Guglielmetti, Robert wrote:
What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f4680c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
finished with no errors (although some 1700 warnings), but when I am
trying a simple test
I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
0
9 -0.833925170898 0.506038208008 0.096073600769
   -0.819481933594 0.473128112793 0.0903565139771
   -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to
erf.c as well? Actually, this warning also appears for most projects.
I've compiled and used the same package in linux before with no problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

_______________________________________________
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

[Victor_LRG]

Robert,

Actually, your cooking recipe does work for me as well!, at least for
Radiance 5.0. It looks like there is something wrong when using more recent
versions of MVSC and/or CMake... but that's another story. So far I'm happy
with the result. Thanks!

Merry Christmas!

Victor

···

On 22 December 2016 at 14:39, Guglielmetti, Robert < [email protected]> wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.
0.a.6/radiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.
0.a.6/radiance-5.0.a.6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f
4680c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

>Dear all,
>
>I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
>MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
>finished with no errors (although some 1700 warnings), but when I am
>trying a simple test
> I get the following error with ovonv: fatal - (!xform
>objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
>object has the following description, which seems right to me:
>
>
>cage_sphere polygon 311s1m134f
>0
>0
>9 -0.833925170898 0.506038208008 0.096073600769
> -0.819481933594 0.473128112793 0.0903565139771
> -0.853187255859 0.492587890625 0.0980178833008
>
>
>
>In VS I can see the following warnings regarding oconv and xform:
>
>
>C4273 'erf': inconsistent dll linkage
>C4273 'erfc': inconsistent dll linkage
>
>
>
>They both refer to rtmath.h file, which I guess they should refer to
>erf.c as well? Actually, this warning also appears for most projects.
>I've compiled and used the same package in linux before with no problem.
>
>
>Any ideas?
>
>
>Thanks
>
>
>Victor Lopez-Rioboo Gil
>

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

[Guglielmetti_Robert]

Oh, that’s good news! Hopefully that will work for you for a while. Not
sure when we will have time to sort out all the build issues with the
latest source.

Happy New Year everyone!

- Rob

···

On 12/23/16, 6:03 AM, "Victor LRG" <[email protected]> wrote:

Robert,

Actually, your cooking recipe does work for me as well!, at least for
Radiance 5.0. It looks like there is something wrong when using more
recent versions of MVSC and/or CMake... but that's another story. So far
I'm happy with the result. Thanks!

Merry Christmas!

Victor

On 22 December 2016 at 14:39, Guglielmetti, Robert ><[email protected]> wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.
6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.
6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f4680
c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
finished with no errors (although some 1700 warnings), but when I am
trying a simple test
I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
0
9 -0.833925170898 0.506038208008 0.096073600769
  -0.819481933594 0.473128112793 0.0903565139771
  -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to
erf.c as well? Actually, this warning also appears for most projects.
I've compiled and used the same package in linux before with no problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

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

[Nathaniel_Jones]

Hi Victor,

I'm considering implementing equirectangular view for some of my own work,
and before I start, I was wondering what the state of your implementation
is and whether you might share it. Also, is this something that might work
its way into the main Radiance distribution?

Happy new year,

Nathaniel

···

On Thu, Dec 22, 2016 at 10:09 AM, Victor LRG <[email protected]> wrote:

Rob,

I have tried the last official release, so just 5.0. I'll try 5.0.a.12 to
see what happens. I have used the NREL Windows installers before and I had
no issues.

The reason I wanted to compile Radiance myself is that I was playing
around with the source code and I wanted to try the changes. So far I have
incorporated an equirectangular view to rpict (see Radiance General October
2016 Creating new view types for Radiance) and an additional option for
pextrem. They do seem to work fine in Linux, but unfortunately I not always
have access to a Linux machine. Therefore, it would be great to be able to
compile it for Windows.

I'll have a look at the link to the commit. For now a was using the
CMakeLists.txt that came with the source code package with the following
modifications:

cmake_policy(SET CMP0045 OLD)
SET(CMAKE_PREFIX_PATH “C:/Qt/5.7/msvc2015_64/lib/cmake/Qt5Widgets”)
SET(TIFF_INCLUDE_DIR “C:/Program Files (x86)/GnuWin32/include”)

I'll try using the CMake/MSVC/libtiff/Qt versions you suggest to see if
that makes a difference.

Many thanks,

Victor

On 22 December 2016 at 14:39, Guglielmetti, Robert < > [email protected]> wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/
radiance-5.0.a.6
-win64.exe
<https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6-win64.exe>
https://github.com/NREL/Radiance/releases/download/5.0.a.6/
radiance-5.0.a.6
-win32.exe
<https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6-win32.exe>

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0e
a42963ea8f4680c
d1fc5
<https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f4680cd1fc5>

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

>Dear all,
>
>I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
>MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
>finished with no errors (although some 1700 warnings), but when I am
>trying a simple test
> I get the following error with ovonv: fatal - (!xform
>objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
>object has the following description, which seems right to me:
>
>
>cage_sphere polygon 311s1m134f
>0
>0
>9 -0.833925170898 0.506038208008 0.096073600769
> -0.819481933594 0.473128112793 0.0903565139771
> -0.853187255859 0.492587890625 0.0980178833008
>
>
>
>In VS I can see the following warnings regarding oconv and xform:
>
>
>C4273 'erf': inconsistent dll linkage
>C4273 'erfc': inconsistent dll linkage
>
>
>
>They both refer to rtmath.h file, which I guess they should refer to
>erf.c as well? Actually, this warning also appears for most projects.
>I've compiled and used the same package in linux before with no problem.
>
>
>Any ideas?
>
>
>Thanks
>
>
>Victor Lopez-Rioboo Gil
>

_______________________________________________
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

[Victor_LRG]

Nathaniel,

So far my implementation the equirectangular view seems to work. The only
part that I have not touched for full support is util/rpiece.c because I
don't use it very often. You can also create an equirectangular view
through other routes, but I find having it inside the code faster and more
convenient.

I'm happy to share it. Personally, I think it would be useful to
incorporate it into the main distribution, but that's a question for Greg.

Cheers,

Victor Lopez-Rioboo Gil

···

On 7 January 2017 at 18:42, Nathaniel Jones <[email protected]> wrote:

Hi Victor,

I'm considering implementing equirectangular view for some of my own work,
and before I start, I was wondering what the state of your implementation
is and whether you might share it. Also, is this something that might work
its way into the main Radiance distribution?

Happy new year,

Nathaniel

On Thu, Dec 22, 2016 at 10:09 AM, Victor LRG <[email protected]> wrote:

Rob,

I have tried the last official release, so just 5.0. I'll try 5.0.a.12 to
see what happens. I have used the NREL Windows installers before and I had
no issues.

The reason I wanted to compile Radiance myself is that I was playing
around with the source code and I wanted to try the changes. So far I have
incorporated an equirectangular view to rpict (see Radiance General October
2016 Creating new view types for Radiance) and an additional option for
pextrem. They do seem to work fine in Linux, but unfortunately I not always
have access to a Linux machine. Therefore, it would be great to be able to
compile it for Windows.

I'll have a look at the link to the commit. For now a was using the
CMakeLists.txt that came with the source code package with the following
modifications:

cmake_policy(SET CMP0045 OLD)
SET(CMAKE_PREFIX_PATH “C:/Qt/5.7/msvc2015_64/lib/cmake/Qt5Widgets”)
SET(TIFF_INCLUDE_DIR “C:/Program Files (x86)/GnuWin32/include”)

I'll try using the CMake/MSVC/libtiff/Qt versions you suggest to see if
that makes a difference.

Many thanks,

Victor

On 22 December 2016 at 14:39, Guglielmetti, Robert < >> [email protected]> wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag
that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/r
adiance-5.0.a.6
-win64.exe
<https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6-win64.exe>
https://github.com/NREL/Radiance/releases/download/5.0.a.6/r
adiance-5.0.a.6
-win32.exe
<https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6-win32.exe>

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0e
a42963ea8f4680c
d1fc5
<https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f4680cd1fc5>

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your
test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

>Dear all,
>
>I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
>MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
>finished with no errors (although some 1700 warnings), but when I am
>trying a simple test
> I get the following error with ovonv: fatal - (!xform
>objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
>object has the following description, which seems right to me:
>
>
>cage_sphere polygon 311s1m134f
>0
>0
>9 -0.833925170898 0.506038208008 0.096073600769
> -0.819481933594 0.473128112793 0.0903565139771
> -0.853187255859 0.492587890625 0.0980178833008
>
>
>
>In VS I can see the following warnings regarding oconv and xform:
>
>
>C4273 'erf': inconsistent dll linkage
>C4273 'erfc': inconsistent dll linkage
>
>
>
>They both refer to rtmath.h file, which I guess they should refer to
>erf.c as well? Actually, this warning also appears for most projects.
>I've compiled and used the same package in linux before with no problem.
>
>
>Any ideas?
>
>
>Thanks
>
>
>Victor Lopez-Rioboo Gil
>

_______________________________________________
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

[Greg_Ward]

Hi Victor (& Nathaniel),

I am happy to take a look at the code and see how much effort it would be to integrate. I have a question first, however.

Is the "equirectangular" view useful for anything less than a full panorama? Would people want to use it for smaller/different views, or do you always set vertical to 180° and horizontal to 360° in every application?

If you only use this view for one purpose, then I wonder if it is really worth having a view implemented in Radiance, which needs to handle every possible setting correctly. Also, I wonder in such a case if you have tested every possible (legal) setting?

Cheers,
-Greg

···

From: Victor LRG <[email protected]>
Date: January 8, 2017 3:49:00 AM PST

Nathaniel,

So far my implementation the equirectangular view seems to work. The only part that I have not touched for full support is util/rpiece.c because I don't use it very often. You can also create an equirectangular view through other routes, but I find having it inside the code faster and more convenient.

I'm happy to share it. Personally, I think it would be useful to incorporate it into the main distribution, but that's a question for Greg.

Cheers,

Victor Lopez-Rioboo Gil

On 7 January 2017 at 18:42, Nathaniel Jones <[email protected]> wrote:
Hi Victor,

I'm considering implementing equirectangular view for some of my own work, and before I start, I was wondering what the state of your implementation is and whether you might share it. Also, is this something that might work its way into the main Radiance distribution?

Happy new year,

Nathaniel

On Thu, Dec 22, 2016 at 10:09 AM, Victor LRG <[email protected]> wrote:
Rob,

I have tried the last official release, so just 5.0. I'll try 5.0.a.12 to see what happens. I have used the NREL Windows installers before and I had no issues.

The reason I wanted to compile Radiance myself is that I was playing around with the source code and I wanted to try the changes. So far I have incorporated an equirectangular view to rpict (see Radiance General October 2016 Creating new view types for Radiance) and an additional option for pextrem. They do seem to work fine in Linux, but unfortunately I not always have access to a Linux machine. Therefore, it would be great to be able to compile it for Windows.

I'll have a look at the link to the commit. For now a was using the CMakeLists.txt that came with the source code package with the following modifications:

cmake_policy(SET CMP0045 OLD)
SET(CMAKE_PREFIX_PATH “C:/Qt/5.7/msvc2015_64/lib/cmake/Qt5Widgets”)
SET(TIFF_INCLUDE_DIR “C:/Program Files (x86)/GnuWin32/include”)

I'll try using the CMake/MSVC/libtiff/Qt versions you suggest to see if that makes a difference.

Many thanks,

Victor

On 22 December 2016 at 14:39, Guglielmetti, Robert <[email protected]> wrote:
What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6
-win64.exe
https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6
-win32.exe

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f4680c
d1fc5

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

>Dear all,
>
>I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
>MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
>finished with no errors (although some 1700 warnings), but when I am
>trying a simple test
> I get the following error with ovonv: fatal - (!xform
>objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
>object has the following description, which seems right to me:
>
>
>cage_sphere polygon 311s1m134f
>0
>0
>9 -0.833925170898 0.506038208008 0.096073600769
> -0.819481933594 0.473128112793 0.0903565139771
> -0.853187255859 0.492587890625 0.0980178833008
>
>
>
>In VS I can see the following warnings regarding oconv and xform:
>
>
>C4273 'erf': inconsistent dll linkage
>C4273 'erfc': inconsistent dll linkage
>
>
>
>They both refer to rtmath.h file, which I guess they should refer to
>erf.c as well? Actually, this warning also appears for most projects.
>I've compiled and used the same package in linux before with no problem.
>
>
>Any ideas?
>
>
>Thanks
>
>
>Victor Lopez-Rioboo Gil
>

[Nathaniel_Jones]

I guess I'd generally be in favor of having equirectangular view as an
option, although I can see how it does only cater to a few applications.
The fact that it would probably always be used with the same parameters
doesn't bother me much more than cylindrical or angular fisheye views,
which I suspect are also almost always used the same way. I also expect
that the ability to "zoom in" on the image would be "legal", if not
popular. Going beyond 180 degrees in the vertical direction is
mathematically definable, though it would look odd and be inefficient to
sample. The bigger issue might be that equirectangular view begs having a
stereo offset parameter as a convenience feature, which doesn't exist in
Radiance.

However, as I've been looking at this problem a bit more, it seems that
even equirectangular view doesn't meet all of my needs. I may need to
implement something like ODS
<https://developers.google.com/vr/jump/rendering-ods-content.pdf> view for
what I have in mind.

Nathaniel

···

On Sun, Jan 8, 2017 at 12:18 PM, Gregory J. Ward <[email protected]> wrote:

Hi Victor (& Nathaniel),

I am happy to take a look at the code and see how much effort it would be
to integrate. I have a question first, however.

Is the "equirectangular" view useful for anything less than a full
panorama? Would people want to use it for smaller/different views, or do
you always set vertical to 180° and horizontal to 360° in every application?

If you only use this view for one purpose, then I wonder if it is really
worth having a view implemented in Radiance, which needs to handle every
possible setting correctly. Also, I wonder in such a case if you have
tested every possible (legal) setting?

Cheers,
-Greg

*From: *Victor LRG <[email protected]>

*Date: *January 8, 2017 3:49:00 AM PST

Nathaniel,

So far my implementation the equirectangular view seems to work. The only
part that I have not touched for full support is util/rpiece.c because I
don't use it very often. You can also create an equirectangular view
through other routes, but I find having it inside the code faster and more
convenient.

I'm happy to share it. Personally, I think it would be useful to
incorporate it into the main distribution, but that's a question for Greg.

Cheers,

Victor Lopez-Rioboo Gil

On 7 January 2017 at 18:42, Nathaniel Jones <[email protected]> > wrote:

Hi Victor,

I'm considering implementing equirectangular view for some of my own
work, and before I start, I was wondering what the state of your
implementation is and whether you might share it. Also, is this something
that might work its way into the main Radiance distribution?

Happy new year,

Nathaniel

On Thu, Dec 22, 2016 at 10:09 AM, Victor LRG <[email protected]> wrote:

Rob,

I have tried the last official release, so just 5.0. I'll try 5.0.a.12
to see what happens. I have used the NREL Windows installers before and I
had no issues.

The reason I wanted to compile Radiance myself is that I was playing
around with the source code and I wanted to try the changes. So far I have
incorporated an equirectangular view to rpict (see Radiance General October
2016 Creating new view types for Radiance) and an additional option for
pextrem. They do seem to work fine in Linux, but unfortunately I not always
have access to a Linux machine. Therefore, it would be great to be able to
compile it for Windows.

I'll have a look at the link to the commit. For now a was using the
CMakeLists.txt that came with the source code package with the following
modifications:

cmake_policy(SET CMP0045 OLD)
SET(CMAKE_PREFIX_PATH “C:/Qt/5.7/msvc2015_64/lib/cmake/Qt5Widgets”)
SET(TIFF_INCLUDE_DIR “C:/Program Files (x86)/GnuWin32/include”)

I'll try using the CMake/MSVC/libtiff/Qt versions you suggest to see if
that makes a difference.

Many thanks,

Victor

On 22 December 2016 at 14:39, Guglielmetti, Robert < >>> [email protected]> wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag
that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/r
adiance-5.0.a.6
-win64.exe
<https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6-win64.exe>
https://github.com/NREL/Radiance/releases/download/5.0.a.6/r
adiance-5.0.a.6
-win32.exe
<https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.6-win32.exe>

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0e
a42963ea8f4680c
d1fc5
<https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f4680cd1fc5>

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to
try
the NREL package on your input and see what happens. Or, send me your
test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

>Dear all,
>
>I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86
and
>MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
>finished with no errors (although some 1700 warnings), but when I am
>trying a simple test
> I get the following error with ovonv: fatal - (!xform
>objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
>object has the following description, which seems right to me:
>
>
>cage_sphere polygon 311s1m134f
>0
>0
>9 -0.833925170898 0.506038208008 0.096073600769
> -0.819481933594 0.473128112793 0.0903565139771
> -0.853187255859 0.492587890625 0.0980178833008
>
>
>
>In VS I can see the following warnings regarding oconv and xform:
>
>
>C4273 'erf': inconsistent dll linkage
>C4273 'erfc': inconsistent dll linkage
>
>
>
>They both refer to rtmath.h file, which I guess they should refer to
>erf.c as well? Actually, this warning also appears for most projects.
>I've compiled and used the same package in linux before with no
problem.
>
>
>Any ideas?
>
>
>Thanks
>
>
>Victor Lopez-Rioboo Gil
>

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

[Guglielmetti_Robert]

I’ll keep an eye out, should this be added to the standard palette of
views in the source. I think it’s pretty easy to add it to the Qt rvu...

···

On 1/8/17, 10:18 AM, "Gregory J. Ward" <[email protected]> wrote:

Hi Victor (& Nathaniel),

I am happy to take a look at the code and see how much effort it would be
to integrate. I have a question first, however.

Is the "equirectangular" view useful for anything less than a full
panorama? Would people want to use it for smaller/different views, or do
you always set vertical to 180° and horizontal to 360° in every
application?

If you only use this view for one purpose, then I wonder if it is really
worth having a view implemented in Radiance, which needs to handle every
possible setting correctly. Also, I wonder in such a case if you have
tested every possible (legal) setting?

Cheers,
-Greg

From:
Victor LRG <[email protected]>
Date:
January 8, 2017 3:49:00 AM PST

Nathaniel,

So far my implementation the equirectangular view seems to work. The only
part that I have not touched for full support is util/rpiece.c because I
don't use it very often. You can also create an equirectangular view
through other routes, but I find having
it inside the code faster and more convenient.

I'm happy to share it. Personally, I think it would be useful to
incorporate it into the main distribution, but that's a question for Greg.

Cheers,

Victor Lopez-Rioboo Gil

On 7 January 2017 at 18:42, Nathaniel Jones ><[email protected]> wrote:

Hi Victor,

I'm considering implementing equirectangular view for some of my own
work, and before I start, I was wondering what the state of your
implementation is and whether you might share it. Also, is this something
that might work its way into the main Radiance
distribution?

Happy new year,

Nathaniel

On Thu, Dec 22, 2016 at 10:09 AM, Victor LRG ><[email protected]> wrote:

Rob,

I have tried the last official release, so just 5.0. I'll try 5.0.a.12 to
see what happens. I have used the NREL Windows installers before and I
had no issues.

The reason I wanted to compile Radiance myself is that I was playing
around with the source code and I wanted to try the changes. So far I
have incorporated an equirectangular view to rpict (see Radiance General
October 2016 Creating new view types for
Radiance) and an additional option for pextrem. They do seem to work
fine in Linux, but unfortunately I not always have access to a Linux
machine. Therefore, it would be great to be able to compile it for
Windows.

I'll have a look at the link to the commit. For now a was using the
CMakeLists.txt that came with the source code package with the following
modifications:

cmake_policy(SET CMP0045 OLD)

SET(CMAKE_PREFIX_PATH “C:/Qt/5.7/msvc2015_64/lib/cmake/Qt5Widgets”)
SET(TIFF_INCLUDE_DIR “C:/Program Files (x86)/GnuWin32/include”)

I'll try using the CMake/MSVC/libtiff/Qt versions you suggest to see if
that makes a difference.

Many thanks,

Victor

On 22 December 2016 at 14:39, Guglielmetti, Robert ><[email protected]> wrote:

What¹s the vintage of the source code? There were a couple of minor
patches to the 5.0 official release (Mid-September), and the last tag that
builds for Windows for me is the 'NREL 5.0.a.12¹ tag:

https://github.com/NREL/Radiance/releases/tag/5.0.a.12

You could try the Windows installers we have, which seem to be working:

https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.
6
-win64.exe
<https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a
.6-win64.exe>
https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a.
6
-win32.exe
<https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a
.6-win32.exe>

I also Œget¹ wanting to roll your own, though. Again you¹d need to make
sure your source aligns with this commit, or earlier:
https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f4680
c
d1fc5
<https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f468
0cd1fc5>

And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.

The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
seem to work fine. It¹d be potentially mutually beneficial for you to try
the NREL package on your input and see what happens. Or, send me your test
input and we can go from there.

- Rob

On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:

Dear all,

I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
finished with no errors (although some 1700 warnings), but when I am
trying a simple test
I get the following error with ovonv: fatal - (!xform
objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
object has the following description, which seems right to me:

cage_sphere polygon 311s1m134f
0
0
9 -0.833925170898 0.506038208008 0.096073600769
  -0.819481933594 0.473128112793 0.0903565139771
  -0.853187255859 0.492587890625 0.0980178833008

In VS I can see the following warnings regarding oconv and xform:

C4273 'erf': inconsistent dll linkage
C4273 'erfc': inconsistent dll linkage

They both refer to rtmath.h file, which I guess they should refer to
erf.c as well? Actually, this warning also appears for most projects.
I've compiled and used the same package in linux before with no problem.

Any ideas?

Thanks

Victor Lopez-Rioboo Gil

[Victor_LRG]

I agree with Nathaniel that the general use would be similar to cylindrical
or angular fisheye views in terms of view apertures. Personally, I use the
equirectangular view in four combinations: 180-360 deg horizontally and
90-180 deg vertically, and then as a base for other fancier view types when
I need them.

With regards to the stereo offset I wonder if it could be added with a bit
of work using the standard clipping plane offset as an stereo one?

Victor

···

On 9 January 2017 at 15:59, Guglielmetti, Robert < [email protected]> wrote:

I’ll keep an eye out, should this be added to the standard palette of
views in the source. I think it’s pretty easy to add it to the Qt rvu...

On 1/8/17, 10:18 AM, "Gregory J. Ward" <[email protected]> wrote:

>Hi Victor (& Nathaniel),
>
>
>I am happy to take a look at the code and see how much effort it would be
>to integrate. I have a question first, however.
>
>
>Is the "equirectangular" view useful for anything less than a full
>panorama? Would people want to use it for smaller/different views, or do
>you always set vertical to 180° and horizontal to 360° in every
>application?
>
>
>If you only use this view for one purpose, then I wonder if it is really
>worth having a view implemented in Radiance, which needs to handle every
>possible setting correctly. Also, I wonder in such a case if you have
>tested every possible (legal) setting?
>
>
>Cheers,
>-Greg
>
>
>From:
>Victor LRG <[email protected]>
>Date:
>January 8, 2017 3:49:00 AM PST
>
>
>
>
>
>Nathaniel,
>
>
>So far my implementation the equirectangular view seems to work. The only
>part that I have not touched for full support is util/rpiece.c because I
>don't use it very often. You can also create an equirectangular view
>through other routes, but I find having
> it inside the code faster and more convenient.
>
>
>I'm happy to share it. Personally, I think it would be useful to
>incorporate it into the main distribution, but that's a question for Greg.
>
>
>Cheers,
>
>
>Victor Lopez-Rioboo Gil
>
>
>
>
>On 7 January 2017 at 18:42, Nathaniel Jones > ><[email protected]> wrote:
>
>Hi Victor,
>
>
>I'm considering implementing equirectangular view for some of my own
>work, and before I start, I was wondering what the state of your
>implementation is and whether you might share it. Also, is this something
>that might work its way into the main Radiance
> distribution?
>
>
>Happy new year,
>
>
>Nathaniel
>
>
>On Thu, Dec 22, 2016 at 10:09 AM, Victor LRG > ><[email protected]> wrote:
>
>Rob,
>
>
>I have tried the last official release, so just 5.0. I'll try 5.0.a.12 to
>see what happens. I have used the NREL Windows installers before and I
>had no issues.
>
>
>The reason I wanted to compile Radiance myself is that I was playing
>around with the source code and I wanted to try the changes. So far I
>have incorporated an equirectangular view to rpict (see Radiance General
>October 2016 Creating new view types for
> Radiance) and an additional option for pextrem. They do seem to work
>fine in Linux, but unfortunately I not always have access to a Linux
>machine. Therefore, it would be great to be able to compile it for
>Windows.
>
>
>I'll have a look at the link to the commit. For now a was using the
>CMakeLists.txt that came with the source code package with the following
>modifications:
>
>
>cmake_policy(SET CMP0045 OLD)
>
>SET(CMAKE_PREFIX_PATH “C:/Qt/5.7/msvc2015_64/lib/cmake/Qt5Widgets”)
>SET(TIFF_INCLUDE_DIR “C:/Program Files (x86)/GnuWin32/include”)
>
>
>
>I'll try using the CMake/MSVC/libtiff/Qt versions you suggest to see if
>that makes a difference.
>
>
>Many thanks,
>
>
>Victor
>
>
>
>
>
>
>
>
>On 22 December 2016 at 14:39, Guglielmetti, Robert > ><[email protected]> wrote:
>
>What¹s the vintage of the source code? There were a couple of minor
>patches to the 5.0 official release (Mid-September), and the last tag that
>builds for Windows for me is the 'NREL 5.0.a.12¹ tag:
>
>https://github.com/NREL/Radiance/releases/tag/5.0.a.12
>
>
>You could try the Windows installers we have, which seem to be working:
>
>https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a
.
>6
>-win64.exe
><https://github.com/NREL/Radiance/releases/download/5.
0.a.6/radiance-5.0.a
>.6-win64.exe>
>https://github.com/NREL/Radiance/releases/download/5.0.a.6/radiance-5.0.a
.
>6
>-win32.exe
><https://github.com/NREL/Radiance/releases/download/5.
0.a.6/radiance-5.0.a
>.6-win32.exe>
>
>I also Œget¹ wanting to roll your own, though. Again you¹d need to make
>sure your source aligns with this commit, or earlier:
>https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f
4680
>c
>d1fc5
><https://github.com/NREL/Radiance/commit/0c842736bf2b0908ba0ea42963ea8f
468
>0cd1fc5>
>
>And for the record, that NREL Windows build used Cmake 3.3.2, MSVC 12
>2013, a libtiff I rolled myself with 4.0.4-beta, and Qt5.3.
>
>The NREL packages aren¹t bulletproof, I¹m finding, but xform and oconv
>seem to work fine. It¹d be potentially mutually beneficial for you to try
>the NREL package on your input and see what happens. Or, send me your test
>input and we can go from there.
>
>- Rob
>
>
>On 12/22/16, 5:15 AM, "Victor LRG" <[email protected]> wrote:
>
>>Dear all,
>>
>>I amtrying to compile Radiance 5R0 for Windows using Cmake 3.7.1 x86 and
>>MVSC 2015 v14 with libtiff 3.8.2 and qt-x86-2.0.4. The compilation
>>finished with no errors (although some 1700 warnings), but when I am
>>trying a simple test
>> I get the following error with ovonv: fatal - (!xform
>>objects/cage_sphere2.rad): bad arguments for polygon "311s1m134f". This
>>object has the following description, which seems right to me:
>>
>>
>>cage_sphere polygon 311s1m134f
>>0
>>0
>>9 -0.833925170898 0.506038208008 0.096073600769
>> -0.819481933594 0.473128112793 0.0903565139771
>> -0.853187255859 0.492587890625 0.0980178833008
>>
>>
>>
>>In VS I can see the following warnings regarding oconv and xform:
>>
>>
>>C4273 'erf': inconsistent dll linkage
>>C4273 'erfc': inconsistent dll linkage
>>
>>
>>
>>They both refer to rtmath.h file, which I guess they should refer to
>>erf.c as well? Actually, this warning also appears for most projects.
>>I've compiled and used the same package in linux before with no problem.
>>
>>
>>Any ideas?
>>
>>
>>Thanks
>>
>>
>>Victor Lopez-Rioboo Gil
>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

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

[Greg_Ward]

Hi Victor,

I thought that there was some trick to doing stereo 360° views that involved rotating the eye positions with the ray directions to keep them at right angles. Andy (McNeil), can you help us out?

-Greg

···

From: Victor LRG <[email protected]>
Date: January 10, 2017 2:14:48 AM PST

I agree with Nathaniel that the general use would be similar to cylindrical or angular fisheye views in terms of view apertures. Personally, I use the equirectangular view in four combinations: 180-360 deg horizontally and 90-180 deg vertically, and then as a base for other fancier view types when I need them.

With regards to the stereo offset I wonder if it could be added with a bit of work using the standard clipping plane offset as an stereo one?

Victor

On 9 January 2017 at 15:59, Guglielmetti, Robert <[email protected]> wrote:
I’ll keep an eye out, should this be added to the standard palette of
views in the source. I think it’s pretty easy to add it to the Qt rvu...

On 1/8/17, 10:18 AM, "Gregory J. Ward" <[email protected]> wrote:

>Hi Victor (& Nathaniel),
>
>
>I am happy to take a look at the code and see how much effort it would be
>to integrate. I have a question first, however.
>
>
>Is the "equirectangular" view useful for anything less than a full
>panorama? Would people want to use it for smaller/different views, or do
>you always set vertical to 180° and horizontal to 360° in every
>application?
>
>
>If you only use this view for one purpose, then I wonder if it is really
>worth having a view implemented in Radiance, which needs to handle every
>possible setting correctly. Also, I wonder in such a case if you have
>tested every possible (legal) setting?
>
>
>Cheers,
>-Greg

[Andrew_McNeil]

Hi Greg,

The viewpoint, or ray origin, is different for each column of pixels in a
stereo ODS rendering. If you start with a viewpoint, and draw a circle with
diameter that is the distance between one's pupils, then the origin for
each ray should be at a point where the ray is tangent to the circle (on
the left side of the circle for left eye and right side for right eye).
It's explained & illustrated well here:

rendering-ods-content.pdf

I don't see how clipping planes could be used to modify the ray origin, but
I could be wrong.

And this goes a ways back in the thread, but one instance where smaller
than 180° x 360° sized equirectangular views would be necessary is if a
user wanted to use rpiece to render the full view.

Best,
Andy

···

On Tue, Jan 10, 2017 at 10:38 AM, Gregory J. Ward <[email protected]> wrote:

Hi Victor,

I thought that there was some trick to doing stereo 360° views that
involved rotating the eye positions with the ray directions to keep them at
right angles. Andy (McNeil), can you help us out?

-Greg

*From: *Victor LRG <[email protected]>

*Date: *January 10, 2017 2:14:48 AM PST

I agree with Nathaniel that the general use would be similar to cylindrical
or angular fisheye views in terms of view apertures. Personally, I use
the equirectangular view in four combinations: 180-360 deg horizontally and
90-180 deg vertically, and then as a base for other fancier view types when
I need them.

With regards to the stereo offset I wonder if it could be added with a bit
of work using the standard clipping plane offset as an stereo one?

Victor

On 9 January 2017 at 15:59, Guglielmetti, Robert < > [email protected]> wrote:

I’ll keep an eye out, should this be added to the standard palette of
views in the source. I think it’s pretty easy to add it to the Qt rvu...

On 1/8/17, 10:18 AM, "Gregory J. Ward" <[email protected]> wrote:

>Hi Victor (& Nathaniel),
>
>
>I am happy to take a look at the code and see how much effort it would be
>to integrate. I have a question first, however.
>
>
>Is the "equirectangular" view useful for anything less than a full
>panorama? Would people want to use it for smaller/different views, or do
>you always set vertical to 180° and horizontal to 360° in every
>application?
>
>
>If you only use this view for one purpose, then I wonder if it is really
>worth having a view implemented in Radiance, which needs to handle every
>possible setting correctly. Also, I wonder in such a case if you have
>tested every possible (legal) setting?
>
>
>Cheers,
>-Greg

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