Frame revisions in Celx

[chris]

I'm looking for advice on how to resolve an issue with the usage of frames in Celx scripts.

Some quick background . . . Internally, Celestia uses coordinate conventions that are not standard in astronomy. The conversion is trivial: to convert a position vector R0 in Celestia's internal coordinates to R1 in the standard J2000 ecliptic system:

R1x = R0x
R1y = -R0z
R1z = R0y

(It amounts to a rotation of 90 degrees about the x-axis.)

In SSC files, Celestia's internal coordinate system is hidden: positions in FixedPositions, SampledOrbits, etc. are all given in standard astronomical coordinates. But, the non-standard coordinates are still used in celx scripts. I'd like to address this problem without breaking existing scripts. It's particularly important, because the coordinates generated by ScriptedOrbits (and the rotations produced by ScriptedRotations) are all in the standard coordinate system.

I've seen only a very few existing scripts that depend on the current definitions of reference frames: Clive Pottinger's Celestia Visual Guide, Harald Schmidt's azimuth-elevation script, and Toti's Gravity Simulator. But, there are almost certainly more out there that simply haven't been published, so I'm afraid to simply change how frames work. Another possibility is to add some sort of version tag to frame objects, along with new methods for creating frames: frames created with the new method would get the old version and maintain compatilibity, frames created with the new methods would use standard astronomical conventions for coordinates.

This idea could be extended even further. We could give the celestia object itself a version. Suppose that you could create a new celestia object like this:

Code: Select all

cel = celestia:newinterface("1.6.0")


Then, you'd could call all of the usual celestia object methods with cel. Any objects created from cel via newframe, etc. would inherit the new version tag and behave in the new manner. Obviously, things could get out of control with different functions behaving very differently across Celestia versions--even though compatibility would be maintained, documentation and code maintenance would be a headache. But, for a very few key changes such as coordinate conventions, the cost could be worthwhile.

--Chris

[t00fri]

Let me make a comment that is relevant for frames in general, but not specifically for this thread:

For an economic describtion of objects in various frames I would proceed quite differently.

Since physical observables must be independent of the choice of coordinates/frames, it is generally possible to subdivide the respective tasks into frame independent ones (invariants) and frame dependent ones. The frame independent ones are not always easy to isolate, but once obtained, one can evalue them in ANY convenient frame!

This can save lots of work/CPU power and is the proper way of approach.

Just an illustration: while any objects associated with vectors x1, x2 transform covarianty under frame transformations, the inner product x1.x2 is clearly one of many invariants one can form. Similarly one can form invariants using cross products of vectors, (x1^x2).x3, determinants = epsilon_ijk x1^i x_2^j x3^k etc. It's just a standard procedure to find them all...

Once all invariants have been set up in a given system, physically relevant quantities can ALL be expressed in terms of these invariants (and only these). Only unphysical things remain effectively coordinate/frame dependent. Such considerations would be of paramount importance in the context of appropriate frame dependent orbit displays which are still lacking in Celestia.

But never mind ...

F.

[chris]

Once all invariants have been set up in a given system, physically relevant quantities can ALL be expressed in terms of these invariants (and only these). Only unphysical things remain effectively coordinate/frame dependent. Such considerations would be of paramount importance in the context of appropriate frame dependent orbit displays which are still lacking in Celestia.

Certainly Celestia needs to be able to show an orbit in a reference frames other than the one in which it is defined. How should we best use invariants in the implementation of a more flexible orbit plotting system?

--Chris

[t00fri]

Once all invariants have been set up in a given system, physically relevant quantities can ALL be expressed in terms of these invariants (and only these). Only unphysical things remain effectively coordinate/frame dependent. Such considerations would be of paramount importance in the context of appropriate frame dependent orbit displays which are still lacking in Celestia.

Certainly Celestia needs to be able to show an orbit in a reference frames other than the one in which it is defined. How should we best use invariants in the implementation of a more flexible orbit plotting system?

--Chris

I don't want to suggest at this late stage of the matter, where most of the frame code has been developed already by you, to switch to such an approach based on invariants

Yet, it's perhaps intellectually interesting to mention a few relevant concepts.

