Dear Bogdan, the format seems indeed simple enough to use directly, or have users convert their own formats. We should allow floats in the azimuth column, though. If other formats appear, these should then be added with some format name in the landscape.ini. But some code fragment for reading and feeding a SphericalPolygon (or whatever is the best to use in that family of classes) would be nice. I have not started with this yet, so I don't know yet the right class. I am just into sampling the spherical pano for transparency - this can be used for sunrise time or such issues above the real landscape. I am just about getting this to work. Next the fisheyes. I have the impression these are not geometrically accurate, though, but just decoration. I think I have seen the SphericalPolygon even has a dedicated inside() function, this will make that addition quite simple. Just as I lamented yesterday, there is no usage example...
About not being able to build: Shouldn't it be possible to build Stellarium with (cost-free) MS Visual C++2010/2012 express on a Qt/ANGLE/MSVC installation? I know, these trials take days. I even tried building MESA for my netbook to have higher OpenGL. Didn't succeed, though. And I gave up for more urgent work. And there is a MSVC project in trunk. It seems outdated (set for Qt4.8), maybe you could update and try building that with MSVC? I am not too familiar with MSVC project structure, though. Kind regards, Georg On Do, 7.11.2013, 19:01, Bogdan Marinov wrote: > On 11/7/13, Georg Zotti <georg.zo...@univie.ac.at> wrote: >> [snipped] >> If reading a JSON already works, transforming alt/az text lists to JSONs >> should be simple enough for users. Which one is the best to use? > > As the one who proposed that blueprint, I will be very happy if this > gets implemented. > > As for the format: > > I've updated the link to the example file used in SkyChart: > http://sourceforge.net/p/skychart/code/HEAD/tree/trunk/tools/data/horizon/horizon_Geneve.txt > > It would be very nice if the implementation of Stellarium is > compatible with that format. It's not very hard to parse - you need to > read a text file line by line, ignore every line beginning with a #, > read lines that contain a pair of space-separated values and > discard/warn about anything else. > > My original vision was to have the same file structure as the other > landscape types, but with the landscape.ini containing a reference to > the .txt file instead of a texture. > > Another possibility is to save the alt/az pairs directly into the > landscape.ini file, for example using the "array" feature in > QSettings: > http://qt-project.org/doc/qt-5.0/qtcore/qsettings.html#beginWriteArray > > Or we can have multiple implementations/input formats and detect which > one is used in a particular landscape file. :) > > If you need help with the data input code, I can make a small program > for creating/parsing such landcapes, similar to the location list > editor. (I have problems with building/running Stellarium at the > moment.) > > Regards, > Bogdan Marinov > ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Stellarium-pubdevel mailing list Stellarium-pubdevel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel