[Herra Tohtori]

In a nutshell, me and Zacam managed to figure out why some planets look elliptically distorted despite all the valiant efforts to fix aspect ratio related problems. The problem become quite obvious after making a special test texture, which can be found here should you be interested.

Since images tell more than words, without further ado here be a pair of them:






Description: The first image uses values DivX: 2 and DivY:2, while ScaleX and ScaleY are 4.000000 on both images. Field view is likewise default on both shots.

The lower image, quite obviously, uses DivX: 1 and DivY: 1 and looks remarkably much better than with the divisions into multiple parts.


With this empirical data it can be concluded that the division algorithm is rather borked and even more importantly it's fundamentally useless considering the options offered by FS2_Open. It can also be hypothesized that the same applies to nebula textures, but since they don't have even as much geometric shapes as planets do, they most likely have just passed unnoticed like forever and it hardly matters, but it's probably "good-to-know" information for background designers that some distortion will be caused by the division mechanism.

As far as I know, the reason for the divisions on planets was originally to make really big planets "less" distorted in a sense, but obviously it does not work out so well, and we've been having the skyboxes for that purpose for a long time. Conclusively, FSUpgrade is changing all planet backgrounds to use DivX: 1 and DivY: 1 (no divisions) and suggests other background designers to take this phenomenon into account when positioning planets to background (I would personally even go as far as suggesting everyone to use DivX/Y: 1 and if the planet is big enough to look dumb that way, use a skybox instead).

Since this likely affects all missions and campaigns with planets in them, this topic is here rather than FSU forum, because the relevant people are found here.


Thank you for your time.

[Vrets]

This explains a lot, thanks.

I've always been befuddled by the divx/divy boxes, anyways.

[FreeSpaceFreak]

I never used divisions anyway

[n00b]Woo! 1000th post! Yay! [/n00b]

[Rodo]

Noticed this on several ocations, that's why I never use more than x5 or x6 at maxium and with no divisions.

So we are sticking to skyboxes for close and detailed views of planets right?

[Maverick]

For me i somewhat have this problem as well but its a big green box surrounding the planet... happened a few times at the end of the FS1 port around earth and a few others...

[FUBAR-BDHR]

That's an entirely different problem.  The green around a planet is because the wrong color background was used for transparency or the file was saved incorrectly.   

[Mobius]

My choices in terms of X-Y divisions are good, then. I have never liked divisions.

So we are sticking to skyboxes for close and detailed views of planets right?

I don't think it's the case, really. Planet textures in skyboxes have immobile and fixed positions, which aren't flexible at all. They screw up the whole concept of getting close to a planet and/or showing different persprectives of it.

Unless you have multiple skyboxes, which isn't recommendable when you can simply use a bitmap and scale it according to your requirements.

[Maverick]

Is there any way to fix it because even though its not a problem, its a bit of a nuisance when i see it happen

[Mobius]

Are you refering to the same problem you mentioned above? If so, it's the bitmap itself that needs to be edited...coding has nothing to do with it.

Assuming that pure green parts should be transparent, I'm afraid that the parts you can see aren't made of pure green. The RGB values should be 0, 255, 0 and I guess that even 0, 254, 0 would screw up the transparency.

[Zacam]

The green grid was created to represent a planet to evidence the amount of distortion. It is an intentional graphic, not the bug. The bug is the distortion.
The distortion issue resolution is simple: Don't use DivY or DivX values greater than 1 whenever possible.

Planets having a normal looking appearance, but green wedges at the corners would require an image manipulation of the file in question to resolve.

Hopefully, this covers both potential possible questions present. Or else I am exercising my jaw on shoe leather again. :-)

[karajorma]

Are you refering to the same problem you mentioned above? If so, it's the bitmap itself that needs to be edited...coding has nothing to do with it.

Bollocks. That's quite obviously a code bug.

[Herra Tohtori]

Eeh

