Are planets supposed to look like that?

[pheonixstorm]

Like i said.. i would rather a bad planet than a bad ship and bases... And the issue only seems to affect atlantis. All the other planets have no issues

[pheonixstorm]

Emphasis mine.

Indeed, strook's work (as promising as it may be) was way too alpha to be hitting trunk... there's a lesson to be learnt there phoenixstorm.

Doesn't strook have his own branch now?

strook has a branch but no svn access

strooks work was not the actual problem. The problem that caused the planet issue was a diff by breese that was for a fix for several issues. The fix by breese DID fix an issue where anything above simple shaders showed the landing bay ship, serinity, and who knows what else to show as a white blob on the models instead of a nice textured, shaded 3D object. Check the images posted above this thread for what I mean by a nice white ship.

The issue with atlantis only seemed to affect atlantis and not any of the other planets in the starting system. So, it would appear to only affect planets that use the same techniques as atlantis. So the fix by breese actually fixed one bug but caused another.

The possible inclusion of planetary flight code by strook on the other hand might have had an impact of the LOD numbers. The code from sphere_generic.cpp/h had no impact either way on the planet bug.

In any case, with no control over svn by klauss, myself or even chuck (whenever he returns) it is up to ace to setup svn access and we all know how often he comes around.. not often enough. Reason why I hope he adds klauss as a project admin, or failing that then me. At least then we can make sure someone can more quickly tend to the needs of VS.

Hopefully klauss can find out why the changed code from mesh_xml fixed the ships but broke atlantis.

[breese]

So the fix by breese actually fixed one bug but caused another.

As all I did was to initialized uninitialized variables, I am convinced that I did not introduce a new bug. The white blob bug is more likely a latent bug that had been masked by the bug that I fixed.

I initialized all the variables to zero (or false) because is generally a sane default value. So I suggest that you start by investigating if these values should be set to something else. The code using point_state looks suspecious.

[breese]

I travelled back to Altantis and was able to reproduce the odd looking planets using r12984. I was able to fix with a single change (totally unrelated to my uninitialized fixes, btw):

Code: Select all

diff --git a/src/gfx/sphere.h b/src/gfx/sphere.h
index acc1105..d696372 100644
--- a/src/gfx/sphere.h
+++ b/src/gfx/sphere.h
@@ -83,7 +83,7 @@ public: SphereMesh() : Mesh()
                     theta_max,
                     mipmap,
                     reverse_normals,
-                    true,
+                    false,
                     planet );
     }
     void Draw( float lod, bool centered = false, const Matrix &m = identity_matrix );

I do not know if this is a correct fix, but it makes Atlantis whole again.

[klauss]

Vista/32, extreme/extreme: ships are again white on top in the dock, but planets appear correctly textured. Same for very high/nicest.

White on top? Do you have a screenshot of that? It sounds like it could be some lighting bug (not texturing).

Starting hangar 12984:
http://img406.imageshack.us/img406/1701/24062373.png

Starting hangar 12985:
http://img259.imageshack.us/img259/4638/90973918.png

I have seen the same a few months/couple dozen svn revisions ago.

That's a lighting issue, and I'm not sure it's a bug. I don't get that in linux. Can I have your savegame so I can try it at home?

Lights have a "size" parameter that has to be given to the shader, it looks like either the size is being computed incorrectly, not computed at all, or something like that. But if it looks fine outside of the base, it must be something with rendering ships inside bases, so I'll check that code path.

[klauss]

In any case, with no control over svn by klauss, myself or even chuck (whenever he returns) it is up to ace to setup svn access and we all know how often he comes around.. not often enough. Reason why I hope he adds klauss as a project admin, or failing that then me. At least then we can make sure someone can more quickly tend to the needs of VS.

I might have access.

At least I know I have admin access to the bug tracker, that might mean I have admin access over other areas - just nobody told me, I found out by mere chance

Hopefully klauss can find out why the changed code from mesh_xml fixed the ships but broke atlantis.

Ya, I'll try, but I have to be able to reproduce the bug at home first. I don't see white ships. And when I do, it's not a bug, it's a lighting "feature" that happens when models are very very very close to the sun - on those cases, it's on purpose.

