Big bugs in 1.5.0 Pre 2

[Christophe]

If you make that change, please go ahead and check it in; otherwise I'll do it later today. I think that there may be an MSVC compiler flag to enable ANSI for loop scoping conventions, which would help avoid breaks like this in the future.

I'm just reading this thread now, I checked in the fix about an hour ago

I also reported a similar red Earth bug, including the shaders log, to the mailing list.

[t00fri]

Indeed Chris,

I forgot about it: In agreement with Christophe's report I also found that your

#define VERTEX_BUFFER_OBJECTS_ENABLED

had a rather negative effect on my 64k VT tile display....

Bye Fridger

[chris]

fyi:

Celestia as built this morning (6:35 EDT)
crashes when viewing Saturn
on my system at work.

System:
2GB, 1.86GHz Core2Duo, WinXP Pro SP2
Quadro FX 550, ForceWare 91.36

I'll update Forceware shortly to the current Quadro version, 91.85, but thought I'd let you know now, since that'll take a while.

That problem should already have been fixed by a checkin made at 5am PDT--I was up late, not early The bug existed in CVS for only a few hours; you just happened to pick the wrong time to update from CVS.

--Chris

[selden]

This morning's Celestia still crashes with the newer v91.85 Quadro graphics drivers. I can't rebuild Celestia until I get home, so further testing on this system at work will have to wait until tomorrow.

[selden]

Wednesday morning: I rebuilt from CVS at about 5:15 AM EDT. Viewing Saturn doesn't crash Celestia on my home system.

A new(?) visual anomaly: orbit paths sometimes (but not often) are partially or completely visible in front of a planet where they should be obscured. The overlap amount flickers and varies with viewpoint distance. It seems to be more easily reproducible on the outermost planets like Neptune. (a precision problem? This is not the issue of the path being drawn some distance away from the orbiting body: it does intersect when drawn properly.)

Here's an example:


and a url:
view-orbit-path

[chris]

It's not unnecessary work--you definitely found a bug with the red Earth. With my latest checkin, night lights+normal maps+specular will not work. Do you think that you may have night textures disabled now?

--Chris

Beautiful!!! I got my red Earth back...Ahem. For some
reason the rendering path had shifted from OpenGL 2.0
and that was the reason for the nice natural (non-red)
display of mother Earth.

So indeed no vasted work. Good. As a cross-check: the
red globe is gone as soon as I switch off the night lights.

I checked in a fix an hour ago. I tested night lights successfully with every combination of specular, normal maps, and eclipse shadows.

--Chris

[t00fri]

Indeed, Chris,

with your 1-hour-ago fix my beautiful red Earth has left me . With and without nightlights.

However, I can confirm Selden's findings: The selected path of Neptun sometimes is visible in front of that planet, while it should lead right through its center (and thus be invisible)

Bye Fridger

[rthorvald]

The problem with offset XYZ coords persists. Though so far, it always seems to happen only with LongLat origins.

At the stage i am in my work, the XYZ bug is what i really need info on: is this is a bug in Pre 2 or in Pre 1? I am not getting anything done before i know that...

Chris,
I *really* need to know if this is a Pre 1 or Pre 2 bug. It is much more
important to know where the bug is than it is to get it fixed. My work is at a
complete standstill because i can??t aim for compability with either version
without this info...

- rthorvald

[tech2000]

The problem with offset XYZ coords persists. Though so far, it always seems to happen only with LongLat origins.

At the stage i am in my work, the XYZ bug is what i really need info on: is this is a bug in Pre 2 or in Pre 1? I am not getting anything done before i know that...

Chris,
I *really* need to know if this is a Pre 1 or Pre 2 bug. It is much more
important to know where the bug is than it is to get it fixed. My work is at a
complete standstill because i can??t aim for compability with either version
without this info...

- rthorvald

Runar:

v1.5.0pre3 should be released in a few days... Let's hope this is fixed in that version..

Bye, Anders

[chris]

The problem with offset XYZ coords persists. Though so far, it always seems to happen only with LongLat origins.

At the stage i am in my work, the XYZ bug is what i really need info on: is this is a bug in Pre 2 or in Pre 1? I am not getting anything done before i know that...

Chris,
I *really* need to know if this is a Pre 1 or Pre 2 bug. It is much more
important to know where the bug is than it is to get it fixed. My work is at a
complete standstill because i can??t aim for compability with either version
without this info...

- rthorvald

Runar,

I finally looked at your problem and detail. The short answer is that there's no bug in Celestia.

The more detailed answer is that several ssc properties were changes from single to double precision between pre1 and pre2 (and a couple even after pre2!). The most recent of these changes was to PrecessionRate on March 4th, and I noticed you use this in your ssc file. It's the changes to these rotation parameters that are probably causing you grief. Because the missile is specified relative to a LongLat object, it's in a rotating coordinate system and thus affected by the precision changes to rotation parameters. Your problems are compounded by the fact that missile was launched > 700 years in the past, and the default epoch for rotation parameters is Jan 1, 2000. That's a long time for the tiny difference in rotation rate to accumulate, leaving your object far away from the intended place.

