Celestia Forums

After a pretty stormy landing of my spacecraft on the Venus surface, the heavy metal door opened slowly and the time seemed endless... Wow!

=============== Have a click! ===================
Amazing Thunderstorm Simulation mpeg (3Mb)
==============================================



Here is the underlying algorithm by Dobashi, Tsuyoshi Yamamoto, Tomoyuki Nishita of how to render efficiently lightnings, taking into account scattering effects due to clouds and atmospheric particles.

http://nis-lab.is.s.u-tokyo.ac.jp/~nis/ ... htning.pdf

See also

http://forum.celestialmatters.org/viewt ... =4042#4042


Enjoy,
F.

I've been meaning to reply to your post at CM but I was running a few HiRise images and they bring my computer to it's knees. So I leave it be.
This is really impressive. They almost look real. . If only..........
cartrite

Recently, Celestia seems to be getting more and more "swallowed" by mundane body frames, reference marks, terminator circles and the like... . Hence, occasionally, I can't resist to remind everyone about the exciting graphics challenges of "celestial" atmospheres and other spectacular phenomena in our Universe, waiting to be visualized ...

F.

t00fri wrote:Recently, Celestia seems to be getting more and more "swallowed" by mundane body frames, reference marks, terminator circles and the like... . Hence, occasionally, I can't resist to remind everyone about the exciting graphics challenges of "celestial" atmospheres and other spectacular phenomena in our Universe, waiting to be visualized ...

Ideas are cheap. Code isn't.

--Chris

chris wrote:

t00fri wrote:Recently, Celestia seems to be getting more and more "swallowed" by mundane body frames, reference marks, terminator circles and the like... . Hence, occasionally, I can't resist to remind everyone about the exciting graphics challenges of "celestial" atmospheres and other spectacular phenomena in our Universe, waiting to be visualized ...

Ideas are cheap. Code isn't.

--Chris

In physics this saying is also well known, but reversed


F.

t00fri wrote:

chris wrote:

t00fri wrote:Recently, Celestia seems to be getting more and more "swallowed" by mundane body frames, reference marks, terminator circles and the like... . Hence, occasionally, I can't resist to remind everyone about the exciting graphics challenges of "celestial" atmospheres and other spectacular phenomena in our Universe, waiting to be visualized ...

Ideas are cheap. Code isn't.

--Chris

In physics this saying is also well known, but reversed

In that case, welcome to the world of software engineering.

--Chris

Fridger, I haven't react to your post on CM or here because... well because outside Celestia those rendering are physics and math questions and of course it's not my field; now I'm really not sure this kind of stuff is for Celestia... Mie scattering is fine because we need it to draw the atmospheres, but if we had to implement details like that, then first we would need volumetric clouds, then real time 3d topo, then and only then we could think in details such lightning or auroras...

ElChristou wrote:Fridger, I haven't react to your post on CM or here because... well because outside Celestia those rendering are physics and math questions and of course it's not my field; now I'm really not sure this kind of stuff is for Celestia... Mie scattering is fine because we need it to draw the atmospheres, but if we had to implement details like that, then first we would need volumetric clouds, then real time 3d topo, then and only then we could think in details such lightning or auroras...

Quite right, Christophe.

Of course, I was NOT to suggest that we start right away with implementing lightnings into Celestia . Yet that stuff is certainly fascinating... And of course, I'd fancy real time volumetric clouds and multiple scattering of light from them, when thinking about diving into the atmosphere of Earth, Titan or Venus...

Fast Real-Time Cloud Simulation by Nishita et al.(Click!)

The above lightning video and notably the algorithm was to really serve as a general plea not to neglect the plethora of exciting atmospheric phenomena together with multiple light scattering, in favour of more such mundane flight dynamics complexity. The latter will MAINLY interest some specialized branches of space agencies. In my view, for them this is cheap "outsourcing" of work that they want to be done...

I am certainly aware that this is also largely a matter of personal taste. Hence, I don't think there is much sense in breaking off another discussion about this issue here. Yet I wanted to express my opinion about all this once for all in writing. Certainly a main reason why I have pretty much decoupled lately from Chris' intensive "exercises" in flight dynamics...

I am aware that frames are a useful concept in Celestia. Besides some flight dynamics professionals, also a few add-on creators will be happy, presumably. On the other hand, the definition of and transformations among reference frames are pretty much "bread and butter" subjects for every grown-up theoretical physicist, and thus no interesting challenge whatsoever. So that may just explain my personal lack of enthusiasm in this matter

