Problem with textures on segments (GMAX)

[jtanabodee]

has to be mip maps are present in the textures, unless someone can think of anything else.

To my opinion I think it is a MUST. Mip map is LODs in term of texture of SCENERY. It makes the performance better.
It is the different story if you do AIRLINE LIVERY. The mip map is not recommended for the crisp and clear texture of the aircraft.
You problem is caused by the flatten of the airport.
You need to make flatten to a certain height for all over the area.
You can do that in ADE. But I have that problem too. Sometimes flatten seem to have problem.
http://www.fsdeveloper.com/forum/threads/change-airport-altitude-problem.436044/page-2#post-732054

 

[HugoPiugo]

I did flatten the airport area. And after reading your post I added the Exclude too. But, it becomes a mess:
There was one of those weird lines where this gap between the polygon is. It seems they got separated

 

[jtanabodee]

I think you might try using other height. You need to use TcalX to explore the height of the whole area and choose one of the height (usually the highest one) and flatten with that number.

 

[HugoPiugo]

I cant get TcalcX to work on my pc, it's not dotNET, not simconnect, nothing works. It seems like I was covered by a wave of bad luck.
I'll try and move everything to my other computer and see If it works. I'll say something later.
Meanwhile:
I did try again the mip map thing:
With MipMaps:

Wihtout:

It doesn't change any of the lines that appear.

 

[HugoPiugo]

Just used Tcalcx and the alt changes from 7.3150005..... to 7.3150002, so I can't change it on model converter because in only accepts 7.3150.

 

[HugoPiugo]

So I have some news about the lines. I read somewhere that in order to have the perfect UVWunrap you need to inboard 12 pixels each side! Don't ask me where I read it, maybe I understood it wrong, but I tried it, and it actually works! Gives me a lot of work, because I have to copy and paste 12 lines of pixels (don't know if there's a easiest way to do it) at each side... Then inboard those 12 pixels at gmax (each side), and here's the result:

You can check the difference in the images I uploaded before, the line was ridiculous, and now it's not noticeable.
Don't know why, the only think that passes trough my head is that with some distance, somehow fsx makes appear the border of the texture, and in this case, we have enough pixels to disguise the border. I don't know, this is a explanation from a guy that doesn't understand nothing about this...
I tried it with 8 pixels, and with 5, and none of those gets better than the 12 pixels.

The process of getting each texture with 12 pixels each side and then Resample back to 1024 is kind of boring, but at least it works...

EDIT: Look at the difference, how it was before:

 

[bob5568]

interesting!

 

[jtanabodee]

Regarding the line between each tile, I have made a tutorial for this problem. It might be easier than copying the pixel of photo.
http://www.fsdeveloper.com/wiki/ind...:_How_to_eliminate_lines_between_each_polygon

 

[HugoPiugo]

yes, that line was fixed. The problem was that when I moved away, in the distance it got pretty visible, but when I'm close, it's completly ok. So I used more and less your way to fix it, but instead of 1 pixel each side I had to make it 12 so that the line disapears in the distance. In this topic: http://www.fsdeveloper.com/forum/threads/imagery-white-lines.434505/ they say that 8px is more than enough. And I think that this is where I took the idea. Tried with 8 and it got much better, and then with 12 even better.
Some examples I just did right now:
Difference between:
3 pixels/6 pixels (each side):

Now between 8 and 12:

 

[GaryGB]

Hello:

MCX development version now can include MIPMAPS in converted textures via the Material Editor.


...Or one can use FS SDK ImageTool to create MIPMAPs:

http://www.fsdeveloper.com/forum/threads/converting-textures-to-mip-maps.6637/

http://www.fsdeveloper.com/forum/th...g-split-to-different-heights-with-mcx.427856/


Hope this helps !

GaryGB

Hi GaryGB,
My MCX includes MipMaps when converted there. I've tried both, tried converting in MCX and Imagetool (not using MipMaps) and both got the same result.

My problem is only the line that appears in the distance, not the flatten ground, that I'm aware of.

FYI: Some related additional ideas previously explored on this topic:

http://www.fsdeveloper.com/forum/th...s-follow-a-size-guideline.431618/#post-689024

