Menu
▾
▴
Re: [Stellarium-pubdevel] star drawing
|
From: F. C. <fab...@go...> - 2008-05-14 08:14:40
|
Hi Johannes, On Wed, May 14, 2008 at 12:06 AM, Johannes Gajdosik <joh...@gm...> wrote: > Dear developers, dear Fabien, > > Yes, I had some progress concerning my experimental work on star > rendering. > For my taste the stars should look somewhat like in these screenshots. > > http://members.aon.at/johannes_gajdosik/Stars1.png > http://members.aon.at/johannes_gajdosik/Stars2.png > http://members.aon.at/johannes_gajdosik/Stars3.png > http://members.aon.at/johannes_gajdosik/Stars4.png > > (Easy quiz: does everybody know these constellations?) Your screenshots look promising, they look nice although I find the halos way too big at this zoom level but I guess it's just for showing the capabilities of the shaders. > My solution involves among other things: a parallelized geodesic grid > search, a new catalog format that requires really little main memory > for the stars, a vertex/fragment program for doing the actual > rendering. (Note that Stars1.png, Stars2.png use a different fragment > program than Stars3.png, Stars4.png.) > Because of these requirements I am not sure if it makes sense to > incorporate this code into stellarium. When some weeks ago the cheap > food disconter next to my door sold a Quad Core Computer with 3GB Ram > and NVidia series 8 graphic for about 700 Euro, I realized that the > time has come for programs that utilize these machines fully. For me > this means that shader programming and multithreading is a must, and > that the singleprocessor paradigma with graphics on the CPU is dead. As > a consequence I tolerate that my software will not run on old computers. > > Privately I now use 461306454 stars of the Nomad. But I plan to write a > conversion program (this is really easy, because it's just a tiny > change) for converting the 220000000 currently distributed stars into > my new format, so that you might be able to try my experimental program. > > Now how shall we proceed? > > I for my part will try to improve my star fragment program, and then > proceed to planet rendering on the GPU. This will be a challenging > task, because of the limited floating point accuracy in the GPU. Also > am not yet sure about the shadow of Saturns ring. > And stellarium? At the meeting and ever since Fabien has always spoken > against shader programming. Here I head into a different direction. > Also for me the star rendering in stellarium is definitely not fast > enough, although Fabien says it is. You will discover this quickly when > you try to reproduce my screenshots by drawing more stars. Also I want > to see faster planet rendering. Therefore I want to utilize the other > cores. But this time I will not try to force you into my way of doing > things. Also I must point out that what I do is somewhat experimental, > and there is no guarantee that maximum GPU usage, as I try to do, will > really be as successful as I assume. Because the shiny new Quad core > CPU might turn out to be idle. Anyway it is fun and I want to give it a > try. What you did sounds very interesting, and I will be happy if we can integrate them into stellarium. Unlike what you say I would really like to have a faster star rendering, e.g. I am fully aware that zooming on the milky way makes the program much slower, and I also would like to see more stars at the same time. To integrate the features into stellarium there are however 2 important conditions: the code should remain clean, this means respecting style and comments, encapsulating all the non-portable parts, this also means that we should avoid creating new external dependencies, e.g. using Qt library when possible (for threads, I/O, collections). This point is not negotiable because it determines the survival of the project. The second point is that all non portable code (shaders etc..) should have a fall back in case of non compatibility, and that good code design should be used to allow this to be done in a clean way (e.g. hidden behind a common API, like the new SkyDrawer class). I think it is usually possible to find such a satisfying design with little performance drop. We can discuss this point, and may decide to drop support for old hardware but I think if we do that we'll get hundred of very angry users.. Cheers, Fabien > > > > On 2008.05.13 12:23:43 CEST, Fabien Chéreau wrote: > > Johannes, > > Did you do any improvement on this subject? I am playing with a subset > > of the DSS here, and your stars rendering looks much more like the > > plates than the current rendering. If your new code would be used, > > both would look much more integrated. > > Fabien > > > > On Tue, Feb 26, 2008 at 1:01 PM, Fabien Chéreau > > <fab...@go...> wrote: > > > > > > > > > > > > On Tue, Feb 26, 2008 at 11:37 AM, Johannes Gajdosik > > > <joh...@gm...> wrote: > > > > On 2008.02.26 11:20:09 CET, Fabien Chéreau wrote: > > > > > Hi, > > > > > Very nice colors! > > > > > > > > Forgot to say: The colors are exacly the ones that are hardcoded > > in > > > > stellarium. > > > > > > > > > > > > > I am also quite interested to work on a new improved star > > > > > rendering code. I think we should try to make the code work on > > any > > > > > openGL > > > > > implementations by default (i.e. without any extensions). > > > > > > > > If you are interested I can send the test program that generates > > the > > > > given image. What I will do in my prototypical test > > implementation is > > > > this: Feed star coordinates, colors and sizes into a Vertex Array > > > > (which will later become a vertex buffer object) that I call with > > > > GL_POINTS (point sprites). > > > > > > I think the GL_POINTS may work better as before (e.g. for the size > > > parameter) (apparently openGL + Qt handles that better). However, a > > full > > > support may require to use sample buffer, which I deactivated > > because it is > > > very slow, at least on my computer. > > > > > > > The data is passed to my vertex program and > > > > finally to the frament program, which just computes the colors > > without > > > > a single texture lookup. > > > > For performance reasons I parallelize the star lookup and > > coordinate > > > > computation. > > > > > > > > > > Sounds interesting. It would be very great if the interface to > > SkyDrawer > > > could allow to make that transparently, i.e. calling > > drawPointSource() > > > method would just feed the Vertex Array instead of displaying, and > > display > > > everything at once later. This would need to introduce another > > method in the > > > style of "prepareDraw". For example we could introduce a > > > pointSourcesDrawBegin() and pointSourcesDrawEnd(), and every call to > > > drawPointSource() in between would do that. This could allow strong > > > optimizations and in the same time keep a clean and simple > > interface hiding > > > the details. > > > > > > In general, also make sure that those optimizations are really > > > significative, because now the star rendering itself is really not > > the > > > slowest part of the program on my computer (excepted maybe in very > > dense > > > regions) > > > > > > Fabien > > > > > > > > > > > > > > Johannes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You probably noticed that all this code was moved to SkyDrawer. > > I > > > > > think it > > > > > is possible to make it quite fast because there is now 1 call to > > > > > "prepareDraw" which initializes the openGL state before drawing > > stars > > > > > and > > > > > then multiple calls to drawPointSource or drawDiskSource. > > > > > I think we should also move into this class the methods to use > > to > > > > > draw a > > > > > planet or any 3D shape on which sun-light and eye adaptation > > applies > > > > > (and > > > > > probably merge it with drawDiskSource). > > > > > The big advantage of having all the sky rendering code into this > > > > > class is > > > > > that it will allow to improve the interaction between eye > > adapatation > > > > > and > > > > > the currently drawn objects. > > > > > Cheers, > > > > > Fabien > > > > > > > > > > On Sun, Feb 24, 2008 at 10:29 PM, Johannes Gajdosik < > > > > > joh...@gm...> wrote: > > > > > > > > > > > I just wanted to give some results of my experiments of star > > > > > rendering. > > > > > > In this example I use a fragment program, but the same result > > could > > > > > > also be achieved with multitexturing and blending. > > > > > > > > > > > > Yours, > > > > > > Johannes > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > > > This SF.net email is sponsored by: Microsoft > > > > > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > > > _______________________________________________ > > > > > > Stellarium-pubdevel mailing list > > > > > > Ste...@li... > > > > > > > > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