What I touched upon, is based on a mathematically advanced approach to non-relativistic physics and notably frame transformations based on the concept of symmetry.

The latter is fundamental and naturally expandable!

I am talking of non-relativistic physics (mechanics) based on the Galilei group of symmetry transformations, which is the non-relativistic limit of the Lorentz group of relativistic mechanics.

Hence a formulation in terms of Galilei invariants is not only elegant and economic, but most importantly ready for an extension into special and general relativity lateron (Aha! )

Since this is clearly more advanced matter and this forum is inappropriate for more mathematically based discussions, let me just quote a typical paper that discusses things more or less as I would have done it, too. It certainly exposes the general spirit of finding and using (two-body) Galilei invariants for describing non-relativistic astro-mechanics with frame transformations and all that , for example.

++++++++++++++++++++++++++++++
http://arxiv.org/pdf/astro-ph/0605169
++++++++++++++++++++++++++++++

The essential point is that this method is perfectly analogous to what we use in many other areas of theoretical physics such as particle physics and general relativity/particle cosmology/field theory.

F.

[t00fri]

For those who are ignorant about what I am talking about, here is some Wiki basics:

http://en.wikipedia.org/wiki/Galilean_relativity

The Galilei group consists of coordinate transformations between systems in uniform relative motion using the Newtonian form of relativity; it is a 10-parameter group which contains the Euclidean group as a subgroup. The time is still a universally valid parameter, the transformation between reference frames only affects the space coordinates. The Euclidean distances are still invariant, but the transformations are allowed to be time-dependent. This group determines the form of Newton's equations of motion, and that of the Schr?¶dinger equation for a free spinless particle.

If we remove the space-time translations from the Galilei group we are left with a 6-parameter homogeneous Galilei group consisting of orthogonal transformations and Galilean 'boosts', which are transformations to coordinate systems in uniform relative motion and which coincide at time 0.

In the Lorentz-Einstein form of relativity the homogeneous Galilei group is replaced by another 6-parameter group which mixes the space and time coordinates: the Lorentz group. This is the group of real linear transformations of space-time (represented by 4x4 real matrices) which leave invariant the pseudo-Euclidean form

(ct)^2 - x^2 - y^2 - z^2

The Poincar?© group or inhomogeneous Lorentz group combines the Lorentz group with the 4-parameter group of space-time translations.

When we use a group of space-time transformations like the Lorentz group, we find that the energy is not an invariant; instead the energy and momentum will transform as a four-vector, the energy-momentum vector. The rest mass of a particle remains invariant.


F.

[chris]

Once all invariants have been set up in a given system, physically relevant quantities can ALL be expressed in terms of these invariants (and only these). Only unphysical things remain effectively coordinate/frame dependent. Such considerations would be of paramount importance in the context of appropriate frame dependent orbit displays which are still lacking in Celestia.

Certainly Celestia needs to be able to show an orbit in a reference frames other than the one in which it is defined. How should we best use invariants in the implementation of a more flexible orbit plotting system?

--Chris

I don't want to suggest at this late stage of the matter, where most of the frame code has been developed already by you, to switch to such an approach based on invariants

Perhaps not. But, if there's much to be gained from switching, then it's worth thinking about. I've read the Wikipedia page, but haven't had a chance do more than skim the paper.

What would be gained from switching to an invariant based approach? Efficiency? I don't think I understand how that would work--could you outline what you approach would look like? I think that would help me understand better exactly what you're proposing. Would it possibly help avoid extra calculations when accounting for light time delay--this would be valuable indeed.

Yet, it's perhaps intellectually interesting to mention a few relevant concepts.

What I touched upon, is based on a mathematically advanced approach to non-relativistic physics and notably frame transformations based on the concept of symmetry.

The latter is fundamental and naturally expandable!

I am talking of non-relativistic physics (mechanics) based on the Galilei group of symmetry transformations, which is the non-relativistic limit of the Lorentz group of relativistic mechanics.

Hence a formulation in terms of Galilei invariants is not only elegant and economic, but most importantly ready for an extension into special and general relativity lateron (Aha! )

Since this is clearly more advanced matter and this forum is inappropriate for more mathematically based discussions, let me just quote a typical paper that discusses things more or less as I would have done it, too. It certainly exposes the general spirit of finding and using (two-body) Galilei invariants for describing non-relativistic astro-mechanics with frame transformations and all that , for example.

