Compiling Radiance for Windows

Thanks, Andy.

Have you already created a .cal file to generate the appropriate ray origins and directions for this? If not, I could take a crack at it. Seems like an easier method than adding a new view type, especially since we would need a new parameter for the stereo offset to get it to do what we want.

Regarding rpiece, you can always use the rtrace -n option to get an equivalent speed-up.

Cheers,
-Greg

···

From: Andy McNeil <[email protected]>
Date: January 11, 2017 1:00:31 PM PST

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: https://developers.google.com/vr/jump/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

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

Hi Greg,
Mark Stock created the attached cal file for rendering ODS views. If it is
okay with Mark, can we add the cal file to the radiance distribution?
Andy

3d360.cal (1.69 KB)

···

On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward <[email protected]> wrote:

Thanks, Andy.

Have you already created a .cal file to generate the appropriate ray
origins and directions for this? If not, I could take a crack at it.
Seems like an easier method than adding a new view type, especially since
we would need a new parameter for the stereo offset to get it to do what we
want.

Regarding rpiece, you can always use the rtrace -n option to get an
equivalent speed-up.

Cheers,
-Greg

*From: *Andy McNeil <[email protected]>

*Date: *January 11, 2017 1:00:31 PM PST

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: https://developers.google.com/
vr/jump/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

_______________________________________________
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

Perfect -- happy to add it to the distribution with Mark's blessing.

Would this satisfy people's needs, or should we think about extensions?

Cheers,
-Greg

3d360.cal (1.69 KB)

···

From: Andy McNeil <[email protected]>
Date: January 11, 2017 4:20:44 PM PST

Hi Greg,
Mark Stock created the attached cal file for rendering ODS views. If it is okay with Mark, can we add the cal file to the radiance distribution?
Andy

On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward <[email protected]> wrote:
Thanks, Andy.

Have you already created a .cal file to generate the appropriate ray origins and directions for this? If not, I could take a crack at it. Seems like an easier method than adding a new view type, especially since we would need a new parameter for the stereo offset to get it to do what we want.

Regarding rpiece, you can always use the rtrace -n option to get an equivalent speed-up.

Cheers,
-Greg

From: Andy McNeil <[email protected]>
Date: January 11, 2017 1:00:31 PM PST

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: https://developers.google.com/vr/jump/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

Andy, Greg,

I'm happy to have it included, if it's up to par. I'm not happy with
the neck rotation portion of that code, and if you want the pixel
edges to line up right on azimuth=0, I need to put a 0.5 in there
somewhere.

Mark

···

On 1/11/17, Andy McNeil <[email protected]> wrote:

Hi Greg,
Mark Stock created the attached cal file for rendering ODS views. If it is
okay with Mark, can we add the cal file to the radiance distribution?
Andy

On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward <[email protected]> > wrote:

Thanks, Andy.

Have you already created a .cal file to generate the appropriate ray
origins and directions for this? If not, I could take a crack at it.
Seems like an easier method than adding a new view type, especially since
we would need a new parameter for the stereo offset to get it to do what
we
want.

Regarding rpiece, you can always use the rtrace -n option to get an
equivalent speed-up.

Cheers,
-Greg

*From: *Andy McNeil <[email protected]>

*Date: *January 11, 2017 1:00:31 PM PST

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: https://developers.google.com/
vr/jump/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

_______________________________________________
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

Thanks, Mark.

I'll take a closer look at it and generate some test images with your .cal file. Also, if there are any features people want to have that they would feel helpful or important, let us know!

-Greg

···

From: Mark Stock <[email protected]>
Date: January 11, 2017 4:40:54 PM PST

Andy, Greg,

I'm happy to have it included, if it's up to par. I'm not happy with
the neck rotation portion of that code, and if you want the pixel
edges to line up right on azimuth=0, I need to put a 0.5 in there
somewhere.

Mark

On 1/11/17, Andy McNeil <[email protected]> wrote:

Hi Greg,
Mark Stock created the attached cal file for rendering ODS views. If it is
okay with Mark, can we add the cal file to the radiance distribution?
Andy

On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward <[email protected]> >> wrote:

Thanks, Andy.

Have you already created a .cal file to generate the appropriate ray
origins and directions for this? If not, I could take a crack at it.
Seems like an easier method than adding a new view type, especially since
we would need a new parameter for the stereo offset to get it to do what
we
want.

Regarding rpiece, you can always use the rtrace -n option to get an
equivalent speed-up.

Cheers,
-Greg

*From: *Andy McNeil <[email protected]>

*Date: *January 11, 2017 1:00:31 PM PST

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: https://developers.google.com/
vr/jump/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

_______________________________________________
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

I checked in the file, renaming it to "view360stereo.cal" in the src/cal/cal folder. I made a few modifications, which I hope are improvements, but I don't have a viewer that I can test it with. Can someone give it a try?