Chris wrote:Ideas are cheap. Code isn't.
...
In that case, welcome to the world of software engineering.

It is certainly NOT my intention to be impatient. I am rather talking about the relative weights in the distribution of our coding efforts for Celestia...

Research physicists are often concerned with HUGE and very difficult coding tasks. So was I for several decades! Hence I know very well that solid and mathematically involved code takes a lot of time and effort. And I have A LOT of personal experience in that! The coding tasks in pure science are entirely different in nature from the typical tasks in software engineering. No GUI's, no manuals and the like . Only the mathematical results count, usually displayed in columns of numbers or long algebraic expressions. The code may well have to run for a whole week without intermission, before the desired results are ready

F.

t00fri wrote:The above lightning video and notably the algorithm was to really serve as a general plea not to neglect the plethora of exciting atmospheric phenomena together with multiple light scattering, in favour of more such mundane flight dynamics complexity. The latter will MAINLY interest some specialized branches of space agencies. In my view, for them this is cheap "outsourcing" of work that they want to be done...

There are various reasons that I work on Celestia--challenge; a chance to learn more about various topics in astronomy, physics, and graphics; simulating vistas in places that we have no hope of visiting in my lifetime; and contributing in some way to the exploration and understanding of the universe. Doing some work for space agencies means that I get to spend a lot more time pursuing these things without compromising Celestia's open source status. If the space agencies are getting a good deal, then fine: there's hardly a surfeit of funding at ESA or NASA.

I am certainly aware that this is also largely a matter of personal taste. Hence, I don't think there is much sense in breaking off another discussion about this issue here. Yet I wanted to express my opinion about all this once for all in writing. Certainly a main reason why I have pretty much decoupled lately from Chris' intensive "exercises" in flight dynamics...

As it happens, I'm very interested in the visualization of flight and orbital dynamics. It's a happy coincidence that I can even earn a bit of money doing it and at the same time contribute (a little, and indirectly) to space exploration. And, as a product of the work I've done to make Celestia a better tool for spaceflight visualization, we now have better performance (see Selden's results for his Hale add-on) and planetshine.

I am aware that frames are a useful concept in Celestia. Besides some flight dynamics professionals, also a few add-on creators will be happy, presumably. On the other hand, the definition of and transformations among reference frames are pretty much "bread and butter" subjects for every grown-up theoretical physicist, and thus no interesting challenge whatsoever. So that may just explain my personal lack of enthusiasm in this matter

The coding of frames support in Celestia provided a few engaging challenges. It's very often the case that something conceptually simple is still tricky to express in software, especially when that software needs to run at 60 frames per second.

t00fri wrote:

Chris wrote:Ideas are cheap. Code isn't.
...
In that case, welcome to the world of software engineering.

It is certainly NOT my intention to be impatient. I am rather talking about the relative weights in the distribution of our coding efforts for Celestia...

Research physicists are often concerned with HUGE and very difficult coding tasks. So was I for several decades! Hence I know very well that solid and mathematically involved code takes a lot of time and effort. And I have A LOT of personal experience in that! The coding tasks in pure science are entirely different in nature from the typical tasks in software engineering. No GUI's, no manuals and the like . Only the mathematical results count, usually displayed in columns of numbers or long algebraic expressions. The code may well have to run for a whole week without intermission, before the desired results are ready

My rather curt replies to your earlier message were an expression of the frustration I feel when people pose big ideas without any apparent appreciation of what effort might actually be required to implement them. Generally these ideas are very large in scope and come without any specific recommendations, e.g. "add gravity to Celestia". I know that you're better informed than the people with that particular oft-seen request, but some of the ideas that you continually allude to are vaguely specified. Many times, you've smugly insinuated that something is amiss in Celestia's implementation of frames because they're not formulated with relativity in mind. But in all that time, you've failed to provide concrete examples of how these frames would be useful to Celestia users. A link to a Wikipedia article, an arXiv paper, and a winking smiley are not enough to motivate me to get serious about implementing a relativistic approach to frames. My guess is that somewhere in between relativistic hand-waving and working C++ code, there's a big "Oh no that won't work at all" moment waiting. I'd be happy to be proven wrong: give some motivating examples, and some evidence that we can do frames your way and not kill Celestia's performance in the vast majority of situations when relativistic effects are visually imperceptible.

