Celestia Forums

Guys, Celestia is growing and will continue to grow, so I'm wondering if it's not time to talk a bit about the containing of the official package and it's organization.

I will give here my point of view (I?€™m not saying it should be like this, this are just some ideas), which is also in relation with some others threads concerning the quality of addons.
I start from the fact that the official package is becoming quite big, and place should be done for futures enhancements, then have a look to a possible restructuration of some directories within Celestia Resources, then some ideas about external high quality addons.


*****************

To do some place:

1) The Celestia official pack should be free from "human prints", no spacecraft models at all.

2) All the actual models should be released as official extension pack on Celestia official page.

3) Some asteroids models and textures should also be removed and released as official extension pack on Celestia official page next to expanded asteroids catalogs.

All official extension packages/files should be based on scientifical datas (maps, models, catalogues, etc). The ideal (easier for public) would be the use of installers for those packages/files.

Example of official extension packages (to download and install from Celestia official page):

Spacecrafts (Lowres) -> the actuals :

galileo.3ds
galileo.xyz
cassini.3ds
cassini.xyz
huygens.3ds
huygens.xyz
apollo.3ds
apollo.ssc
skylab.3ds
skylab.ssc
marsodyssey.3ds
marsglobalsurvr.3ds
shroxmars.ssc
gemini.3ds
mercury7.3ds
shroxclassic.ssc
hubble.3ds
iss.3ds
iss-cap1.jpg
iss-mc1.jpg
iss-mc31.jpg
iss-sol1.jpg
mir.3ds

Asteroids:

amalthea.3ds
amalthea.cmod
amalthea.jpg
eros.3ds
eros.cmod
eros.jpg
eros.cms
ida.3ds
ida.cmod
ida_locs2.ssc
bacchus.3ds
bacchus.cmod
etc...

Etc?€¦


*****************

Organization:


POINT 1: Renaming Data to Core with only:

asterisms.dat
boundaries.dat
hdxindex.dat
saoxindex.dat
solarsys.ssc
starnames.dat
stars.dat
stars.txt



POINT 2: Data folder (with sub hierarchy pre-established, only used for official files):

- Models folder:

deimos.cmod
deimos.3DS
phobos.cmod
phobos.3DS
asteroid.cms
halley.3ds
halley.cmod
roughsphere.cms
S0.pts
Sa.pts
Sb.pts
SBa.pts
SBb.pts
SBc.pts
Sc.pts


- Textures folder:

-> lowres -> actuals less some asteroids maps
-> medres -> actuals less some asteroids maps
-> highres -> only earth maps


- Locations (all locations files should end with "_locs") folder:

solsys_locs.ssc
world-capitals.ssc
jupmoons2.ssc
mars_locs2.ssc
marsmoons2.ssc
merc_locs2.ssc
minormoons.ssc
moon_locs2.ssc
nepmoons2.ssc
numberedmoons.ssc
ring_locs.ssc
satmoons2.ssc
uranmoons.ssc
venus_locs2.ssc


- Catalogues folder:

revised.stc
deepsky.dsc
spectbins.stc
visualbins.stc
extrasolar.ssc
extrasolar.stc
nearstars.stc
outersys.ssc


POINT 3: Extras folder used for external addons.


*****************

Concerning high level realistic addons (I'm thinking in the best map/models creators):

- They should be presented on Celestia official page as a "must have".

- A charter for the maps creation should be done; for example for whatever BIG (VT,DDS) map you want to present, obligation in creating maps for Low, Med, and HighRes folders (512, 1k, 2k) then in altsurfaces all others res (4k png/dds, 8k.., 16VT)...

- A charter for 3D models should also be done (obligation of optimization)

For all fictional addons, ML should find a solution to present a ?€?top ten?€

Hello ElChristou,

I agree with your essay. Your goals of improving the quality of the credibility are beneficial. Maybe you can consider the software verifying the checksum of the solarsys.ssc file. The results of that verification of the authenticity of the loaded file can be used to warn or reject edited versions. The use of the extras directory would then become enforced. The purity of the scientific representation would be ensured, to some degree. The extras directory could be the launching pad for fiction and speculations, with no entry point easily available to corrupt the best efforts of serious contributors.

Hey, no more opinions? if I'm saying stupidity someone can tell me, no problem

Chris,

among the developers this is a VERY old issue, indeed:

around every new release we tend to "encourage ourselves", with requesting separate official default and hires texture packs...it's just a LOT of work to do these tasks well for the FULL amount of bodies within Celestia.

Just have a look in the developer's list. It has happened again this time (1.4.0 final)


Bye Fridger

PS: The only request that is even older is to devise a more sensible key shortcut scheme for Celestia

Well I'm ready to work on this in this new year if needed...

ElChristou wrote:Well I'm ready to work on this in this new year if needed...

Excellent!

I think such a task can only be completed at high standards if an /experienced/ team in these matters is cooperating.

There are many tricky facets to this:

1) Procedural work to achieve e.g. a /reproducable/ re-coloration, brightness & contrast normalization in various circumstances . E.G writing PS, GIMP or ImageMagick scripts...