Thanks!
-Greg

···

From: "Gregory J. Ward" <[email protected]>
Date: January 11, 2017 4:53:07 PM PST

Thanks, Mark.

I'll take a closer look at it and generate some test images with your .cal file. Also, if there are any features people want to have that they would feel helpful or important, let us know!

-Greg

From: Mark Stock <[email protected]>
Date: January 11, 2017 4:40:54 PM PST

Andy, Greg,

I'm happy to have it included, if it's up to par. I'm not happy with
the neck rotation portion of that code, and if you want the pixel
edges to line up right on azimuth=0, I need to put a 0.5 in there
somewhere.

Mark

On 1/11/17, Andy McNeil <[email protected]> wrote:

Hi Greg,
Mark Stock created the attached cal file for rendering ODS views. If it is
okay with Mark, can we add the cal file to the radiance distribution?
Andy

On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward <[email protected]> >>> wrote:

Thanks, Andy.

Have you already created a .cal file to generate the appropriate ray
origins and directions for this? If not, I could take a crack at it.
Seems like an easier method than adding a new view type, especially since
we would need a new parameter for the stereo offset to get it to do what
we
want.

Regarding rpiece, you can always use the rtrace -n option to get an
equivalent speed-up.

Cheers,
-Greg

*From: *Andy McNeil <[email protected]>

*Date: *January 11, 2017 1:00:31 PM PST

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: https://developers.google.com/
vr/jump/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

_______________________________________________
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

I just ran the view360stereo.cal file on a model that I've been working
with. The image that's generated is mirrored left-to-right from what I'd
expect. Other than that, the ODS projection works decently well in my
cardboard viewer.

A few other notes: The .cal file name in the example in comments doesn't
match the new name of the .cal file. Also, this is perhaps unnecessary, but
I'd like to be able to specify the forward direction to appear in the
center of the image.

For my own work, I've gone ahead and implemented the ODS view in source
code. I've called it VT_ODS (-vto) and added a new parameter -vi for
inter-pupillary distance. I haven't bothered with the EX and EZ parameters
for neck rotation yet. Also, the implementation isn't complete (I'm not
sure what viewloc() does, for example), but it's working for my purposes.

Cheers,

Nathaniel

···

On Fri, Jan 13, 2017 at 9:31 PM, Gregory J. Ward <[email protected]> wrote:

I checked in the file, renaming it to "view360stereo.cal" in the
src/cal/cal folder. I made a few modifications, which I hope are
improvements, but I don't have a viewer that I can test it with. Can
someone give it a try?

Thanks!
-Greg

> From: "Gregory J. Ward" <[email protected]>
> Date: January 11, 2017 4:53:07 PM PST
>
> Thanks, Mark.
>
> I'll take a closer look at it and generate some test images with your
.cal file. Also, if there are any features people want to have that they
would feel helpful or important, let us know!
>
> -Greg
>
>> From: Mark Stock <[email protected]>
>> Date: January 11, 2017 4:40:54 PM PST
>>
>> Andy, Greg,
>>
>> I'm happy to have it included, if it's up to par. I'm not happy with
>> the neck rotation portion of that code, and if you want the pixel
>> edges to line up right on azimuth=0, I need to put a 0.5 in there
>> somewhere.
>>
>> Mark
>>
>> On 1/11/17, Andy McNeil <[email protected]> wrote:
>>> Hi Greg,
>>> Mark Stock created the attached cal file for rendering ODS views. If
it is
>>> okay with Mark, can we add the cal file to the radiance distribution?
>>> Andy
>>>
>>>
>>> On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward < > [email protected]> > >>> wrote:
>>>
>>>> Thanks, Andy.
>>>>
>>>> Have you already created a .cal file to generate the appropriate ray
>>>> origins and directions for this? If not, I could take a crack at it.
>>>> Seems like an easier method than adding a new view type, especially
since
>>>> we would need a new parameter for the stereo offset to get it to do
what
>>>> we
>>>> want.
>>>>
>>>> Regarding rpiece, you can always use the rtrace -n option to get an
>>>> equivalent speed-up.
>>>>
>>>> Cheers,
>>>> -Greg
>>>>
>>>> *From: *Andy McNeil <[email protected]>
>>>>
>>>> *Date: *January 11, 2017 1:00:31 PM PST
>>>>
>>>>
>>>> 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:
https://developers.google.com/
>>>> vr/jump/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
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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

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

I can probably make the suggested changes. Let's hear from Mark to see what he says. I was also wondering about the azimuth direction, but I don't have a phone or the app I need to check things.

-Greg

···

From: Nathaniel Jones <[email protected]>
Date: January 16, 2017 1:15:01 PM PST

I just ran the view360stereo.cal file on a model that I've been working with. The image that's generated is mirrored left-to-right from what I'd expect. Other than that, the ODS projection works decently well in my cardboard viewer.