The one bit of good news is that all these necessary precision changes are done. If you use a version of Celestia built from CVS after March 4, your add-on will be future proof.

--Chris

[rthorvald]

The one bit of good news is that all these necessary precision changes are done. If you use a version of Celestia built from CVS after March 4, your add-on will be future proof.

Thank you for your detailed reply! This is everything i need to continue.

- rthorvald

[rthorvald]

The most recent of these changes was to PrecessionRate on March 4th, and I noticed you use this in your ssc file. It's the changes to these rotation parameters that are probably causing you grief. Because the missile is specified relative to a LongLat object, it's in a rotating coordinate system and thus affected by the precision changes to rotation parameters. Your problems are compounded by the fact that missile was launched > 700 years in the past, and the default epoch for rotation parameters is Jan 1, 2000

By changing the epoch (for the planet), i cannot get a closer match than about 1000 kilometers, whereas the difference between Pre 1 and Pre 2 is ca. 1144 kilometers for the objects associated with this longlat (about 25 different XYZ files). The precessionrate only affects the "mother object"??s orientation, not its position on the surface (with a discrepancy of more than 1100 km), so i wonder if there isn??t something more at work.

If not, what do you suggest is the shortest route here? I have checked the actual position of the LongLat definition against a texture backdrop, and it does not move relative to the surface. Have you done anything with how dates are calculated between Pre 1 and 2 at all?

- rthorvald

[rthorvald]

Edit to the above:
I think i just don??t understand some of the consequences of your update before march 12:

you are right in that it has to do with the precessionrate of the LongLat: the longlats who lacks a precessionrate property does not drift between Pre 1 and 2.

It does not matter, since i now know this and can update the neccecary files. It just bugs me that i don??t understand *why* precessionrate causes the point to move.

Anyhow, thanks again for the explanations.

- rthorvald

[jgrillo2002]

wait. if you get the fixes by the cvs version, then where can I find the recent Celestis CVS?

[selden]

Celestia is maintained on SourceForge.
http://sourceforge.net/projects/celestia

You can view and download individual files from the CVS archive at
http://celestia.cvs.sourceforge.net/celestia/celestia/

You can checkout the entire CVS archive by using a command of the form

cvs -z 3 -d:pserver:anonymous@celestia.cvs.sourceforge.net:/cvsroot/celestia checkout celestia/

Details of the command will vary depending on which cvs client you use.

[neo albireo]

I tried to compile with XCode just now, but build failed. I'm not experienced whatsoever, so far I was almost always lucky and builds succeeded. If there is anything simple and quick to make build succeed, please tell me. There are so many improvements now every day, I would really like to test

[ANDREA]

I tried to compile with XCode just now, but build failed. I'm not experienced whatsoever, so far I was almost always lucky and builds succeeded. If there is anything simple and quick to make build succeed, please tell me. There are so many improvements now every day, I would really like to test

I agree with neo albireo, and as I am absolutely ignorant of compiling, can some of the compiling "experts" give an advice on where to find a clear explanation on what must be done, avoiding me (us?) a long digging among zillions of web links on this subject, please?
I would be very pleased to check the new cvs as they appear, together with all the connected stuff (like the new Chris' sprites cmods).
Thanks a lot

Andrea

[selden]

Xcode is used for Mac programming. Someone with Mac programming experience will have to describe its requirements.

Once you've got a working compilation environment, it's easy to rebuild Celestia. (I type 4 commands under Windows: get update, define library locations, cd to celestia directory, makerelease.bat. In principle, this could be reduced to 1 command.) Setting up the environment can be rather difficult.

There have been several Topics discussing how to set up the environment for building Celestia under Windows. One is at
http://www.celestiaproject.net/forum/viewtopic.php?t=6255

[dirkpitt]

I tried to compile with XCode just now, but build failed. I'm not experienced whatsoever, so far I was almost always lucky and builds succeeded. If there is anything simple and quick to make build succeed, please tell me. There are so many improvements now every day, I would really like to test

Hi, I'm in charge of the current Mac OS X version.
Could you copy and paste your build error messages into a post? Also, what're your Xcode and Mac OS X versions?

Usually, as the other non-developer Mac users who have experience with compiling latest versions can atest to (ElChristou, Cham, rthorvald, ...), an SCM > Update Entire Project, followed by a Build ought to work. There's no special developer-only trick to make compiles work everyday.

[jgrillo2002]

Celestia is maintained on SourceForge.
http://sourceforge.net/projects/celestia

You can view and download individual files from the CVS archive at
http://celestia.cvs.sourceforge.net/celestia/celestia/

You can checkout the entire CVS archive by using a command of the form

cvs -z 3 -d:pserver:anonymous@celestia.cvs.sourceforge.net:/cvsroot/celestia checkout celestia/

Details of the command will vary depending on which cvs client you use.

ok but I use CVS Tortise and it doesnt want to work. I actually typed in the command line on what you said and I dont think it recognizes it