++++++++++++++++++++++++++++++
http://arxiv.org/pdf/astro-ph/0605169
++++++++++++++++++++++++++++++

The essential point is that this method is perfectly analogous to what we use in many other areas of theoretical physics such as particle physics and general relativity/particle cosmology/field theory.

But that doesn't necessarily make it more appropriate for Celestia. Specifically, what problems would it solve? I don't claim to have read and understood everything in the paper, but it seems to be more appropriate for integrating the positions of gravitationally interacting bodies, whereas Celestia is just using precomputed trajectories for everything. Am I mistaken?

--Chris

[Fenerit]

Freefall.

[cpotting]

I'm looking for advice on how to resolve an issue with the usage of frames in Celx scripts.

I read through Fridger's suggestions for handling the the coordinate systems, and I am not ashamed to say that I was lost at the fifth paragraph of the first post (that's not bad for a guy who can total 4 numbers 5 times and give you 6 different answers!). But if I get the gist of what Fridger suggested, it would involve a major rewrite. I can't comment on that, but I will give my 2 cents worth, assuming that a simpler solution is what Chris is after...

Another possibility is to add some sort of version tag to frame objects, along with new methods for creating frames: frames created with the new method would get the old version and maintain compatilibity, frames created with the new methods would use standard astronomical conventions for coordinates.

This is where I cast my vote. Perhaps something along the lines of

Code: Select all

celestia:setreferencemethod(old)  (default is new)


This way, a one-line code change in the few scripts that need it would maintain backward compatibility.

This idea could be extended even further. We could give the celestia object itself a version. Suppose that you could create a new celestia object like this:

Code: Select all

cel = celestia:newinterface("1.6.0")


I would just warn, that to me anyway, this approach makes it look as if newinterface would support all of the previous versions of the celestia object.
If it would, how much "bloat" would that introduce?
If it doesn't, then how will the coder know what versions he can use as a parameter and which he can't. There have been many version numbers for Celestia.

That's my 2 cents... now I'm broke.

[t00fri]

I'm looking for advice on how to resolve an issue with the usage of frames in Celx scripts.

Some quick background . . . Internally, Celestia uses coordinate conventions that are not standard in astronomy. The conversion is trivial: to convert a position vector R0 in Celestia's internal coordinates to R1 in the standard J2000 ecliptic system:

R1x = R0x
R1y = -R0z
R1z = R0y

(It amounts to a rotation of 90 degrees about the x-axis.)

In SSC files, Celestia's internal coordinate system is hidden: positions in FixedPositions, SampledOrbits, etc. are all given in standard astronomical coordinates. But, the non-standard coordinates are still used in celx scripts. I'd like to address this problem without breaking existing scripts. It's particularly important, because the coordinates generated by ScriptedOrbits (and the rotations produced by ScriptedRotations) are all in the standard coordinate system.

I've seen only a very few existing scripts that depend on the current definitions of reference frames: Clive Pottinger's Celestia Visual Guide, Harald Schmidt's azimuth-elevation script, and Toti's Gravity Simulator. But, there are almost certainly more out there that simply haven't been published,
...
--Chris

All my PERL scripts for catalog extraction and transformation of DSO's (deepsky.pl, visualbins.pl and spectbins.pl) that are part of the sources and hence published, depend crucially on that strange convention! I wonder why these scripts are always forgotten...they constitute thousands of lines of PERL scripting code...

F.

[t00fri]

I'm looking for advice on how to resolve an issue with the usage of frames in Celx scripts.

I read through Fridger's suggestions for handling the the coordinate systems, and I am not ashamed to say that I was lost at the fifth paragraph of the first post (that's not bad for a guy who can total 4 numbers 5 times and give you 6 different answers!). But if I get the gist of what Fridger suggested, it would involve a major rewrite.

Indeed .. and that --for me-- is a main reason for being pretty unhappy with the present situation: Chris is mostly working on such things tacitly and I only learn about them from his usual brief posts:

" I have been working on such and such and commited the code to SVN"