A few other notes: The .cal file name in the example in comments doesn't match the new name of the .cal file. Also, this is perhaps unnecessary, but I'd like to be able to specify the forward direction to appear in the center of the image.

For my own work, I've gone ahead and implemented the ODS view in source code. I've called it VT_ODS (-vto) and added a new parameter -vi for inter-pupillary distance. I haven't bothered with the EX and EZ parameters for neck rotation yet. Also, the implementation isn't complete (I'm not sure what viewloc() does, for example), but it's working for my purposes.

Cheers,

Nathaniel

On Fri, Jan 13, 2017 at 9:31 PM, Gregory J. Ward <[email protected]> wrote:
I checked in the file, renaming it to "view360stereo.cal" in the src/cal/cal folder. I made a few modifications, which I hope are improvements, but I don't have a viewer that I can test it with. Can someone give it a try?

Thanks!
-Greg

> From: "Gregory J. Ward" <[email protected]>
> Date: January 11, 2017 4:53:07 PM PST
>
> Thanks, Mark.
>
> I'll take a closer look at it and generate some test images with your .cal file. Also, if there are any features people want to have that they would feel helpful or important, let us know!
>
> -Greg
>
>> From: Mark Stock <[email protected]>
>> Date: January 11, 2017 4:40:54 PM PST
>>
>> Andy, Greg,
>>
>> I'm happy to have it included, if it's up to par. I'm not happy with
>> the neck rotation portion of that code, and if you want the pixel
>> edges to line up right on azimuth=0, I need to put a 0.5 in there
>> somewhere.
>>
>> Mark
>>
>> On 1/11/17, Andy McNeil <[email protected]> wrote:
>>> Hi Greg,
>>> Mark Stock created the attached cal file for rendering ODS views. If it is
>>> okay with Mark, can we add the cal file to the radiance distribution?
>>> Andy
>>>
>>>
>>> On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward <[email protected]> > >>> wrote:
>>>
>>>> Thanks, Andy.
>>>>
>>>> Have you already created a .cal file to generate the appropriate ray
>>>> origins and directions for this? If not, I could take a crack at it.
>>>> Seems like an easier method than adding a new view type, especially since
>>>> we would need a new parameter for the stereo offset to get it to do what
>>>> we
>>>> want.
>>>>
>>>> Regarding rpiece, you can always use the rtrace -n option to get an
>>>> equivalent speed-up.
>>>>
>>>> Cheers,
>>>> -Greg
>>>>
>>>> *From: *Andy McNeil <[email protected]>
>>>>
>>>> *Date: *January 11, 2017 1:00:31 PM PST
>>>>
>>>>
>>>> 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: https://developers.google.com/
>>>> vr/jump/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
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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

_______________________________________________
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,

I think what viewloc does the inverse of viewray. For a given point (p) and
view type pointer (*v) I think it calculates the image location (i), with
ip[0] and ip[1] being the ratio coordinates from the bottom left corner and
ip[2] the distance to the clipping plane.

Victor

···

On 16 January 2017 at 21:15, Nathaniel Jones <[email protected]> wrote:

I just ran the view360stereo.cal file on a model that I've been working
with. The image that's generated is mirrored left-to-right from what I'd
expect. Other than that, the ODS projection works decently well in my
cardboard viewer.

A few other notes: The .cal file name in the example in comments doesn't
match the new name of the .cal file. Also, this is perhaps unnecessary, but
I'd like to be able to specify the forward direction to appear in the
center of the image.

For my own work, I've gone ahead and implemented the ODS view in source
code. I've called it VT_ODS (-vto) and added a new parameter -vi for
inter-pupillary distance. I haven't bothered with the EX and EZ parameters
for neck rotation yet. Also, the implementation isn't complete (I'm not
sure what viewloc() does, for example), but it's working for my purposes.

Cheers,

Nathaniel

On Fri, Jan 13, 2017 at 9:31 PM, Gregory J. Ward <[email protected]> > wrote:

I checked in the file, renaming it to "view360stereo.cal" in the
src/cal/cal folder. I made a few modifications, which I hope are
improvements, but I don't have a viewer that I can test it with. Can
someone give it a try?

Thanks!
-Greg