http://www.fsdeveloper.com/forum/threads/imagery-white-lines.434505/

http://www.fsdeveloper.com/forum/threads/fsx-groundpoly-with-sp2-flytampa-did-it.9727/page-2


Have you tried creating ex: 9 MIPMAPS per terrain texture image file (rather than using a FS2004 SDK default of just 7) ?


...Note that in the first thread linked immediately above, ImageTool accepts a command line switch 'string' to create MIPMAPs:

-mip ...Generate mip maps [DEFAULT]

Mip: %s


In the above ImageTool example, "-MIP" is the command line switch 'Parameter', and "%s" is the 'string' to be substituted by a integer value (ex: 7 -or- 9) ...applied to the Parameter


Perhaps one may also consider testing other ImageTool parameters to change output for "texture clamping" ex:

-fold ...Fold the Edge colors for clamped textures

https://msdn.microsoft.com/en-us/library/windows/desktop/bb204825(v=vs.85).aspx

https://msdn.microsoft.com/en-us/library/windows/desktop/bb206239(v=vs.85).aspx

https://www.opengl.org/archives/resources/code/samples/sig99/advanced99/notes/node64.html

http://www.cs.uregina.ca/Links/class-info/315/WWW/Lab5/index_gl3.html#Repeat

http://stackoverflow.com/questions/19611745/opengl-black-lines-in-between-tiles/31485701

https://www.google.com/#q=-fold+Fold+the+Edge+colors+for+clamped+textures



Alternatively, one may use Martin Wright's DXTBmp to create MIPMAPs:

"The nVidia codec offers an option to Dither images during the save process. Depending on the image and the save format this may give better visual results.


Use the MipMaps "Use 16 bit Dither" option to switch this feature on or off. Check the results before saving by Previewing the saved image.


The codec also now includes options to adjust the way mipmaps are generated. Options are available in the MipMaps section to change the type of scaling method used and also to apply specific processing functions to each mipmap. Experimentation may be required to find the best combination for your needs."

http://www.mwgfx.co.uk/programs/dxtbmp.htm

CAVEAT:

"martin
Apr 19, 2011 - 9:05AM

Re: DDS DXT3 texture saved by DXTbmp looks blurry in CFS3

I have a sneaking feeling that imagetool does something special with the mipmaps that is optimised for FS/CFS.

