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 <gregoryjw...@gmail.com> 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 <rio...@gmail.com> > > *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 <nathaniel...@gmail.com> > 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 <rio...@gmail.com> 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 < >>> robert.guglielme...@nrel.gov> 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" <rio...@gmail.com> 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 > Radiance-dev@radiance-online.org > http://www.radiance-online.org/mailman/listinfo/radiance-dev > >
_______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