> From: "Gregory J. Ward" <[email protected]>
> Date: January 11, 2017 4:53:07 PM PST
>
> Thanks, Mark.
>
> I'll take a closer look at it and generate some test images with your
.cal file. Also, if there are any features people want to have that they
would feel helpful or important, let us know!
>
> -Greg
>
>> From: Mark Stock <[email protected]>
>> Date: January 11, 2017 4:40:54 PM PST
>>
>> Andy, Greg,
>>
>> I'm happy to have it included, if it's up to par. I'm not happy with
>> the neck rotation portion of that code, and if you want the pixel
>> edges to line up right on azimuth=0, I need to put a 0.5 in there
>> somewhere.
>>
>> Mark
>>
>> On 1/11/17, Andy McNeil <[email protected]> wrote:
>>> Hi Greg,
>>> Mark Stock created the attached cal file for rendering ODS views. If
it is
>>> okay with Mark, can we add the cal file to the radiance distribution?
>>> Andy
>>>
>>>
>>> On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward < >> [email protected]> >> >>> wrote:
>>>
>>>> Thanks, Andy.
>>>>
>>>> Have you already created a .cal file to generate the appropriate ray
>>>> origins and directions for this? If not, I could take a crack at it.
>>>> Seems like an easier method than adding a new view type, especially
since
>>>> we would need a new parameter for the stereo offset to get it to do
what
>>>> we
>>>> want.
>>>>
>>>> Regarding rpiece, you can always use the rtrace -n option to get an
>>>> equivalent speed-up.
>>>>
>>>> Cheers,
>>>> -Greg
>>>>
>>>> *From: *Andy McNeil <[email protected]>
>>>>
>>>> *Date: *January 11, 2017 1:00:31 PM PST
>>>>
>>>>
>>>> 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:
https://developers.google.com/
>>>> vr/jump/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
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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

_______________________________________________
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

I went ahead and checked in the suggested changes -- give it a try!

-Greg

···

From: "Gregory J. Ward" <[email protected]>
Date: January 16, 2017 1:32:00 PM PST

I can probably make the suggested changes. Let's hear from Mark to see what he says. I was also wondering about the azimuth direction, but I don't have a phone or the app I need to check things.

-Greg

From: Nathaniel Jones <[email protected]>
Date: January 16, 2017 1:15:01 PM PST

I just ran the view360stereo.cal file on a model that I've been working with. The image that's generated is mirrored left-to-right from what I'd expect. Other than that, the ODS projection works decently well in my cardboard viewer.

A few other notes: The .cal file name in the example in comments doesn't match the new name of the .cal file. Also, this is perhaps unnecessary, but I'd like to be able to specify the forward direction to appear in the center of the image.

For my own work, I've gone ahead and implemented the ODS view in source code. I've called it VT_ODS (-vto) and added a new parameter -vi for inter-pupillary distance. I haven't bothered with the EX and EZ parameters for neck rotation yet. Also, the implementation isn't complete (I'm not sure what viewloc() does, for example), but it's working for my purposes.

Cheers,

Nathaniel

On Fri, Jan 13, 2017 at 9:31 PM, Gregory J. Ward <[email protected]> wrote:
I checked in the file, renaming it to "view360stereo.cal" in the src/cal/cal folder. I made a few modifications, which I hope are improvements, but I don't have a viewer that I can test it with. Can someone give it a try?

Thanks!
-Greg

> From: "Gregory J. Ward" <[email protected]>
> Date: January 11, 2017 4:53:07 PM PST
>
> Thanks, Mark.
>
> I'll take a closer look at it and generate some test images with your .cal file. Also, if there are any features people want to have that they would feel helpful or important, let us know!
>
> -Greg
>
>> From: Mark Stock <[email protected]>
>> Date: January 11, 2017 4:40:54 PM PST
>>
>> Andy, Greg,
>>
>> I'm happy to have it included, if it's up to par. I'm not happy with
>> the neck rotation portion of that code, and if you want the pixel
>> edges to line up right on azimuth=0, I need to put a 0.5 in there
>> somewhere.
>>
>> Mark
>>
>> On 1/11/17, Andy McNeil <[email protected]> wrote:
>>> Hi Greg,
>>> Mark Stock created the attached cal file for rendering ODS views. If it is
>>> okay with Mark, can we add the cal file to the radiance distribution?
>>> Andy
>>>
>>>
>>> On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward <[email protected]> >> >>> wrote:
>>>
>>>> Thanks, Andy.
>>>>
>>>> Have you already created a .cal file to generate the appropriate ray
>>>> origins and directions for this? If not, I could take a crack at it.
>>>> Seems like an easier method than adding a new view type, especially since
>>>> we would need a new parameter for the stereo offset to get it to do what
>>>> we
>>>> want.
>>>>
>>>> Regarding rpiece, you can always use the rtrace -n option to get an
>>>> equivalent speed-up.
>>>>
>>>> Cheers,
>>>> -Greg
>>>>
>>>> *From: *Andy McNeil <[email protected]>
>>>>
>>>> *Date: *January 11, 2017 1:00:31 PM PST
>>>>
>>>>
>>>> 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: https://developers.google.com/
>>>> vr/jump/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
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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

_______________________________________________
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

Ok, this gives the orientation I would expect, but the left and right eye
views are now switched. Probably and artifact of reversing the azimuth
direction...

Nathaniel

···

On Sun, Jan 22, 2017 at 4:06 PM, Gregory J. Ward <[email protected]> wrote:

I went ahead and checked in the suggested changes -- give it a try!

-Greg

*From: *"Gregory J. Ward" <[email protected]>

*Date: *January 16, 2017 1:32:00 PM PST

I can probably make the suggested changes. Let's hear from Mark to see
what he says. I was also wondering about the azimuth direction, but I
don't have a phone or the app I need to check things.

-Greg

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

*Date: *January 16, 2017 1:15:01 PM PST

I just ran the view360stereo.cal file on a model that I've been working
with. The image that's generated is mirrored left-to-right from what I'd
expect. Other than that, the ODS projection works decently well in my
cardboard viewer.

A few other notes: The .cal file name in the example in comments doesn't
match the new name of the .cal file. Also, this is perhaps unnecessary, but
I'd like to be able to specify the forward direction to appear in the
center of the image.

For my own work, I've gone ahead and implemented the ODS view in source
code. I've called it VT_ODS (-vto) and added a new parameter -vi for
inter-pupillary distance. I haven't bothered with the EX and EZ parameters
for neck rotation yet. Also, the implementation isn't complete (I'm not
sure what viewloc() does, for example), but it's working for my purposes.