DXTBmp uses the nVidia DDS library to output textures. The Photoshop plugin uses the same libraries and I wouldn`t be surprised if the other programs also use code based on the nVidia library. I would expect all these methods to create very similar results

I remember using the commandline options in imagetool and there is a flag you can set to specify that the output is to be used for terrain. My guess is that it sets something in the file that tells FS/CFS to switch mipmaps at a greater distance than normal so making it look slightly sharper for longer. Its not that the image data is any better just that it holds on to the higher mipmaps for longer. In the same way that aircraft can be made to look sharper by removing the mipmaps (so forcing the use of the full image at all distances) delaying the switch to the next mipmap will extend the distance before terrain switches to a smaller (blurrier) mipmap.
On the other hand it is possible that the mipmap scaling algorithm used by imagetool is different to nVidia and creates mipmaps that are particularly optimised for terrain. The nVidia code is not FS-Specific as most games these days use DDS. There are options available in the plugin (and DXTBmp) to use different scaling algorithms and it may be worth experimenting with these to see if they make any difference in this situation.

Or just use imagetool (for the final output at least)"

http://pub9.bravenet.com/forum/static/show.php?usernum=743074977&frmid=74&msgid=754470&cmd=show



Thus, one might wonder whether there may be ongoing issues of precision in Ground Polygon creation, texture mapping and run time rendering by FS related to this anomaly of "seams" or "lines" in ones output via MCX and other 'legacy G-Poly' utilities.


I found the "Texture Filtering" section of this article on RenderMan intriguing as to how such "seams" arise and may be dealt with:

http://renderman.pixar.com/view/what-the-rispec-never-told-you

"Discontinuity in texture coordinates can also be a cause of seams. This frequently happens when using cylindrical and spherical projections. One of the texture coordinates jumps all the way from 1.0 back down to zero across a single micropolygon. This confuses the texture() function into filtering across the entire width of the image, so you get a single abberant row of micropolygons with the average color of the entire texture."



The FS SDK calculates terrain vertices in the QMID grid with no less than double precision (...for apparently 'good' reasons) according to ACES' Adam Szofran in his "Global Terrain" document:

"After triangulation, the mesh vertices must be transformed to account for the Earth's curvature."

"The conversion from latitude, longitude, and altitude above sea-level to geocentric Cartesian coordinates is relatively straightforward using equation 4-14 from the WGS 84 specification:


Where:
a = 6378137.0 meters (Earth's equatorial radius)
b = 6356752.3142 meters (Earth's polar radius)
e = 8.1819190842622 x 10-2 (ellipsoid eccentricity)


The equations must be evaluated using 64-bit floating point to prevent a loss of precision. The seven significant digits of 32-bit floats aren't enough to represent a point with better than sub meter accuracy. Since the rendering pipeline (Direct3D in this case) uses 32-bit floats, the final coordinates used for rendering must be converted to 32-bit offsets from a 64-bit local origin no more than several thousand meters away (see Figure 7). It would be simpler if each cell had its own local origin and world-to-camera matrix, but then small cracks would be visible between cells due to floating-point imprecision. Therefore, all the cells must share the same local origin and matrix."

http://download.microsoft.com/downl...obal Terrain Technology for Microsoft ESP.pdf

http://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx


See also: Pages 41-43 of 207 in...

http://earth-info.nga.mil/GandG/publications/NGA_STND_0036_1_0_0_WGS84/NGA.STND.0036_1.0.0_WGS84.pdf

...and:

https://en.wikipedia.org/wiki/Double-precision_floating-point_format

https://en.wikipedia.org/wiki/Floating_point

https://en.wikipedia.org/wiki/Significant_figures#Rounding_and_decimal_places


This is why I previously suggested:

"SCASM source coding with Ground Polygons to create them as "Area Points" (aka "mini-quads") and place them with their RefPoints relative to a NW corner of the known and calculable terrain QMID grid vertices for local terrain quads (which IIUC, is done via the SDK SHP2VEC compiler when working with custom vector terrain land class polygons)."

http://www.fsdeveloper.com/forum/threads/getting-coordinates-from-existing-bgl.435585/#post-726746

GaryGB

 

[HugoPiugo]

Thank you very much for your help GaryGB. I didn't have time to check and try all the advises in your post, but I will.
For now, the fix I found was exactly inboard a good number of pixels each side when mapping. I found that the more pixels inboard the least the line appears.

It was at the topic "Imagery white lines" that I got the idea to try inboard more pixels than just 1 or 2.
About the mipmaps, when I create them with Imagetool I think it creates 11. At least, at the side it says: MipLevels: 11
I'll take a deeper look into it, just thought I should say something since you've put so much work on trying to help. I'll post something when I take the look.

 

[GaryGB]

Hi again, and thanks for following up; we all may benefit from learning more about how you have solved such a scenario with 'currently available' SDK and 3rd party utilities.

GaryGB

 

[jtanabodee]

For now, the fix I found was exactly inboard a good number of pixels each side when mapping. I found that the more pixels inboard the least the line appears.

It was at the topic "Imagery white lines" that I got the idea to try inboard more pixels than just 1 or 2.

That is a very good point. In my tutorial, I put some calculation example that you can use for any number of pixels you want to. Then use the number of percentage to transform the satellite image to fit in.
For example if you want 5 pixels for each edge, your satellite image that you need to shrink down is 1024-10=1014 that is 1014/1024 =0.99. Then you use Scale transform to be 0.99 of the original photo. I think this is the easiest way for me.

 

[astaticmusic]

not trying to hijack the thread but......I just posted a topic similar to what is discussed here, do you guys think this will this stop the polygons created in gmax from expanding when put in the sim? I didn't have any issues with lines between the polys, its all about gmax model is a different size that the Photoshop one.

BTW... Hugo was watching the same tutorials that I have been studying.

 

[HugoPiugo]

astaticmusic, I answered in your thread