Big bugs in 1.5.0 Pre 2

[rthorvald]

I have just compared Pre 2 with Pre 1, that is:
- Until now, i have used Steven??s build from january. Yesterday, i got a copy
of the newest in CVS from ElChristou, to do some testing. This review, then is on the
differences between these two. There are some big differences:

I have tested with my Ran scenario, which is pretty taxing, i guess. The test was done
on Intel OSX 10.4.8.

1
Pre 2 is much slower and unresponsive than Pre 1. It uses *time* to load textures
and particularily CMODs, that just isn??t noticeable in Pre 1. Performance is "choppy".

2
Emissive models are washed out: instead of texture and coloring, they are shown in an
uniform, deep red color. No detail, just an uniform red color everywhere.
This happens ONLY under OGL 2.0: not in other render paths.

3
There??s something wrong with locations: In Pre 1, when i use a CelUrl to goto Ran, i end
up roughly where one would expect - a little offset from where you would endup in 1.4.1.
But: in Pre 2, i will always end up 336 KiloParsecs (!!) from the target. It works
the other way around, too: a Celurl saved with Pre 2 are 336 KPC away if opened with Pre 1.
It??s like the galaxy has been turned on its head...

4
The most dramatic one: XYZ coordinates are about 8 kilometers off in Pre 2 compared to Pre 1.

... I know changes were made between 1.4 and 1.5 as to how positions were calculated: this
actually gave me several weeks of work to convert the data files for Ran from 1.4 to 1.5...
But now it has happened with XYZ values between Pre 1 and Pre 2 - and i hope i won??t have to
re-write the seventy-five XYZ files i have in Ran...

Now, it might well be that it is the clock that is off instead of the XYZ coords. It would
make sense, since the offset aren??t constant: some XYZ files work, some are offset. It is
either the clock, or it is related to the XYZ origin. I will investigate more on this. But
the timekeeping was changed between 1.4 and 1.5, so probably a bug has sneaked in between
Pre 1 and Pre 2 here...

- rthorvald

[rthorvald]

Re [4]:
I am pretty sure it is the clock that is off, since i find that XYZ position displacement vary between a few kilometers and several hundred.

This worries me quite a bit, since i have an enormous amount of work put into interactions of a huge number of models, and between Pre 1 and Pre 2, the Ran project is falling apart...

- rthorvald

[Cham]

Runar,

I have none of the problems you described, on my system (G5 OS X 10.4.9), except maybe about the bug #3. The red models under OGL2 may be related to your video card drivers. Are you sure your system supports OGL2 ? I can't tell about the time problems you're experiencing.

Developing a large addon project for a software which is itself in a developing phase is very risky. Personally, I much prefer to create "small" addons, with a simple structure, so I don't fall on frustrating problems about features changes which may occur frequently while the software is developped. I've experienced this before, with models rendering, especially with depth sorting. I had to return frequently in my modeler to change some pieces, fighting constantly against the "corrections" done to CVS Celestia. This is very frustrating when you think your model was finished.

Bug #3 in your list (?) : There's an annoying bug, related to URLs stored in the favorite list. Adding a simple star, or using a recent CVS built, may broke many of my favorite items in my favorite menu. I never told about this problem before. It's a serious one, since I'm using LOTS of favorite links. Now, most of them are broken. They are getting me at a wrong location.

[tech2000]

Runar,

I have none of the problems you described, on my system (G5 OS X 10.4.9), except maybe about the bug #3. The red models under OGL2 may be related to your video card drivers. Are you sure your system supports OGL2 ? I can't tell about the time problems you're experiencing.

Guys,

I can confirm that there are atleast some sort of problem with red models with the CVS. I have downloaded Vincent's latest compiled version of Celestia.exe (celestia_1.5_cvs.exe) to use with the lua edu tools and when I look at Cham's Earth's Interior it turns red in OGL2, but NOT if I use the official v1.5.0 pre2 executable. I'm ofcourse using the latest ATI drivers (v6.4) in my Windows Vista machine.

Bye, Anders

[rthorvald]

The red models under OGL2 may be related to your video card drivers. Are you sure your system supports OGL2 ?

Yes, i??m sure. It works exactly as it should in Pre 1. In Pre 2, with no changes to my config, the models - all of them - are red, with NO texturing.

Developing a large addon project for a software which is itself in a developing phase is very risky.

Of course, i know that. I did expect things to change between versions, which is why i did all the modelling and texture work first, and the data files just these last few months. However, after the change from 1.4 to 1.5, i thought things could safely be written to 1.5, since the issues with time and positioning were discussed and explained to me when 1.5 Pre 1 came out.

had to return frequently in my modeler to change some pieces, fighting constantly against the "corrections" done to CVS Celestia. This is very frustrating when you think your model was finished.

Yes... Though i expect that, now, and plan for it. But when the SSC and XYZ files breaks between versions, it is more than just inconvenient... I now have 75 XYZ files and thousands of SSC entries that was pieced together intricately, and that now is a ton of unconnected bits and pieces...