For me i somewhat have this problem as well but its a big green box surrounding the planet... happened a few times at the end of the FS1 port around earth and a few others...

Is there any way to fix it because even though its not a problem, its a bit of a nuisance when i see it happen

Are you refering to the same problem you mentioned above? If so, it's the bitmap itself that needs to be edited...coding has nothing to do with it.

The division splitting-algorithm causes a distortion, which is a code problem but avoidable by not using the divisions.

Having a green box surrounding the planet is with very high probability a media error, first and foremost comes mind that someone saved a retail PCX file with green transparency edges directly to TGA or DDS without editing it, enter green box. And that has nothing to do with the coding but how you set up transparency on the planet texture itself. Or like Mobius suggested, it could be that the colour is not #00ff00 [0,255,0] pure green after indexing is complete.

Unless the code is no longer compatible with PCX planets that use green for transparency, I don't see how it could be anything but a media error.

[ARSPR]

Hey, I don't know much about perspective math but I think that even looking worse IT'S NOT A BUG, BUT EXACT MATH.

I suppose the "div=2" just makes the game drawing 2 x 2 = 4 bitmaps instead of just one. And, as you are looking them at sligthly different angles the drawn planet is somehow distorted. But that's PURELLY fine in a strictly math sense.

Just think about fish-eye lenses in photography. There's simply no way to make an ultra wide angle shot without distortion. Moreover, normal lenses DO correct the naturally generated distortion because, with small FOVs, we usually prefer the straight looking version. In this way when we watch photos, we are fully used to watch distortion-fixed ones which need "special" lenses (although all lenses try to be "special" enough ). A spherical background must be distorted if seen on a flat background, unless artificially fixed somehow, which is only possible for small FOVs.

So I think it's just a balance between mathematically correct, good looking and personal preferences (as example I don't specially mind distorted planets because it gives me a further 3D feeling). Maybe, as a general rule, only HUGE planets will look better with some amount set on division while the rest of planets won't. But in a strict sense, the further from the center any background bitmat part is the wider its distortion should be, (that's what is shown in the "div = 2" screenshot).

----- Edited -----

How do you UV map that BIG flat circle/rectangle over the spherical background pof without distorting it?

I suppose that if the pof has enough number vertex, you will get a really similar looking with the background pof or with a big number of DivX and DivY. Divisions is emulating this effect of laying a flat bitmap over a curved background.

[Zacam]

Well, there are no spherical POFs for planets, just images that hang out in space.

So, there should be no spacial distortion trying to fit an image to a shape, because there is no shape that it is being applied to.

Though, that would be cool as all hell to make 3D planets with rotation. Pure killer to map and would probably bring most systems to their knees in addition to everything else.

[Herra Tohtori]

I suppose that if the pof has enough number vertex, you will get a really similar looking with the background pof or with a big number of DivX and DivY. Divisions is emulating this effect of laying a flat bitmap over a curved background.

Yes, but consider that the planet bitmap is already a render, which means that it's perfectly fine to display that as a flat image. The correction is in the image already.

Consider that skyboxes used to be actual cubes with flat faces, but the renders were made so that it looked seamless. Cubemaps used in environmental mapping still are just like this.

That said, it would obviously be awesome to have realistically sized planets, ideally with something like 8192x4096 map when looked at from a distance and then details done by procedural terrain generation like in Infinity, but to begin with it would require the rendering distance problems to be fixed (realistically sized planets would be so far that they start flickering) and other stuff would need to be added in as well... like a good atmospheric effect. The Cardinal Spear explores with mapped planets, and those are the main problems I came across while making them; they need to be way too small to work in the game, they are too blurry when you fly close to them, and they don't look as good as renders due to lack of atmospheric effect.

Renders of planets are indeed much cheaper solution and as long as they are really just the background imagery they work perfectly fine, and without any divisions.

[ARSPR]

Well, there are no spherical POFs for planets, just images that hang out in space.

So, there should be no spacial distortion trying to fit an image to a shape, because there is no shape that it is being applied to.