2) Experience with 16bit grayscale image manipulations (=> noiseless normal maps) that in PS 7.x are available only in very limited amount. Gimp has NONE.
ImageMagick has a complete 16bit version!

3) scientific aspects...

4) Merging photographic texture pieces after doing cylindrical projections with respective software (that is NOT available for OS-X in binary form). This would be particularly relevant to keep up-to-date wrto ongoing results from space missions (Cassini,...)

Bye Fridger

I would simply like to say that I very much enjoy Celestia because it's
supposed to be a factual representation of what we think we know
about the universe.

To further the quality and authenticity of Celestia, I'd be happy with
whatever proposals the developers would care to implement.

I very much enjoy some of the more "speculative" textures and
add-ons distributed with this marvelous software. As a non-scientist,
however, I can easily be mis-lead by a texture which has been tinted or
colored based on someone's opinion of what a celestial body "Ought To"
look like.

To be quite honest with you, I still don't know what color Mars is. One
texture displays the planet using a deep, rust red texture. Another
version shows the planet as having a bright orange exterior. There are
also other versions which display Mars as a dull reddish-brown orb.

Is there no way to standardize these things?

Please understand here. I'm not complaining. I just find myself
siding with the people who wish to see factual representations
of our universe.

Dr. Schrempp is a staunch believer in realism, but even he doesn't have
the time and energy it takes to investigate every object displayed in our
favorite program.

Perhaps the deveopers need to involve themselves in a simple
check-off system for proposed textures or new additions to Celestia.
In other words, perhaps new candidates for inclusion in the official
releases should be passed down the developer mailing list so that each
developer could give a "Go/No Go" evaluation based on their particular
areas of expertise.

I know this is probably not a new idea, but it's one which might have
merit in this ever-changing environment.

At any rate, sorry to take up so much time with this thought, but I really
do love this program. Again thanks VERY MUCH to all of you
for providing this spectacular piece of software.

Cheers.

Inventory Checkup Program for Celestia

It is proposed that an open source Perl program be written to check
the inventory of planets, satellites, etc. on your computer system.
It would have a database of past file attributes, such as an attribute
that indicated whether a file has been obsoleted or officially approved.
This utility program would examine the files on
disk drives you specify. It would calculate a checksum that is unique
for the data in the file. The 8 byte checksum changes greatly if even
one character is edited in the file. Therefore, each file version is uniquely
identifiable, regardless of the file name. The checkup program would
report the following results :

1 Name of the file for the celestial bodies.
2 Names of bodies in the file and a count.
3 Number of duplicates or alternatives with similar names
4 Date of matching checksum, with file history link available
5 Alert for unmatched checksum that indicates an edited file.
6 Offer to record new history notes for unmatched file.
7 Fiction Flag
8 Official Core Item Flag
9 Quality rating
10 Textures available
11 Missing files that are available in the official distribution
12 Missing files that are available in unofficial distributions

The program could have a "snapshot" command to record all this
information in a new database. Then, at future times, a new report
could be produced to indicate how much change has occurred in
the Celestia files. Version numbers for celestia.exe files can be
reported.

The report can have 4 levels of detail.
Level 1 report : data is unchanged or changed compared to certain dates
Level 2 report : list changed files
Level 3 report : list changed bodies
Level 4 report : list changed body parameters

The open source nature of this work would allow several people to
gradually implement the more detailed features over a long period
of time.

Donations Facility

The new Perl program would include a "Donations Facility" to track textures
and bodies that have already been offered for donation to Celestia, but which
have not been reviewed for quality ratings. A donor would post a notice of
donation in a Forum. A file would be available that has collected all of
the donation notices. The Perl program would be able to read the
standardized notice forms and report all available donations in a single
report. The Celestial Motherload would be inventoried by the program, and
other storage facilities would be listed by URL.

Archiving Facility

The program would be able to copy categories of data files to backup
directories in a quick and useful way. A category of "edited" files could
be used to back up only files that are not standard files. After a new
installation of files is downloaded, the program could be used to replace
the new standard files with the custom data files, quickly and easily.
Also, the archive could have small and large collections that are selectable
from a list of implementations. The user could erase the data with one
command and put a different data set in place. Different users could swap
collections of data for bodies in simple steps using the program. Then
the imported collection could be stored and be replaced by a different
collection quickly. Each user would have a copy of the Perl program to
independently take inventories and perform quality assurance activities.


Modular Program

For several contributors to work on this, the work can be planned to be modular
so stand-alone partial implementations can make progress without all the
other modules. Integration could then occur by any person who wants to
put together several capabilities.

t00fri wrote:

ElChristou wrote:Well I'm ready to work on this in this new year if needed...

Excellent!

I think such a task can only be completed at high standards if an /experienced/ team in these matters is cooperating.

There are many tricky facets to this:...

Well, before talking about effective work, personally I need to have the adequate structure to work with. This structure can be committed right now and some first ?€?official?€