Now, i am not complaining, i know Celestia is unfinished. However, i must know what the benchmark is, so to speak - whic model it is correct to work towards - to be able to get anything done... I am sure the developer??s goals haven??t changed from Pre 1 to Pre 2 - which means it is a bug. But is it in Pre 1 or Pre 2? Can i safely assume it is in Pre 2 and continue working, or should i take the time to convert everything to Pre 2?

- rthorvald

[chris]

I have just compared Pre 2 with Pre 1, that is:
- Until now, i have used Steven??s build from january. Yesterday, i got a copy
of the newest in CVS from ElChristou, to do some testing. This review, then is on the
differences between these two. There are some big differences:

I have tested with my Ran scenario, which is pretty taxing, i guess. The test was done
on Intel OSX 10.4.8.

1
Pre 2 is much slower and unresponsive than Pre 1. It uses *time* to load textures
and particularily CMODs, that just isn??t noticeable in Pre 1. Performance is "choppy".

I haven't observed that myself . . . Did you get a debug version of the program? If that's not it, could you find a specific case that's slower in your version of Celestia than in pre1? A case where there's just a single model that's slower than before, ideally with nothing else visible.

2
Emissive models are washed out: instead of texture and coloring, they are shown in an
uniform, deep red color. No detail, just an uniform red color everywhere.
This happens ONLY under OGL 2.0: not in other render paths.

I just checked in a fix for this . . . There was a shader bug that wasn't caught by the NVIDIA driver's GLSL compiler. I downloaded a tool that forces strict conformance for the compiler, so bugs like this shouldn't slip through again.

3
There??s something wrong with locations: In Pre 1, when i use a CelUrl to goto Ran, i end
up roughly where one would expect - a little offset from where you would endup in 1.4.1.
But: in Pre 2, i will always end up 336 KiloParsecs (!!) from the target. It works
the other way around, too: a Celurl saved with Pre 2 are 336 KPC away if opened with Pre 1.
It??s like the galaxy has been turned on its head...

This is surprising . . . There's nothing I can think of that should cause such a huge discrepancy.

4
The most dramatic one: XYZ coordinates are about 8 kilometers off in Pre 2 compared to Pre 1.

... I know changes were made between 1.4 and 1.5 as to how positions were calculated: this
actually gave me several weeks of work to convert the data files for Ran from 1.4 to 1.5...
But now it has happened with XYZ values between Pre 1 and Pre 2 - and i hope i won??t have to
re-write the seventy-five XYZ files i have in Ran...

Now, it might well be that it is the clock that is off instead of the XYZ coords. It would
make sense, since the offset aren??t constant: some XYZ files work, some are offset. It is
either the clock, or it is related to the XYZ origin. I will investigate more on this. But
the timekeeping was changed between 1.4 and 1.5, so probably a bug has sneaked in between
Pre 1 and Pre 2 here...

This sounds very much like the clock difference, though that change went in before the first prerelease. I'll check the commit logs and see if there was a later adjustment to the time. Do constant XYZ files always work? Or is there some other thing that the working XYZ files all have in common?

--Chris

[Cham]

The red models under OGL2 may be related to your video card drivers. Are you sure your system supports OGL2 ?

Yes, i??m sure. It works exactly as it should in Pre 1. In Pre 2, with no changes to my config, the models - all of them - are red, with NO texturing.