Though, that would be cool as all hell to make 3D planets with rotation. Pure killer to map and would probably bring most systems to their knees in addition to everything else.

Yes, but consider that the planet bitmap is already a render, which means that it's perfectly fine to display that as a flat image. The correction is in the image already.

Consider that skyboxes used to be actual cubes with flat faces, but the renders were made so that it looked seamless. Cubemaps used in environmental mapping still are just like this.

Sorry, I haven't explained myself.

By spherical pof I mean the BACKGROUND model. I know we don't have available planet pof models (yet... !, any coder as volunteer for solving this?  ). In this way if you UV map without artificial tricks a flat square/circle over this hypothetical sphere, you'd more or less get the "division" distortion looking. And maybe this distortion could look fine with extremely big bitmaps.

Nevertheless Herra says that the background pofs are cubes not spheres... (strange..., a background cube could have strange looking at corners, or edges between faces, if their maps are not previously pre-distorted).

With my previous post I just wanted to point that POSSIBLY (I'm no math expert):

• There's no bug in the "division" code. It just doesn't fit for planet usage. But it's probably perfect for HUGE bitmaps like nebulas which expand over your full FOV.
• Take this consideration in mind BEFORE any of you, (I mean any of the coders), start looking in the code for something to fix.
• If most people agree on Div=1 looking better than Div=2, go ahead and tweak all the missions (it's just a cosmetic look).

[Herra Tohtori]

Sorry, I haven't explained myself.

By spherical pof I mean the BACKGROUND model. I know we don't have available planet pof models (yet... !, any coder as volunteer for solving this?  ). In this way if you UV map without artificial tricks a flat square/circle over this hypothetical sphere, you'd more or less get the "division" distortion looking. And maybe this distortion could look fine with extremely big bitmaps.

Yeah, perceived visual reality in space is a sphere that has stuff on it's insides. However, that doesn't mean you have to press every background element to follow the curvature of the perceived inner shell of the sphere.

A planet render plastered onto a plane hanging on the space will look just as real as plastering the texture onto the inside of a sphere, since the render is already a planar projection of a what you would see from the viewpoint and therefore the planet should blend into the background just fine without any "bending" to make it appear like it follows the spherical background.

Of course the perceived distance from the planet in relation to it's apparent diameter needs to be taken into account in the rendering phase, but that's a different matter.

Nevertheless Herra says that the background pofs are cubes not spheres... (strange..., a background cube could have strange looking at corners, or edges between faces, if their maps are not previously pre-distorted).

No, I'm saying that they're called skyboxes because the original term skybox refers to a cube model that has six renders (front, back, left, right, up and down) to cover all the insides of the cube. Cubemaps used in envmapping are volume maps that have six layers, and the envmapping system basically utilizes them identical to a skybox in the literal sense of the word.

The actual skybox models used in FS2Open do tend to be spherical for the obvious reason that it's easier to tile a starfield onto a spherical model, it makes the distortion issues much easier to deal with.

With my previous post I just wanted to point that POSSIBLY (I'm no math expert):

• There's no bug in the "division" code. It just doesn't fit for planet usage. But it's probably perfect for HUGE bitmaps like nebulas which expand over your full FOV.
• Take this consideration in mind BEFORE any of you, (I mean any of the coders), start looking in the code for something to fix.
• If most people agree on Div=1 looking better than Div=2, go ahead and tweak all the missions (it's just a cosmetic look).

I'm inclined to agree that the division code itself works probably just like it's intended, but as the practical demonstration quite clearly shows, it has problems that not only cause distortions into the image texture itself (misaligned lines in my example) but also distort the aspect ratio of the whole planet, which doesn't work well at all. At it's intended use - truly big planets - it would probably work somewhat better.

And like I mentioned, the original reason for utilizing the division thingy has greatly diminished due to the advent of more advanced skyboxes that make it possible to use planets with much greater apparent diameter.