As to the astrophysical/astromechanical methodology that underlies his code, Chris is only subjecting himself to "peer reviewing" by the other devs to a VERY limited amount, if any. This is quite unlike the other devs, including a certain very experienced Prof. in Theoretical Physics ...

This highly "uneven" situation is the real reason why at some point, I have given up to try and inject more explicitly how such things are really done ... because it's too late from the start and HENCE would always need substantial rewrites. In addition, any documentation about the underlying formulae that Chris used in his code is usually lacking. I certainly don't have the time and motivation to reconstruct his "homebrewn" underlying formalism for the frame transformations a posteriori from the committed code... Last not least, this forum is not made for exchanging mathematical formulae (before the Latex feature will at last be enabled)

The real advantage of an approach to frames via a (complete) set of frame invariants --as theoretical physicists would do it-- is that frame invariants need NOT be transformed and thus can be calculated in any convenient frame once for all. That saves CPU resources and storage and brings a lot of conceptual clarity! As a respective reminder, our orbit displays still look very odd in particular frames since they are not appropriately transformed along with the changes of reference frame .

but I will give my 2 cents worth, assuming that a simpler solution is what Chris is after...

Simplicity is often a deceptive statement, frequently reflecting peoples' lacking formation rather than objective facts...

F.

[chris]

I'm looking for advice on how to resolve an issue with the usage of frames in Celx scripts.

I read through Fridger's suggestions for handling the the coordinate systems, and I am not ashamed to say that I was lost at the fifth paragraph of the first post (that's not bad for a guy who can total 4 numbers 5 times and give you 6 different answers!). But if I get the gist of what Fridger suggested, it would involve a major rewrite.

Indeed .. and that --for me-- is a main reason for being pretty unhappy with the present situation: Chris is mostly working on such things tacitly and I only learn about them from his usual brief posts:

" I have been working on such and such and commited the code to SVN"

As to the astrophysical/astromechanical methodology that underlies his code, Chris is only subjecting himself to "peer reviewing" by the other devs to a VERY limited amount, if any. This is quite unlike the other devs, including a certain very experienced Prof. in Theoretical Physics ...

Nearly all my changes of consequence have been preceeded by some discussion on the forum and the dev list, or both. I'll also point out the ongoing forum discussion about how to add globular clusters to Celestia.

This highly "uneven" situation is the real reason why at some point, I have given up to try and inject more explicitly how such things are really done ... because it's too late from the start and HENCE would always need substantial rewrites. In addition, any documentation about the underlying formulae that Chris used in his code is usually lacking. I certainly don't have the time and motivation to reconstruct his "homebrewn" underlying formalism for the frame transformations a posteriori from the committed code... Last not least, this forum is not made for exchanging mathematical formulae (before the Latex feature will at last be enabled)

The real advantage of an approach to frames via a (complete) set of frame invariants --as theoretical physicists would do it-- is that frame invariants need NOT be transformed and thus can be calculated in any convenient frame once for all. That saves CPU resources and storage and brings a lot of conceptual clarity! As a respective reminder, our orbit displays still look very odd in particular frames since they are not appropriately transformed along with the changes of reference frame .

but I will give my 2 cents worth, assuming that a simpler solution is what Chris is after...

Simplicity is often a deceptive statement, frequently reflecting peoples' lacking formation rather than objective facts...

You've been alluding to your frame invariants approach for more than a year now without providing anything more than the vaguest hints about how it would help Celestia. If you can give a concrete example about how your approach would either add some important new functionality to Celestia, improve performance, or simplify the code I'd be very happy to join you in rewriting some of the Celestia frame code. But so far, nothing. I very much suspect that while frame invariants are indeed useful in the domain of theoretical physics, they would add nothing to Celestia.

I've delivered a working implementation of reference frames that's already proven useful to many people, including professionals in the space industry. You've tossed out phrases like "saves CPU resource and storage" and provided nothing whatsoever to back it up. You're professed dissatisfaction with my development approach provides you a convenient excuse for being so short on details, but I can't help thinking that real reason your 'proposal' remains so nebulous is that it's nothing more than a few half-formed ideas. I would welcome being proven wrong.

--Chris

[chris]

I'm looking for advice on how to resolve an issue with the usage of frames in Celx scripts.