This is extremelly surprising. I'm using a very recent CVS built made few times ago only, and I'm currently almost up-to-date (I didn't made a built from the latest CVS version yet, since the changes were very minor). I'll make a new built in the following days, just to check, and also because I need to test some sprites models (and crash my whole computer again, but that's another story). I never saw those red models.

Can you post a screen capture of the red models ?

[rthorvald]

I haven't observed that myself . . . Did you get a debug version of the program? If that's not it, could you find a specific case that's slower in your version of Celestia than in pre1? A case where there's just a single model that's slower than before, ideally with nothing else visible.

What i got was ElChristous CVS version of Pre 2, compiled on the 27th of april. I will isolate a particular event/place in Ran, and upload a zip for you to test. In general, it is just slower all around.

i will always end up 336 KiloParsecs (!!) from the target. It works
the other way around, too: a Celurl saved with Pre 2 are 336 KPC away if opened with Pre 1

This is surprising . . . There's nothing I can think of that should cause such a huge discrepancy.

Well, in the zip i will send you the RAN stc file too, and a CelUrl. You can test.
Actually, this one is not a real problem, as long as it will be consistent between all platform versions in the future - but it is annoying for those that share CelUrls. Note that this is evident only in Ran - i remember we had a similar problem in 1.3.2, where CelUrls got displaced when one was that far away from the Solar System (1600 lightyears).

4
It is
either the clock, or it is related to the XYZ origin.

This sounds very much like the clock difference, though that change went in before the first prerelease. I'll check the commit logs and see if there was a later adjustment to the time. Do constant XYZ files always work? Or is there some other thing that the working XYZ files all have in common?

It seems to me that the discrepancy becomes more evident the shorter the timescale. For example, i tested with a spacecraft that leaves the ground and flies through a structure in orbit: in Pre 1 it matches where it will be at 1/1000 of a second... In Pre 2, it leaves the ground exactly where it should, but hits off the mark with several kilometers.

I am pretty sure it is the clock, but i will check to see if it can have anything to do with the origin, too: many of the files originates from LongLat spots instead of from the star: maybe LongLats are unstable between Pre 1 and Pre 2?

- rthorvald

PS: i??ll send you the zip later tonight.

[chris]

I am pretty sure it is the clock, but i will check to see if it can have anything to do with the origin, too: many of the files originates from LongLat spots instead of from the star: maybe LongLats are unstable between Pre 1 and Pre 2?

- rthorvald

PS: i??ll send you the zip later tonight.

LongLat could be the difference. Selden noticed that there were precision problems with LongLat and I checked in a fix a few months ago. What you're seeing could be caused by the upgrade from single to double precision. On the surface of a planet the discrepancy should only be a few meters, but projected out into space, there could be larger differences. If the trouble with XYZ files only occurs when the origin is a LongLat object, then I think that's the problem.

--Chris

[rthorvald]

If the trouble with XYZ files only occurs when the origin is a LongLat object, then I think that's the problem.

Ok, i will look into this. If this is the case, you are saying that i can safely work with Pre 2...?

EDIT:
I remember fixing those longlat problems when moving from 1.4 to 1.5 Pre 1... So, unless you have changed it again between Pre 1 and Pre 2, this isn??t the problem.

The other matter, about isolating a slow loading model: that has proven difficult. It looks like the _number_ of things to be drawn might be relevant. I tried isolating the biggest model i have (a 13 MB CMOD) together with a big virtual texture, and they work equally well on both apps. But if i turn on the entire scene (which has a lot of moons and spacecraft visible), Pre 2 is noticeably slower than Pre 1. It also loads slower.

- rthorvald

[rthorvald]

There is a test file that demonstrates the locations (XYZ) error here:
http://www.celestialmatters.org/cm/host ... n_test.zip (21 KB download).

In the zip, you will find a "mini" addon to drop in your addons folder. There is a text document with a CelUrl that in Pre 1 will show you a missile. In Pre 2, it is a thousand kilometers away.

The CELX file shows you the location, so you know the time and place if needed.

Important:
The CelUrl works in both Pre 1 and Pre 2. I have discovered that the problem with CelUrls aren??t the urls themselves, which works if one copy-paste them. The 336 kiloparsecs problem is a bug in the bookmarks: it seems the bookmarks get corrupted between pre 1 and 2.

Regarding the XYZ files, it does seem (so far) to have something to do with LongLats. But i DID fix this between 1.41 and 1.5 Pre 1: i remember we discussed it too, in the prerelease thread...

- rthorvald

[Cham]

Important:
The CelUrl works in both Pre 1 and Pre 2. I have discovered that the problem with CelUrls aren??t the urls themselves, which works if one copy-paste them. The 336 kiloparsecs problem is a bug in the bookmarks: it seems the bookmarks get corrupted between pre 1 and 2.

I frequently get something similar. Many of my bookmarks (favorite items) are getting "corrupted" in a weird way. It's like a kind of unpredictable offset. I never tried to isolate the cause yet, since I had too much things to do. It's becoming very irritating in the long run.

[rthorvald]

Update:
I just downloaded and tested with Dirkpitts build of may 7.

1.
The slow performance from the 27. april build i got from ElChristou is no longer evident: this one loads quickly and responds like it should. So, i guess there must have been something wrong with the april version.

2.
The bookmarks works, too, in this one! So, that bug is also confined to the older april version.

3.
The problem with red emissive models persists.

4.
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...

- rthorvald

[tech2000]

Can you post a screen capture of the red models ?

Cham,
here is your model of earth's interior with a quite red interior.

Bye, Anders

[chris]

Regarding the red emissive models: can someone who's seeing this send me their shaders.log? I checked in a fix yesterday that should have taken care of this problem.

--Chris

[Cham]

Can you post a screen capture of the red models ?

Cham,
here is your model of earth's interior with a quite red interior.

OUCH ! I confirm this ! I have exactly the same rendering with Dirkpitt's last build !!

What the h... !?

With my previous build,, I didn't had this problem. The modell was perfect !

This is clearly a new bug in the CVS build.

[chris]

It looks fine with Windows and a GeForce 8800 GTX. I need to see someone's shaders.log file so I can figure out what's going on. I thought that enabling strict GLSL conformance would prevent this sort of problem. DW: does your new build include the fix for emissive materials that I checked in yesterday?

--Chris

[tech2000]

Regarding the red emissive models: can someone who's seeing this send me their shaders.log? I checked in a fix yesterday that should have taken care of this problem.

--Chris

Here is my shaders.log

Bye, Anders

[chris]

Regarding the red emissive models: can someone who's seeing this send me their shaders.log? I checked in a fix yesterday that should have taken care of this problem.

--Chris

Here is my shaders.log

Bye, Anders

Thanks. The version of Celestia that you're using does not have my fix from yesterday--that will almost certainly fix the problem.

--Chris

[Cham]

Chris,

I just made a new build 5 min ago. It works. My Earth model is now working correctly. So Dirkpitt's build wasn't including your fix.