But maybe it's broken somehow and happens when it isn't supposed to happen...

As all I did was to initialized uninitialized variables, I am convinced that I did not introduce a new bug. The white blob bug is more likely a latent bug that had been masked by the bug that I fixed.

I initialized all the variables to zero (or false) because is generally a sane default value. So I suggest that you start by investigating if these values should be set to something else. The code using point_state looks suspecious.

AFAIK, those variables were initialized and the diff showed the patch removed the initialization.

Look at the diff

[klauss]

I travelled back to Altantis and was able to reproduce the odd looking planets using r12984. I was able to fix with a single change (totally unrelated to my uninitialized fixes, btw):

Code: Select all

diff --git a/src/gfx/sphere.h b/src/gfx/sphere.h
index acc1105..d696372 100644
--- a/src/gfx/sphere.h
+++ b/src/gfx/sphere.h
@@ -83,7 +83,7 @@ public: SphereMesh() : Mesh()
                     theta_max,
                     mipmap,
                     reverse_normals,
-                    true,
+                    false,
                     planet );
     }
     void Draw( float lod, bool centered = false, const Matrix &m = identity_matrix );

I do not know if this is a correct fix, but it makes Atlantis whole again.

I believe you're skipping strook's random perturbation of the sphere's surface with that, but sphere_generic.cpp still has disabled LOD generation. So reverting the changes made to sphere code is still probably best, until strook's work is final.

Now, how strook's code slipped into that patch I don't know. That's probably a result of having per-developer branches - that's why I always preach in favour of per-task branches, so patches don't get mixed up.

[shenle]

That's a lighting issue, and I'm not sure it's a bug. I don't get that in linux. Can I have your savegame so I can try it at home?

Lights have a "size" parameter that has to be given to the shader, it looks like either the size is being computed incorrectly, not computed at all, or something like that. But if it looks fine outside of the base, it must be something with rendering ships inside bases, so I'll check that code path.

That's no savegame, it's the first thing I see when I start a new campaign. If you want I can save it, but I don't see the point. In Windows it's perfectly repeatable, it happens every time you start a game.

(edit) here's a savegame. I started a new campaign in a rev.12985 binary, it shows the white ship. Saved it right away. When loaded in a binary of the previous version (12984) it does not show the white artifact.

[pheonixstorm]

Known about white ship bug.... (see pics below)
1. Happens on simplest shader or higher. Simple shader or lower has no problem.
2. Only affects windows
3. Affects ships and bases (maybe planets)
4. Save game not a factor, happens on a save load or new game.
5. Looked fixed by mesh_xml changes post merge (broke atlantis though or just made the bug more apparent).

r12987 commit does not fix the above.

Lonely llama in space

Poor serenity has lost its color

Oh how awful, the color monster stricks again!


And yes, by all accounts this does appear to be a lighting issue.. but what I don't get is why the fixes by breese corrects the white blob problem on the ships when it appears to me that the fix provided doesn't really change how the code works. Look at...
From mesh_xml.h

Code: Select all

    MeshXML()
        : sharevert(false),
          usenormals(false),
          usetangents(false),
          reverse(false),
          force_texture(false),
          load_stage(0),
          point_state(0),
          vertex_state(0),
          recalc_norm(false),
          num_vertices(0),
          tstrcnt(0),
          tfancnt(0),
          qstrcnt(0),
          lstrcnt(0),
          faction(0),
          mesh(0)
    {
    }

I think until I find a show stopper or you can find the real issue klauss I will let that section stay as a linux/windows split. Use the code by breese for windows and leave it alone for linux. The white ship bug is a real game killer atm.

One last thing I noticed... in all three of the pics do you have any idea what the green polies (best word I can find to descibe it) are?

[pheonixstorm]

Using only the code changes from mesh_xml.cpp/h I have no issues with planets or ships/bases. klauss use you magic wand and find a fix please!

In case I didnt mention it before, the change to gl_light_state did not change anything one way or the other.

[shenle]

r12987 commit does not fix the above.

I can confirm that.

[klauss]

I guess I'll look harder at mesh_xml stuff...

[breese]

AFAIK, those variables were initialized and the diff showed the patch removed the initialization.