Some quick background . . . Internally, Celestia uses coordinate conventions that are not standard in astronomy. The conversion is trivial: to convert a position vector R0 in Celestia's internal coordinates to R1 in the standard J2000 ecliptic system:

R1x = R0x
R1y = -R0z
R1z = R0y

(It amounts to a rotation of 90 degrees about the x-axis.)

In SSC files, Celestia's internal coordinate system is hidden: positions in FixedPositions, SampledOrbits, etc. are all given in standard astronomical coordinates. But, the non-standard coordinates are still used in celx scripts. I'd like to address this problem without breaking existing scripts. It's particularly important, because the coordinates generated by ScriptedOrbits (and the rotations produced by ScriptedRotations) are all in the standard coordinate system.

I've seen only a very few existing scripts that depend on the current definitions of reference frames: Clive Pottinger's Celestia Visual Guide, Harald Schmidt's azimuth-elevation script, and Toti's Gravity Simulator. But, there are almost certainly more out there that simply haven't been published,
...
--Chris

All my PERL scripts for catalog extraction and transformation of DSO's (deepsky.pl, visualbins.pl and spectbins.pl) that are part of the sources and hence published, depend crucially on that strange convention! I wonder why these scripts are always forgotten...they constitute thousands of lines of PERL scripting code...

F.

There weren't forgotten, but they're not relevant to this discussion. I was talking about a change to celx that wouldn't affect the internals of Celestia, thus the opening sentence of the topic:

I'm looking for advice on how to resolve an issue with the usage of frames in Celx scripts.

--Chris

[selden]

Chris,

I think I'm one of the people who are seriously confused by the current mixture of internal and external coordinate systems used by Celestia. Many of the Lua Scripted functions used by my Hale Telescope addon have had to include what seem to me to be arbitrary 90 degree rotations about various axes so that models are properly aligned and rotate correctly relative to one another on the screen. I've simply lost track of how the coordinate axes used by 3D design programs map to the different coordinate axes used by Celestia internally and externally. All three seem to be different

I'm not sure what to suggest except to agree that backward compatibility with some form of coordinate system versioning needs to be supported.. Certainly I'm not about to rewrite and redebug more than 7000 lines of code.

[chris]

Chris,

I think I'm one of the people who are seriously confused by the current mixture of internal and external coordinate systems used by Celestia. Many of the Lua Scripted functions used by my Hale Telescope addon have had to include what seem to me to be arbitrary 90 degree rotations about various axes so that models are properly aligned and rotate correctly relative to one another on the screen. I've simply lost track of how the coordinate axes used by 3D design programs map to the different coordinate axes used by Celestia internally and externally. All three seem to be different

I'm not sure what to suggest except to agree that backward compatibility with some form of coordinate system versioning needs to be supported.. Certainly I'm not about to rewrite and redebug more than 7000 lines of code.

Right--the point of the versioning proposal is to maintain complete compatibility for existing scripts, but to reduce the amount of confusion for people creating new scripts. The number of coordinate conventions could be reduced to two: the conventional astronomical coordinate system, and whatever is used by the modeler. In fact, even this modeler confusion could probably be alleviated by switching to a standard coordinate system internally. Another change that would be useful (and handled by the same versioning scheme) is to change the units for universal coordinates from 1e-6 light years to kilometers.

I do think that Clive is right: a boolean switch rather than a general versioning mechanism is most appropriate. The latter invites a proliferation of subtly different conventions and behaviors for functions, and really to limit the amount of confusion, we just want to make this change once.

--Chris

[t00fri]

All my PERL scripts for catalog extraction and transformation of DSO's (deepsky.pl, visualbins.pl and spectbins.pl) that are part of the sources and hence published, depend crucially on that strange convention! I wonder why these scripts are always forgotten...they constitute thousands of lines of PERL scripting code...

F.

There weren't forgotten, but they're not relevant to this discussion. I was talking about a change to celx that wouldn't affect the internals of Celestia, thus the opening sentence of the topic:

...

--Chris

Yes that's what I inferred at first, too. But then you continued like so:

In SSC files, Celestia's internal coordinate system is hidden: positions in FixedPositions, SampledOrbits, etc. are all given in standard astronomical coordinates.

