problems with star textures!!!!! all equal ones...

[brunetto_64]

I have noticed that star textures that I visualize on the program are the same ones...
the color of stars is the same... white texture...
also antares is white ... that is the problem? I have installed version 1.5.0 and also 1.4.1
version...
and the error is the same one.
the old version 1.3.2 instead is corrected!!

Version 1.3.2:


Version 1.4.1:


Version 1.5.0:


what's wrong???

[selden]

Nothing is wrong. Chris made that change intentionally, although many people prefer having separate surface texture images for the different SpectralTypes.

The stars do have a slight coloration controlled by their SpectralType. Also, you can provide a surface texture for any particular star if you want.

http://www.lepp.cornell.edu/~seb/celest ... eters.html
describes how to do that.

[brunetto_64]

this is easy for the stars of which I know the stc files
the problem is that I wanted
to change the texture of Gliese 581,
but its parameters aren't present
in the "nearstars.stc" file...(for example)
and I don't open the star.dat file...
(therefore I will have to gain the parameters from the astronomical data)

[Cham]

Yes, the new star code is lame in 1.5.0. I personally think that the stars are now extremelly dull to watch. Their texture is dull, their atmosphere is dull, the stars are simply boring.

I hope Chris will change his mind about the stars

[t00fri]

Yes, the new star code is lame in 1.5.0. I personally think that the stars are now extremelly dull to watch. Their texture is dull, their atmosphere is dull, the stars are simply boring.

I hope Chris will change his mind about the stars

++++++++
So do I....
++++++++

There are still pending discussions and concrete proposals of mine for the stars' halo/core ratio etc since months. Chris promised to get back to them, but didn't so far.

"physical nonsense" display e.g. here:
http://www.celestiaproject.net/forum/viewtopic ... 18&start=8

Here my proposal of 'compromise via a "reduction of realism"':
http://www.celestiaproject.net/forum/viewtopic ... 8&start=13

I don't want to repeat myself too often...so I gave up.

In any case, the stars as they are are hardly acceptable to make it into 1.5.0 final.

Bye Fridger

[ElChristou]

I also agree... Perhaps stuff should be dev one by one till complete success of the process... Seems there too much in the pipe... just my 2 cents...

[t00fri]

I also agree... Perhaps stuff should be dev one by one till complete success of the process... Seems there too much in the pipe... just my 2 cents...

Absolutely!

There are many little changes & fixes and quick partial "graphical attempts" here and there in recent months,
e.g. such things

http://www.celestiaproject.net/forum/viewtopic ... 79&start=0

+++++++++++++++++
but the stuff that is REALLY crucial for an OVERALL satisfactory display AND for a consistent development of associated textures is still pending without any visible progress!
+++++++++++++++++


E.g.