Look at the diff

No, the initialization of those variables were moved to the constructor (in mesh_xml.h) and there I also initialized the remaining PODs that were not initialized before.

[shenle]

12988 for me fixes both the ship bug and the planet bug.

[pheonixstorm]

I did a clean compile and r12988 still has the same problems for me. Check the mesh_xml.cpp/h and make sure there is nothing there from the code I posted earlier.

*EDIT*
Nevermind... didn't update my dev trunk just primary... Works for me. Now that this is solved I am going to work on getting that new memory diff in and test/update trunk provide all goes well.

[klauss]

12988 for me fixes both the ship bug and the planet bug.

Yey!!!

Now, I know why not initializing variables in the constructor brought some trouble, if you take a look at mesh_bxm.cpp, it does create a few MeshXML instances without proper initialization.

What I do not know is why that affected planets, since they use an entirely different code path.

But... the issue is in the past already, and I'll be glad to leave it there for the time being

[breese]

What I do not know is why that affected planets, since they use an entirely different code path.

Quite simple: it did not affect the planets. That problem was caused by the changes to sphere.h.

[pheonixstorm]

The planet problem is still around though on the opposite end. If you look at the lighting of planets they look too white to me. That or the shader needs to tone down the lighting a litte. It just doesn't look right being so bright especially when there is a large amount of cloud cover.

[klauss]

Screenshot?

I've experienced similar lighting oddities at extreme shader settings without a GPU capable of sRGB (which tones down lighting by using gamma-correct blending).

I'm not sure how to fix it, since it's the user setting a shader setting he shouldn't use

sRGB-capable GPUs start with the GeForce 9 line or so.

[shenle]

I think he refers to, for instance, the planet picture from his post above. It's correctly textured, but the albedo is... well, a bit excessive. I was going to comment on than next. Planets overall look much better in Linux.

...the shader needs to tone down the lighting a litte. It just doesn't look right being so bright especially when there is a large amount of cloud cover.

I agree with the first statement, but cloud cover will raise a planet's albedo. It's too high though.

Here is an example (real life). The top picture is Earth's albedo without any clouds. The bottom one is with average cloud cover.
http://upload.wikimedia.org/wikipedia/c ... albedo.png

[klauss]

I think he refers to, for instance, the planet picture from his post above. It's correctly textured, but the albedo is... well, a bit excessive. I was going to comment on than next. Planets overall look much better in Linux.

They shouldn't look any different in linux.

Atlantis looks overi lluminated mostly because it's illuminated by two stars. Two day zones. When both day zones meet, lighting is very bright.

I've consciously an purposedly made cloud lighting saturate. They're very very bright in real life, seen from above. Anyone been on a plane lately? Remember how bright it was above the clouds?

We're used to seeing the clouds from below, not above. From above, they're bright as the sun.

Here is an example (real life). The top picture is Earth's albedo without any clouds. The bottom one is with average cloud cover.
http://upload.wikimedia.org/wikipedia/c ... albedo.png

That example is meaningless, it all depnds on camera calibration. I've compared the looks of the planets (as in the screenshot above) with shots from the ISS (when people is part of the frame, so as to have a proper reference point), and it matches quite precisely.

If artistic reasons call for modding down lighting, it's rather trivial, but in all my tests, brightness is best. HDR, whenever it might be implemented, will allow for a better experience regarding lighting.

[shenle]

Well okay then, I understand the 2 stars argument. However, they do look different in Linux. Atlantis looks almost as the Earth. If the brightness I see in Windows is what it's supposed to look like, then in Linux it's almost as if someone shoved neutral filters in front of both suns.

[strook]

hi

i think this should be my error

there seem some early planetflight test routines going.

the fix:
1.: download newest svn, klauss deleted some planetflight routines of it.
2.:there is a parameter when generating planets, i think it is the last one, named planet.
just set it to false in planet.cpp in the if section !wormhole
(sorry i'm not at my computer yet.)


in fact, you can delete the whole planetflight section, if you go to the file where a sphere is created (sphere_generic or so..) there is much not complete code (i wonder if it is committed...)

i can send you a patch, i can rearrange it.

[pheonixstorm]

this was already fixed