That looked like your discussion was to be understood in a more general context, wasn't it?

F.

[t00fri]

Indeed .. and that --for me-- is a main reason for being pretty unhappy with the present situation: Chris is mostly working on such things tacitly and I only learn about them from his usual brief posts:

" I have been working on such and such and commited the code to SVN"

As to the astrophysical/astromechanical methodology that underlies his code, Chris is only subjecting himself to "peer reviewing" by the other devs to a VERY limited amount, if any. This is quite unlike the other devs, including a certain very experienced Prof. in Theoretical Physics ...

Nearly all my changes of consequence have been preceeded by some discussion on the forum and the dev list, or both. I'll also point out the ongoing forum discussion about how to add globular clusters to Celestia.

OK Chris, then please give us a pointer, where you explicitly discussed your underlying formalism of frame transformations before implementing the code. I don't mean some general bla bla, but actually the real math formalism of transformations that you specifically implemented. I cannot remember a single formula either symbolic or more explicitly that was exposed by you anywhere beforehand.

Sorry, since you never did this, I felt since one year that I better won't waste my time to work all the frame invariants etc out , just to get some friendly "no-go" response thereafter (because you understand your own stuff better and did it your way already ...) .

In contrast, I have laid open in the past a fair number of my more lengthy calculations in form of commented Maple Worksheet WEB outputs available in this forum, be it my theoretical approach preventing overlapping location labels (importance weights) for various planets and the Moon or the formalism of how comet tails develop in case of several suns etc... I have repeatedly displayed my various frame transformation routines on which both my galaxy orientations and that of my binary orbits are based. They are in human readable form. And of course there are my extensively commented PERL scripts in human readable form that explicitly document what I REALLY did...

Nothing anywhere explicit from you EVER. I remember how hard it was to get out your precise formulae about halo and core sizes of your stars as function of their brightness... Or how many mails it took to get this issue about frame transformation of orbits sorted out with you...All of these things you coded before we could discuss it concisely, while many users didn't like the results for your stars...

Your professed dissatisfaction with my development approach provides you a convenient excuse for being so short on details, but I can't help thinking that real reason your 'proposal' remains so nebulous is that it's nothing more than a few half-formed ideas. I would welcome being proven wrong.

I definitely give up on this whole issue after that sort of allegation (at least as concerns the official version of Celestia...) .

You would be surprised about the code I already did my way during these last weeks and months of being rather quiet around here. .

I'll also point out the ongoing forum discussion about how to add globular clusters to Celestia.

My code also includes globular cluster display (of course). My approach rests on procedural generation of globulars by implementing the characteristic cluster dimensions (r_c, r_t, r_h) statistically, exploits the integrated spectral type, color composition of red and blue stars from the horizontal branch (Horizontal-branch ratio, Dickens horizontal-branch morphological type). I am currently working to also incorporate the ellipticities that are understood via tidal pulls from relevant galaxies of the local group (MilkyWay, M31, LMC, SMC,...), which fixes the vector of the major spheroidal axis... Most importantly, it all applies to a recent (2005) catalog of globulars in other galaxies!

So what, never mind, "as usual from me", it's all hot air

F.

[chris]

Indeed .. and that --for me-- is a main reason for being pretty unhappy with the present situation: Chris is mostly working on such things tacitly and I only learn about them from his usual brief posts:

" I have been working on such and such and commited the code to SVN"

As to the astrophysical/astromechanical methodology that underlies his code, Chris is only subjecting himself to "peer reviewing" by the other devs to a VERY limited amount, if any. This is quite unlike the other devs, including a certain very experienced Prof. in Theoretical Physics ...

Nearly all my changes of consequence have been preceeded by some discussion on the forum and the dev list, or both. I'll also point out the ongoing forum discussion about how to add globular clusters to Celestia.

OK Chris, then please give us a pointer, where you explicitly discussed your underlying formalism of frame transformations before implementing the code. I don't mean some general bla bla, but actually the real math formalism of transformations that you specifically implemented. I cannot remember a single formula either symbolic or more explicitly that was exposed by you anywhere beforehand.