As for atmospheres, I think we're in agreement that the current scattering atmospheres need to be improved. The scattersim app demonstrates that we've got a good theoretical handle on the problem. As with some many problems, it's now JASMOP: "Just A Simple Matter Of Programming" How do you calculate the scattering integral in real time for a million pixels a frame? At any altitude? For any physically plausible scattering and absorption coefficients, scale heights, and phase function parameters. And you only get to use 8-bit lookup tables, etc. I certainly do plan on working on this very interesting problem some more. I'll take you at your word that you're not impatient, but still: if you'd want to make it happen faster, code is a lot more helpful than links to papers, however interesting those papers are.

--Chris

OK, Chris,

I think this was a fair exchange of our views...

Just a few little corrections/additions:

Chris wrote:...but some of the ideas that you continually allude to are vaguely specified.

For you perhaps...Some people also don't understand your code ...

Many times, you've smugly insinuated that something is amiss in Celestia's implementation of frames because they're not formulated with relativity in mind. But in all that time, you've failed to provide concrete examples of how these frames would be useful to Celestia users.

This you misunderstood. I just used frames in special relativity as an illustration, since I know all the respective results by heart. It's the "show case" for frames, so to speak. I would NOT want to suggest relativistic frame definitions for Celestia, as it is set out at present. But as you know, I am thinking BEYOND Celestia since a pretty long time. In that cosmological context, however, it's general relativity frames that are relevant.

What I repeatedly emphasized is that a theoretical physicist would approach frames differently, no matter what their context is. For parametrizing frames, one starts with frame - invariant variables and -- when these are exhausted -- one completes the set by covariant variables. The frame invariants one never needs to transform and can calculate them in the most convenient frame. That is not only elegant, it saves CPU time as well . For Celestia proper, we are not talking about Lorentz transformations of frames, but rather about Galilei transformations, which constitute the familiar non-relativistic limit of the Lorentz group of frame transformations.

Since I typically just get to read your brief SVN commit reports about what you did at the frame front, there is not much room left for telling you in detail how theoretical physicists would approach these things...
It's too late typically and I tend to give up before trying to become a missionary

Still...there must be SOMETHING we have learned in the 10 years between the Bachelor, the PhD and 3x2 years of PostDoc experience thereafter, before research physicists are usually considered "grown-up"

"Code is NOT everything"

F.

t00fri wrote:OK, Chris,

I think this was a fair exchange of our views...

Just a few little corrections/additions:

Chris wrote:...but some of the ideas that you continually allude to are vaguely specified.

For you perhaps...Some people also don't understand your code ...

Many times, you've smugly insinuated that something is amiss in Celestia's implementation of frames because they're not formulated with relativity in mind. But in all that time, you've failed to provide concrete examples of how these frames would be useful to Celestia users.

This you misunderstood. I just used frames in special relativity as an illustration, since I know all the respective results by heart. It's the "show case" for frames, so to speak. I would NOT want to suggest relativistic frame definitions for Celestia, as it is set out at present. But as you know, I am thinking BEYOND Celestia since a pretty long time. In that cosmological context, however, it's general relativity frames that are relevant.

Right, for an application specialized for cosmological visualization, some treatment of general relativity becomes essential.

What I repeatedly emphasized is that a theoretical physicist would approach frames differently, no matter what their context is. For parametrizing frames, one starts with frame - invariant variables and -- when these are exhausted -- one completes the set by covariant variables. The frame invariants one never needs to transform and can calculate them in the most convenient frame. That is not only elegant, it saves CPU time as well . For Celestia proper, we are not talking about Lorentz transformations of frames, but rather about Galiley transformations, which constitute the familiar non-relativistic limit of the Lorentz group of frame transformations.

Since I typically just get to read your brief SVN commit reports about what you did at the frame front, there is not much room left for telling you in detail how theoretical physicists would approach these things...
It's too late typically and I tend to give up before trying to become a missionary

Still...there must be SOMETHING we have learned in the 10 years between the Bachelor, the PhD and 3x2 years of PostDoc experience thereafter, before research physicists are usually considered "grown-up"

Certainly! Which is why I'm asking you for more details on some of your proposals. You've got much more background in physics topics, so you can help me and others make the jump from theory to implementation. I'd really like to know--for example--how a reformulation of frames might simplify the code in Celestia, save CPU cycles, or make it possible to implement some previously tricky feature (light time delay, perhaps?) The current implementation doesn't preclude further development if there's a compelling reason to do it.

"Code is NOT everything"

Agreed.

--Chris