++++++++++++++++++++++++
--Stars
--"Physical nonsense" displays (see my above post)
--Atmospheres & Surface colors: http://www.celestiaproject.net/forum/viewtopic ... 79&start=0
--Thick atmospheres (Titan & friends)
--Modelling stuff (=> Cham's concerns)
--Sensible DXT5nm definition
--Stars.txt issues as widely discussed
-- Good/correct orbit algorithms in connection with frame transforms, as I have discussed extensively.
++++++++++++++++++++++++

It's just revealing to have a good look at the sun and the sky in Stellarium for example to see what is possible here with standard cards ...

Bye Fridger

[brunetto_64]

and and in fact as it wrote t00fri another similar little problem with add-on:



two planet c...
little differences with bobdolesrevenge1's add-on of gliese581 system and the stardat parameters???

[t00fri]

and and in fact as it wrote t00fri another similar little problem with add-on:
...

Please remember, however, ADD-ON's are mostly a USER affair.

Bye Fridger

[brunetto_64]

sorry if me they are bad expressed,(sorry, sorry for my poor english)
is probably that
to calculate the orbital parameters
it can be difficult,
and I must tanks bobdole for its add-on!!!!

[tech2000]

May I ask why there is no public roadmap for Celestias development.
I'm not asking for a roadmap with dates and so, but just a simple one where one can follow the development of Celestia and also see what the future will bring.

How about it Chris?

If there is one that I have totally missed, where can I find it?

Best regards,
Anders

[chris]

It's just revealing to have a good look at the sun and the sky in Stellarium for example to see what is possible here with standard cards ...

The Sun does look good in Stellarium . . . But, the challenge of rendering stars in Celestia is vastly more difficult. Stars need to look good not just from the surface of planets, but from any distance. Same with the sky.

--Chris

[chris]

--Stars

Specifically?

--"Physical nonsense" displays (see my above post)

It's a consequence of additive blending, and not so nonsensical as you suggest. I think that stars as implemented now look more realistic than in your proposal.

--Atmospheres & Surface colors: http://www.celestiaproject.net/forum/viewtopic ... 79&start=0
--Thick atmospheres (Titan & friends)

Yes, this still needs to be addressed, and I think it is the most complicated coding task remaining for 1.5.0 final.

--Modelling stuff (=> Cham's concerns)

Meshes are working quite well, I think. There does seem to be a problem with cmodtool on the Mac producing seams. It definitely does not happen on the Windows version (perhaps cmodtool isn't using the --weld option for cmodfix?)

--Sensible DXT5nm definition

I responded to you in email about this. The code change is trivial. It's a matter of deciding whether to break existing dxt5nm textures in order to conform to what the NV texture tools produce.

--Stars.txt issues as widely discussed

The star database builder needs to be fixed, but corrections in stars.stc mean that Celestia users see stars in the right locations. Thus, I think it's lower priority than other issues and should wait until 1.5.1.

-- Good/correct orbit algorithms in connection with frame transforms, as I have discussed extensively.

I think that this should be a post-1.5.0 feature. Obviously, things are not ideal as they are, but we've survived through many Celestia versions with orbits always drawn in their default frames.

And another reminder . . . Please, please, please . . . Instead of (or in addition to) posting lists of bug reports and complaints in threads like this one, use the SourceForge tracker:

http://sourceforge.net/tracker/?atid=12 ... unc=browse

(And thanks to those who have been using it already . . .)

--Chris

[t00fri]

It's just revealing to have a good look at the sun and the sky in Stellarium for example to see what is possible here with standard cards ...

The Sun does look good in Stellarium . . . But, the challenge of rendering stars in Celestia is vastly more difficult. Stars need to look good not just from the surface of planets, but from any distance. Same with the sky.

--Chris

Yes, Celestia faces a wider and thus way more difficult rendering task over all. Undisputed. But knowing the code structure in render.cpp, one may say that e.g. the rendering of the sky as seen from a planetary surface is a rather contained task in Celestia, and comparable to the one in Stellarium. The latter looks significantly more natural, though. Also the atmospheric phenomena incorporated into the new Wordwind 1.4 tend to look better than in Celestia.

In short, the competition is closing up, since progress in Celestia has been stagnating on this important front for many months.

The stars look nowhere satisfactory in Celestia, if a wider range of brightness is taken into consideration. I think many of the more knowledgable Celestians agree on that.

The new Mie atmospheres were a promising start, but also got stuck, half way.

Bye Fridger

[t00fri]

--Stars

Specifically?

Sorry, I quoted the "specifics" very concisely above and earlier in various other places. You promised to get back to my proposals. But you did not so far.

--"Physical nonsense" displays (see my above post)

It's a consequence of additive blending, and not so nonsensical as you suggest. I think that stars as implemented now look more realistic than in your proposal.

I am aware of the coding reasons. But it is a fact that we are displaying /physical/ nonsense because of difficulties in coding. Whatever the reasons, displaying physical nonsense is ALWAYS a bad option!

My proposal of limiting the halo/core ratio AVOIDS displaying physical nonsense for now. That to me appears more essential than /partially/ better realism.

I actually have never shown examples of bright stars with my proposed max 25% halo/core. I doubt that your bright stars which have halo/core>>1 (!) can be considered more realistic. My reduction of the halo/core ratio eliminates the nonsense displays at least.

A few days ago I once more went carefully through your present star display in the actual CVS code. There were MANY concrete examples that looked really bad.
See also Cham's corresponding statements...

--Sensible DXT5nm definition

I responded to you in email about this. The code change is trivial. It's a matter of deciding whether to break existing dxt5nm textures in order to conform to what the NV texture tools produce.

I know what to do codewise, but YOU got to take the lead here.

Otherwise there will be stagnation. We mainly have discussed the alternative options via email. It's obvious that I can't distribute my new tools, for example, until this issue is cleared from the Celestia perspective.

The old nvdxt tool now has an option -switchRG that neatly allows to toggle between the two dxt5nm options. nvcompress is not as far yet. Also it must be agreed what to put into the fourCC strings...I wrote you also about this earlier.

-- Good/correct orbit algorithms in connection with frame transforms, as I have discussed extensively.

I think that this should be a post-1.5.0 feature. Obviously, things are not ideal as they are, but we've survived through many Celestia versions with orbits always drawn in their default frames.

I tend to disagree. We have survived before all your new frame stuff was there. Now --with the new frame options-- as I have made evident, the implicit assumption that orbits are "frame independent" again leads to physically inconsistent displays. Once frame transformations have been introduced, orbit transforms must come hand in hand.

And another reminder . . . Please, please, please . . . Instead of (or in addition to) posting lists of bug reports and complaints in threads like this one, use the SourceForge tracker:

http://sourceforge.net/tracker/?atid=12 ... unc=browse

(And thanks to those who have been using it already . . .)

--Chris

Well, as long as we still got to work out the conceptional roadmaps for hitherto unsatisfactory rendering attempts, I think hiding the respective discussions in a secluded bug tracker is suboptimal.

Bye Fridger

[chris]

--Sensible DXT5nm definition

I responded to you in email about this. The code change is trivial. It's a matter of deciding whether to break existing dxt5nm textures in order to conform to what the NV texture tools produce.
[/quote]

I know what to do codewise, but YOU got to take the lead here.

Otherwise there will be stagnation. We mainly have discussed the alternative options via email. It's obvious that I can't distribute my new tools, for example, until this issue is cleared from the Celestia perspective.

The old nvdxt tool now has an option -switchRG that neatly allows to toggle between the two dxt5nm options. nvcompress is not as far yet. Also it must be agreed what to put into the fourCC strings...I wrote you also about this earlier.
[/quote]

Taking care of the easy one first . . .

My understanding is that we agreed to do nothing with the new RXGB FourCC code for now.

As for the channel mapping, I will revert Celestia to using the old (x, y) = (green, alpha) mapping that nvcompress uses.

Any objections? And once this is done, would you agree that dxt5nm support is complete?

--Chris

[ElChristou]

--Modelling stuff (=> Cham's concerns)

Meshes are working quite well, I think. There does seem to be a problem with cmodtool on the Mac producing seams. It definitely does not happen on the Windows version (perhaps cmodtool isn't using the --weld option for cmodfix?)

Chris I remember you that the weld option is not the problem; seems to me that the CmodTool have been dev with simple models in mind, mostly with one mesh like asteroids; in this optic, re generate normals with a smooth angle of 30 and more solve all seams problem on such simple models.

Now a complex model with hundreds of meshes receiving each one a particular smoothing setting cannot be process via generate normal. Doing this would eliminate all fine tuning of smoothing along the whole model.

Just look at my prerelease of the Apollo CSM, the only way I found to have a texture without seam on a cylindrical mesh is to split the models in two, from a side all textured meshes with a weld and generate normals cmod conversion, on the other, the rest, without generate normals to not loose the fine tuning...

Now is there something to do with the cmod tools to solve this? I don't know, you are the one who can tell us...

[chris]

-- Good/correct orbit algorithms in connection with frame transforms, as I have discussed extensively.

I think that this should be a post-1.5.0 feature. Obviously, things are not ideal as they are, but we've survived through many Celestia versions with orbits always drawn in their default frames.

I tend to disagree. We have survived before all your new frame stuff was there. Now --with the new frame options-- as I have made evident, the implicit assumption that orbits are "frame independent" again leads to physically inconsistent displays. Once frame transformations have been introduced, orbit transforms must come hand in hand.

It's not a question of consistency. The displays of orbits is consistent right now: every orbit is shown in the reference in which it is defined in the stc or ssc file. As to whether this is always desirable, we both agree that it is not.

It's also not a problem that's new with the introduction of 1.5.0 reference frames--if in 1.4.1 you defined the Pluto-Charon system relative to an invisible barycenter object, the orbit of Pluto would show up as the same 3000km circle you see in 1.5.0.

My point is that flexible reference frames for orbit path rendering are a new feature, not a bug fix, and thus can be reasonably deferred until 1.5.1. It's actually a feature that I'm very excited to work on; I'd much rather work on it than fix bugs, but that would push the 1.5.0 final release further into the future.

--Chris

[chris]

It's just revealing to have a good look at the sun and the sky in Stellarium for example to see what is possible here with standard cards ...

The Sun does look good in Stellarium . . . But, the challenge of rendering stars in Celestia is vastly more difficult. Stars need to look good not just from the surface of planets, but from any distance. Same with the sky.

--Chris

Yes, Celestia faces a wider and thus way more difficult rendering task over all. Undisputed. But knowing the code structure in render.cpp, one may say that e.g. the rendering of the sky as seen from a planetary surface is a rather contained task in Celestia, and comparable to the one in Stellarium.

Not true . . . The sky in Celestia must look good from any altitude. You can't have a special case for the view from a planetary surface. How would this view change as you moved gradually further from the surface? It has to change continuously, and this is not possible if you suddenly switch rendering models.

I understand how to make atmospheres in Celestia more realistic--the hard part is to develop code that is fast as well as realistic. I believe that the time invested in this is worthwhile; but understand that we simply can't use a special case model like Stellarium does (which is based on this paper: http://www.cs.utah.edu/vissim/papers/sunsky/sunsky.pdf)

--Chris

[selden]

Now is there something to do with the cmod tools to solve this? I don't know, you are the one who can tell us...

You might want to investigate the possibility of a CMOD export script for your 3D modelling software. That way the normals you define while modelling would be preserved in the final CMOD model. Cmodfix then would be used only to translate ASCII CMOD files into binary.