Frames as implemented in Celestia are very closely based on the implementation in SPICE, and their appropriateness there is well-demonstrated. There is detailed documentation of the Celestia's frames on the the WikiBook.

Sorry, since you never did this, I felt since one year that I better won't waste my time to work all the frame invariants etc out , just to get some friendly "no-go" response thereafter (because you understand your own stuff better and did it your way already ...) .

As I've said many times, I'm happy to revise how frames are handled by Celestia if there's a demonstrably superior approach.

In contrast, I have laid open in the past a fair number of my more lengthy calculations in form of commented Maple Worksheet WEB outputs available in this forum, be it my theoretical approach preventing overlapping location labels (importance weights) for various planets and the Moon or the formalism of how comet tails develop in case of several suns etc... I have repeatedly displayed my various frame transformation routines on which both my galaxy orientations and that of my binary orbits are based. They are in human readable form. And of course there are my extensively commented PERL scripts in human readable form that explicitly document what I REALLY did...

Nothing anywhere explicit from you EVER. I remember how hard it was to get out your precise formulae about halo and core sizes of your stars as function of their brightness... Or how many mails it took to get this issue about frame transformation of orbits sorted out with you...All of these things you coded before we could discuss it concisely, while many users didn't like the results for your stars...

Indeed, the new star code didn't work out as hoped. And so I reverted to the more-or-less the same approach that people were happy with before, except with the addition of the faster pointer sprite rendering path.

Your professed dissatisfaction with my development approach provides you a convenient excuse for being so short on details, but I can't help thinking that real reason your 'proposal' remains so nebulous is that it's nothing more than a few half-formed ideas. I would welcome being proven wrong.

I definitely give up on this whole issue after that sort of allegation (at least as concerns the official version of Celestia...) .

You would be surprised about the code I already did my way during these last weeks and months of being rather quiet around here. .

Then why not share some of this work? Such a secretive approach to development seems unnecessary in the open source world. I look forward to seeing the results of your work when it's ready.

I'll also point out the ongoing forum discussion about how to add globular clusters to Celestia.

My code also includes globular cluster display (of course). My approach rests on procedural generation of globulars by implementing the characteristic cluster dimensions (r_c, r_t, r_h) statistically, exploits the integrated spectral type, color composition of red and blue stars from the horizontal branch (Horizontal-branch ratio, Dickens horizontal-branch morphological type). I am currently working to also incorporate the ellipticities that are understood from tidal interactions between relevant galaxies of the local group (MilkyWay, M31, LMC, SMC,...), which fixes the vector of the major spheroidal axis... Most importantly, it all applies to a recent (2005) catalog of globulars in other galaxies!

So what, never mind, "as usual from me", it's all hot air

Well, where are the data files and code? And why no discussion either here, the dev list, or Celestial Matters? The work on globular clusters sounds fantastic, and would be a welcome addition to Celestia.

--Chris

[t00fri]

You would be surprised about the code I already did my way during these last weeks and months of being rather quiet around here. .

Then why not share some of this work? Such a secretive approach to development seems unnecessary in the open source world. I look forward to seeing the results of your work when it's ready.

I'll also point out the ongoing forum discussion about how to add globular clusters to Celestia.

My code also includes globular cluster display (of course). My approach rests on procedural generation of globulars by implementing the characteristic cluster dimensions (r_c, r_t, r_h) statistically, exploits the integrated spectral type, color composition of red and blue stars from the horizontal branch (Horizontal-branch ratio, Dickens horizontal-branch morphological type). I am currently working to also incorporate the ellipticities that are understood from tidal interactions between relevant galaxies of the local group (MilkyWay, M31, LMC, SMC,...), which fixes the vector of the major spheroidal axis... Most importantly, it all applies to a recent (2005) catalog of globulars in other galaxies!

So what, never mind, "as usual from me", it's all hot air

Well, where are the data files and code? And why no discussion either here, the dev list, or Celestial Matters? The work on globular clusters sounds fantastic, and would be a welcome addition to Celestia.

--Chris

In the recent past, I have repeatedly expressed my dissatisfaction with the direction that Celestia development takes. Each time you have reinterpreted my efforts as "convenient excuses" for "something" (see our discussion on the hires texture pack, for example). But don't forget, I am also getting PM's of consensus from other active members of this community...

