search

CelestiaProject / Celestia

Real-time 3D visualization of space.
https://celestiaproject.space
GNU General Public License v2.0
1.87k stars 310 forks source link

Celestial objects unification #173

Closed pirogronian closed 2 years ago

pirogronian commented 5 years ago

To me, every (or nearly) celestial object should be able to have:

  1. Trajectory (maybe except location)
  2. Parent
  3. Children
  4. Position in catalog I also suggest to create unified catalog class, which would have:
  5. Name (of catalog), maybe description
  6. Catalog numbers
  7. Catalog names(?) Because I don't know much about catalogs, let me know if I misunderstanded something.
375gnu commented 5 years ago

1-3 They do. 4 Catalog is useless for planets & moons as they belong to their star. Dunno if it required for asteroids and comets. 5-7 Currently Celestia has only one catalog (HIP), other catalogs are either crosslinked to it (e.g. SAO) or map their numbers to HIP numbers (Tycho). Not all catalogs use simple linear numbering (e.g. Tycho has a-b-c numbering). So if you want to fix the problem, you should have a very good understanding of it, simply adding a virtual parent for all C++ classes will not solve it magically.

pirogronian commented 5 years ago

1-3 They do.

No. DSO don't move nor have parents.

  1. It's safer to have that option :) I'll try to understand as much as I can about catalogs.
375gnu commented 5 years ago

Because they are DSO. What parent can a galaxy have?

pirogronian commented 5 years ago

Other galaxy. Or center of mass in a group. For example, Centaur Galaxy near Milky Way or both Magellan Clouds. Moreover, DSOs include also globular clusters and nebulae, that certainly can have parent with galaxy center and trajectory around it. Edit: Moreover, there could be many other purposes, for example purely teoretic galaxy motions presentation or so... Celestia may be used not necessarily for display real objects & features only.

375gnu commented 5 years ago

So, summarizing, you propose to add some dead code, because now we don't have any code to support clusters/nebulae/etc trajectories/universe expansion and so on.

pirogronian commented 5 years ago

As overall code size will be reduced, objections about dead code sounds a bit abstract...

375gnu commented 5 years ago

Are you sure that it will be reduced? Can you prove this?

pirogronian commented 5 years ago

I think so. Now we have 3 base classess for objects, every with own databade, data parser and name handling. It causes existence of three different (although very similar) browse widgets. I propose one universal clasd for (nearly) evetything , with all common code. It can also include code for all special cases or let it for subclassing. If user want galaxy encircling around immovable planet - let it be. I just dont want waste my effort just to prevent user radiculus ideas...

375gnu commented 5 years ago

Just do fgrep -R StarDetails.

Star & DSO browsers can be merged, but merging Solar system browser doesn't worth efforts.

pirogronian commented 5 years ago

So, StarDetails can be left in star.h/cpp, while common data can be moved to, for example, celestialobject. Solar system browser will need a refit, where it will come to extrasolar planets...

375gnu commented 5 years ago

What common data? Radius?

pirogronian commented 5 years ago

Radius also. But first of all: parent, children, trajectory, visibility, category (already is) and (maybe) names list/catalog entries.

375gnu commented 5 years ago

Don't you see that this means that your proposal is useless?

pirogronian commented 5 years ago

No, I don't see. Why?

375gnu commented 5 years ago
  1. because the code is already written
  2. because there is no nontrivial methods common (except trajectory)
  3. and there is no codepaths where star or planet or dso can be used. stars has own path, planets have their own, and so dsos.

First you should implement a new feature which can be implemented better if all object has common ancestor and only then implement your proposal. Not just because you was told that common virtual classes are "the only right thing"

pirogronian commented 5 years ago
  1. So I want to eliminate code, rathwr, than write new.
  2. Still worth an effort.
  3. What is "codepath"? Do you mean rendering method?

you should implement a new feature which can be implemented better if all object has common ancestor

That's how I planned to try it. Where I argued that common virtual class is the only right thing? Btw look at DeepSkyObject definition... :-)

375gnu commented 5 years ago

"code path" = "code", but related to some particular feature.

DSOs have a lot of shared, they are not implemented in this way just because in textbooks it's said so.