Cheers,

Nathaniel

On Fri, Jan 13, 2017 at 9:31 PM, Gregory J. Ward <[email protected]> > wrote:

I checked in the file, renaming it to "view360stereo.cal" in the
src/cal/cal folder. I made a few modifications, which I hope are
improvements, but I don't have a viewer that I can test it with. Can
someone give it a try?

Thanks!
-Greg

> From: "Gregory J. Ward" <[email protected]>
> Date: January 11, 2017 4:53:07 PM PST
>
> Thanks, Mark.
>
> I'll take a closer look at it and generate some test images with your
.cal file. Also, if there are any features people want to have that they
would feel helpful or important, let us know!
>
> -Greg
>
>> From: Mark Stock <[email protected]>
>> Date: January 11, 2017 4:40:54 PM PST
>>
>> Andy, Greg,
>>
>> I'm happy to have it included, if it's up to par. I'm not happy with
>> the neck rotation portion of that code, and if you want the pixel
>> edges to line up right on azimuth=0, I need to put a 0.5 in there
>> somewhere.
>>
>> Mark
>>
>> On 1/11/17, Andy McNeil <[email protected]> wrote:
>>> Hi Greg,
>>> Mark Stock created the attached cal file for rendering ODS views. If
it is
>>> okay with Mark, can we add the cal file to the radiance distribution?
>>> Andy
>>>
>>>
>>> On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward < >> [email protected]> >> >>> wrote:
>>>
>>>> Thanks, Andy.
>>>>
>>>> Have you already created a .cal file to generate the appropriate ray
>>>> origins and directions for this? If not, I could take a crack at it.
>>>> Seems like an easier method than adding a new view type, especially
since
>>>> we would need a new parameter for the stereo offset to get it to do
what
>>>> we
>>>> want.
>>>>
>>>> Regarding rpiece, you can always use the rtrace -n option to get an
>>>> equivalent speed-up.
>>>>
>>>> Cheers,
>>>> -Greg
>>>>
>>>> *From: *Andy McNeil <[email protected]>
>>>>
>>>> *Date: *January 11, 2017 1:00:31 PM PST
>>>>
>>>>
>>>> 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:
https://developers.google.com/
>>>> vr/jump/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
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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

_______________________________________________
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

OK. I'll have to fix that...

···

Sent from my iPad

On Jan 22, 2017, at 3:02 PM, Nathaniel Jones <[email protected]> wrote:

Ok, this gives the orientation I would expect, but the left and right eye views are now switched. Probably and artifact of reversing the azimuth direction...

Nathaniel

On Sun, Jan 22, 2017 at 4:06 PM, Gregory J. Ward <[email protected]> wrote:
I went ahead and checked in the suggested changes -- give it a try!

-Greg

From: "Gregory J. Ward" <[email protected]>
Date: January 16, 2017 1:32:00 PM PST

I can probably make the suggested changes. Let's hear from Mark to see what he says. I was also wondering about the azimuth direction, but I don't have a phone or the app I need to check things.

-Greg

From: Nathaniel Jones <[email protected]>
Date: January 16, 2017 1:15:01 PM PST

I just ran the view360stereo.cal file on a model that I've been working with. The image that's generated is mirrored left-to-right from what I'd expect. Other than that, the ODS projection works decently well in my cardboard viewer.

A few other notes: The .cal file name in the example in comments doesn't match the new name of the .cal file. Also, this is perhaps unnecessary, but I'd like to be able to specify the forward direction to appear in the center of the image.