Well, since some time, I am drawing my consequences of our continued discrepancies about what is important in Celestia and how it should be approached in a genuine team work effort!

It's a pity that there seems to be no other way after > 6.5 years!

F.

[chris]

Well, where are the data files and code? And why no discussion either here, the dev list, or Celestial Matters? The work on globular clusters sounds fantastic, and would be a welcome addition to Celestia.

--Chris

In the recent past, I have repeatedly expressed my dissatisfaction with the direction that Celestia development takes. Each time you have reinterpreted my efforts as "convenient excuses" for "something" (see our discussion on the hires texture pack, for example). But don't forget, I am also getting PM's of consensus from other active members of this community...

You were being unreasonable in that discussion of the hires texture back. Your claim that work on a high resolution texture set for Celestia could not begin until the scattering atmosphere code had been improved is absurd. It is the nature of collaboration that we accept some disagreement about the prioritization of tasks, but you seemed to have trouble with the fact reworking the atmosphere code wasn't at the top of my todo list.

Well, since some time, I am drawing my consequences of our continued discrepancies about what is important in Celestia and how it should be approached in a genuine team work effort!

Celestia is a genuine team effort already: it's based on the contributions and suggestions of dozens of people. If anyone has a complaint about the progress of Celestia development, I invite them to address me personally or speak openly about it on the forum.

It's a pity that there seems to be no other way after > 6.5 years!

I agree that it would be a pity, but disagree that there's no other way. What, for example, is the obstacle to adding your globular cluster changes to Celestia? It would be welcomed.

--Chris

[t00fri]

Well, where are the data files and code? And why no discussion either here, the dev list, or Celestial Matters? The work on globular clusters sounds fantastic, and would be a welcome addition to Celestia.

--Chris

In the recent past, I have repeatedly expressed my dissatisfaction with the direction that Celestia development takes. Each time you have reinterpreted my efforts as "convenient excuses" for "something" (see our discussion on the hires texture pack, for example). But don't forget, I am also getting PM's of consensus from other active members of this community...

You were being unreasonable in that discussion of the hires texture pack. Your claim that work on a high resolution texture set for Celestia could not begin until the scattering atmosphere code had been improved is absurd. It is the nature of collaboration that we accept some disagreement about the prioritization of tasks, but you seemed to have trouble with the fact reworking the atmosphere code wasn't at the top of my todo list.

Rarely, I am called unreasonable. To trigger off a systematic and continuing effort with extensive texture layer administration and all that is a huge effort. For that I just wanted to be sure in advance that the missing surface coloration code due to skylight will actually be available, when needed, given your known continuing "enthusiasm" for suspending spacecraft around planets and moons.

According to your judgement, the texture pack issue was only one "excuse of mine for something". My above frame-invariants proposal was another one... hmm

Well, since some time, I am drawing my consequences of our continued discrepancies about what is important in Celestia and how it should be approached in a genuine team work effort!

Celestia is a genuine team effort already: it's based on the contributions and suggestions of dozens of people.

I am NOT talking about dozens of devoted "helpers". I talk about people like myself who thoroughly understand the underlying astrophysical formalism besides the code, and try to optimize it. The Wikibook entries about frames were written AFTER you coded them already. There was never any concise reference where people with my physics background could critically check out your approach against better alternatives.

It's a pity that there seems to be no other way after > 6.5 years!

I agree that it would be a pity, but disagree that there's no other way. What, for example, is the obstacle to adding your globular cluster changes to Celestia? It would be welcomed.

--Chris

Well, for a number of good reasons, I feel seriously pushed towards thinking about alternatives. It starts with my frustration of being entirly dependent on your "taste", while you do what you please. That's NOT what I consider genuine teamwork. That's certainly NOT how I deal with my PhD students... Noone wants to dispute your authority in coding, although I was already invoked with VERY complex scientific coding projects when you still went to grammar school . Of course that's entirely different stuff in many respects, but still...

It would not be good to go into further detail about the rest in public.

While I know about some motivations of yours for your enhanced coding efforts in flightdynamics, these efforts introduce a VERY large bias into a balanced development of Celestia as a splendid alround 3d visualization platform of the Universe.

F.