For my own work, I've gone ahead and implemented the ODS view in source code. I've called it VT_ODS (-vto) and added a new parameter -vi for inter-pupillary distance. I haven't bothered with the EX and EZ parameters for neck rotation yet. Also, the implementation isn't complete (I'm not sure what viewloc() does, for example), but it's working for my purposes.

Cheers,

Nathaniel

On Fri, Jan 13, 2017 at 9:31 PM, Gregory J. Ward <[email protected]> wrote:
I checked in the file, renaming it to "view360stereo.cal" in the src/cal/cal folder. I made a few modifications, which I hope are improvements, but I don't have a viewer that I can test it with. Can someone give it a try?

Thanks!
-Greg

> From: "Gregory J. Ward" <[email protected]>
> Date: January 11, 2017 4:53:07 PM PST
>
> Thanks, Mark.
>
> I'll take a closer look at it and generate some test images with your .cal file. Also, if there are any features people want to have that they would feel helpful or important, let us know!
>
> -Greg
>
>> From: Mark Stock <[email protected]>
>> Date: January 11, 2017 4:40:54 PM PST
>>
>> Andy, Greg,
>>
>> I'm happy to have it included, if it's up to par. I'm not happy with
>> the neck rotation portion of that code, and if you want the pixel
>> edges to line up right on azimuth=0, I need to put a 0.5 in there
>> somewhere.
>>
>> Mark
>>
>> On 1/11/17, Andy McNeil <[email protected]> wrote:
>>> Hi Greg,
>>> Mark Stock created the attached cal file for rendering ODS views. If it is
>>> okay with Mark, can we add the cal file to the radiance distribution?
>>> Andy
>>>
>>>
>>> On Wed, Jan 11, 2017 at 3:20 PM, Gregory J. Ward <[email protected]> >>>>> >>> wrote:
>>>
>>>> Thanks, Andy.
>>>>
>>>> Have you already created a .cal file to generate the appropriate ray
>>>> origins and directions for this? If not, I could take a crack at it.
>>>> Seems like an easier method than adding a new view type, especially since
>>>> we would need a new parameter for the stereo offset to get it to do what
>>>> we
>>>> want.
>>>>
>>>> Regarding rpiece, you can always use the rtrace -n option to get an
>>>> equivalent speed-up.
>>>>
>>>> Cheers,
>>>> -Greg
>>>>
>>>> *From: *Andy McNeil <[email protected]>
>>>>
>>>> *Date: *January 11, 2017 1:00:31 PM PST
>>>>
>>>>
>>>> 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: https://developers.google.com/
>>>> vr/jump/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
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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

_______________________________________________
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

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

OK -- got that one. Sorry I can't test this out, myself.

-Greg

···

From: Greg Ward <[email protected]>
Date: January 22, 2017 3:44:13 PM PST

OK. I'll have to fix that...

Sent from my iPad

On Jan 22, 2017, at 3:02 PM, Nathaniel Jones <[email protected]> wrote:

Ok, this gives the orientation I would expect, but the left and right eye views are now switched. Probably and artifact of reversing the azimuth direction...

Nathaniel

On Sun, Jan 22, 2017 at 4:06 PM, Gregory J. Ward <[email protected]> wrote:
I went ahead and checked in the suggested changes -- give it a try!

-Greg

From: "Gregory J. Ward" <[email protected]>
Date: January 16, 2017 1:32:00 PM PST

I can probably make the suggested changes. Let's hear from Mark to see what he says. I was also wondering about the azimuth direction, but I don't have a phone or the app I need to check things.

-Greg

From: Nathaniel Jones <[email protected]>
Date: January 16, 2017 1:15:01 PM PST

I just ran the view360stereo.cal file on a model that I've been working with. The image that's generated is mirrored left-to-right from what I'd expect. Other than that, the ODS projection works decently well in my cardboard viewer.

A few other notes: The .cal file name in the example in comments doesn't match the new name of the .cal file. Also, this is perhaps unnecessary, but I'd like to be able to specify the forward direction to appear in the center of the image.

For my own work, I've gone ahead and implemented the ODS view in source code. I've called it VT_ODS (-vto) and added a new parameter -vi for inter-pupillary distance. I haven't bothered with the EX and EZ parameters for neck rotation yet. Also, the implementation isn't complete (I'm not sure what viewloc() does, for example), but it's working for my purposes.

Cheers,

Nathaniel

Looks good!

Nathaniel

···

On Sun, Jan 22, 2017 at 9:31 PM, Gregory J. Ward <[email protected]> wrote:

OK -- got that one. Sorry I can't test this out, myself.

-Greg

*From: *Greg Ward <[email protected]>

*Date: *January 22, 2017 3:44:13 PM PST

OK. I'll have to fix that...

Sent from my iPad

On Jan 22, 2017, at 3:02 PM, Nathaniel Jones <[email protected]> > wrote:

Ok, this gives the orientation I would expect, but the left and right eye
views are now switched. Probably and artifact of reversing the azimuth
direction...

Nathaniel

On Sun, Jan 22, 2017 at 4:06 PM, Gregory J. Ward <[email protected]> > wrote:

I went ahead and checked in the suggested changes -- give it a try!

-Greg

*From: *"Gregory J. Ward" <[email protected]>

*Date: *January 16, 2017 1:32:00 PM PST

I can probably make the suggested changes. Let's hear from Mark to see
what he says. I was also wondering about the azimuth direction, but I
don't have a phone or the app I need to check things.

-Greg

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

*Date: *January 16, 2017 1:15:01 PM PST

I just ran the view360stereo.cal file on a model that I've been working
with. The image that's generated is mirrored left-to-right from what I'd
expect. Other than that, the ODS projection works decently well in my
cardboard viewer.

A few other notes: The .cal file name in the example in comments doesn't
match the new name of the .cal file. Also, this is perhaps unnecessary, but
I'd like to be able to specify the forward direction to appear in the
center of the image.

For my own work, I've gone ahead and implemented the ODS view in source
code. I've called it VT_ODS (-vto) and added a new parameter -vi for
inter-pupillary distance. I haven't bothered with the EX and EZ parameters
for neck rotation yet. Also, the implementation isn't complete (I'm not
sure what viewloc() does, for example), but it's working for my purposes.

Cheers,

Nathaniel

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

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

Hi Victor,

I suppose it depends on which compiler and set of libraries you are using whether you need to include erf.c or not in your src/common/CMakeLists.txt file or not. I don't know which compiler NREL is currently using -- I thought it was MFC, but I've no idea which version.

I don't think this would cause the error you are getting from xform, which is suspicious. Perhaps you could send me your file in a private message, and I could check if there is anything funny in there.

Cheers,
-Greg

P.S. Be sure to sign up to the radiance-dev mailing list via the interface at <https://www.radiance-online.org/community/mailing-lists> so you can post and receive responses.

···

From: Victor LRG <[email protected]>
Date: December 22, 2016 3:17:02 AM PST

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

I’ve been using MSVC in Microsoft Visual Studio 2013 Professional, Cmake
3.3.2, Qt 5.3. But I’ve also not built the source completely successfully
in a while. We’ve been ironing out some kinks in the Pmap stuff. Haven’t
had a chance to give Roland’s latest patches a try, nor am I sure that’s
related to anything you’re attempting to do.

···

On 7/29/17, 9:48 AM, "Gregory J. Ward" <[email protected]> wrote:

Hi Victor,

I suppose it depends on which compiler and set of libraries you are using
whether you need to include erf.c or not in your
src/common/CMakeLists.txt file or not. I don't know which compiler NREL
is currently using -- I thought it was MFC, but I've no
idea which version.

I don't think this would cause the error you are getting from xform,
which is suspicious. Perhaps you could send me your file in a private
message, and I could check if there is anything funny in there.

Cheers,
-Greg

P.S. Be sure to sign up to the radiance-dev mailing list via the
interface at <https://www.radiance-online.org/community/mailing-lists
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.radi
ance-online.org%2Fcommunity%2Fmailing-lists&data=02%7C01%7Crobert.guglielm
etti%40nrel.gov%7Cf3e5d42c5eed4062e8d408d4d6997711%7Ca0f29d7e28cd4f5484427
885aee7c080%7C0%7C0%7C636369402000628384&sdata=chBJhdHzaiK7%2ByYcajFQ6w52%
2Fs1ETJk05d8FcjAVUxI%3D&reserved=0>>
so you can post and receive responses.

From:
Victor LRG <[email protected]>
Date:
December 22, 2016 3:17:02 AM PST

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

I've been using Robert's recipe for a while with no issues. I get many
warnings when compiling, but not critical ones any more. Most warnings have
to do with potential loss of accuracy when converting numbers. I'm now
using a more recent version of MSVC with no problems either. I think I was
recently having issues with the TIFF library, but I'm not compiling pieces
with those dependences any more. I'm currently using Radiance 5 more like a
library, so I haven't tested the latest releases.

Cheers,

Victor LRG

···

On 29 July 2017 at 16:48, Gregory J. Ward <[email protected]> wrote:

Hi Victor,

I suppose it depends on which compiler and set of libraries you are using
whether you need to include erf.c or not in your src/common/CMakeLists.txt
file or not. I don't know which compiler NREL is currently using -- I
thought it was MFC, but I've no idea which version.

I don't think this would cause the error you are getting from xform, which
is suspicious. Perhaps you could send me your file in a private message,
and I could check if there is anything funny in there.

Cheers,
-Greg

P.S. Be sure to sign up to the radiance-dev mailing list via the
interface at <https://www.radiance-online.org/community/mailing-lists> so
you can post and receive responses.

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

*Date: *December 22, 2016 3:17:02 AM PST

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

Oh I see, this is one of the old posts. Sounds like you got it sorted
then, Victor. As far as the libtiff, that library has been a giant pain
for a long time (for me); I eventually made my own 64-bit tifflib for
Windows. Perhaps I could share that someplace, I dunno.

···

On 8/1/17, 10:30 AM, "Victor LRG" <[email protected]> wrote:

I've been using Robert's recipe for a while with no issues. I get many
warnings when compiling, but not critical ones any more. Most warnings
have to do with potential loss of accuracy when converting numbers. I'm
now using a more recent version
of MSVC with no problems either. I think I was recently having issues
with the TIFF library, but I'm not compiling pieces with those
dependences any more. I'm currently using Radiance 5 more like a library,
so I haven't tested the latest releases.

Cheers,

Victor LRG

On 29 July 2017 at 16:48, Gregory J. Ward ><[email protected]> wrote:

Hi Victor,

I suppose it depends on which compiler and set of libraries you are using
whether you need to include erf.c or not in your
src/common/CMakeLists.txt file or not. I don't know which compiler NREL
is currently using -- I thought it was MFC, but I've no
idea which version.

I don't think this would cause the error you are getting from xform,
which is suspicious. Perhaps you could send me your file in a private
message, and I could check if there is anything funny in there.

Cheers,
-Greg

P.S. Be sure to sign up to the radiance-dev mailing list via the
interface at <https://www.radiance-online.org/community/mailing-lists
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.radi
ance-online.org%2Fcommunity%2Fmailing-lists&data=02%7C01%7Crobert.guglielm
etti%40nrel.gov%7C067b9535986943eecaaa08d4d8fab509%7Ca0f29d7e28cd4f5484427
885aee7c080%7C0%7C0%7C636372018680224835&sdata=PiZZshFl%2BkQYlgHNTyUHQBKqS
HizArlBHSnddxhbI6k%3D&reserved=0>>
so you can post and receive responses.

From:
Victor LRG <[email protected]>
Date:
December 22, 2016 3:17:02 AM PST

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

I posted step-by-step how-to on compiling libtiff for Window from the
Radiance source. You can find it on the DAYSIM GitHub page:
https://github.com/MITSustainableDesignLab/Daysim. Scroll down to the
section "Compile DAYSIM" in the notes.

It is a little annoying, but you only have to do it once.

Nathaniel

···

On Tue, Aug 1, 2017 at 9:42 AM, Guglielmetti, Robert < [email protected]> wrote:

Oh I see, this is one of the old posts. Sounds like you got it sorted
then, Victor. As far as the libtiff, that library has been a giant pain
for a long time (for me); I eventually made my own 64-bit tifflib for
Windows. Perhaps I could share that someplace, I dunno.

On 8/1/17, 10:30 AM, "Victor LRG" <[email protected]> wrote:

>I've been using Robert's recipe for a while with no issues. I get many
>warnings when compiling, but not critical ones any more. Most warnings
>have to do with potential loss of accuracy when converting numbers. I'm
>now using a more recent version
> of MSVC with no problems either. I think I was recently having issues
>with the TIFF library, but I'm not compiling pieces with those
>dependences any more. I'm currently using Radiance 5 more like a library,
>so I haven't tested the latest releases.
>
>
>Cheers,
>
>
>Victor LRG
>
>
>On 29 July 2017 at 16:48, Gregory J. Ward > ><[email protected]> wrote:
>
>Hi Victor,
>
>
>I suppose it depends on which compiler and set of libraries you are using
>whether you need to include erf.c or not in your
>src/common/CMakeLists.txt file or not. I don't know which compiler NREL
>is currently using -- I thought it was MFC, but I've no
> idea which version.
>
>
>I don't think this would cause the error you are getting from xform,
>which is suspicious. Perhaps you could send me your file in a private
>message, and I could check if there is anything funny in there.
>
>
>Cheers,
>-Greg
>
>
>P.S. Be sure to sign up to the radiance-dev mailing list via the
>interface at <https://www.radiance-online.org/community/mailing-lists
><https://na01.safelinks.protection.outlook.com/?url=
https%3A%2F%2Fwww.radi
>ance-online.org%2Fcommunity%2Fmailing-lists&data=02%7C01%
7Crobert.guglielm
>etti%40nrel.gov%7C067b9535986943eecaaa08d4d8fa
b509%7Ca0f29d7e28cd4f5484427
>885aee7c080%7C0%7C0%7C636372018680224835&sdata=
PiZZshFl%2BkQYlgHNTyUHQBKqS
>HizArlBHSnddxhbI6k%3D&reserved=0>>
> so you can post and receive responses.
>
>
>From:
>Victor LRG <[email protected]>
>Date:
>December 22, 2016 3:17:02 AM PST
>
>
>
>
>
>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]
https://www.radiance-online.org/mailman/listinfo/radiance-dev