• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Problem with textures on segments (GMAX)

It is hard to make it perfect align. It is like pave with tiles. You can see the seam even those tiles were laid by skilled craftsman.
But by photoscenery, it is like you pave your airport with seamless carpet. I know that the resolution in close range is not as good as ground poly. But we often do tarmac, concrete etc. with ground poly method. Since the texture is seamless, so you cannot see the line in between each tile of texture.
 
bob5568 said:
EDIT: but notice your image doesn't have duplicated information in the first two pixels, thus you'll get the bad match you see.
Click to expand...

Okay, so here's a PDF with all the steps I did, with 10 images of what I was doing, and If you could take a look to see if I did something wrong, I'd appreciate it.
Thank you very much to both of you for trying to help me. If there's nothing I can do more, then I'll just do it with those lines. But it makes totally sence the fix you've showed me, I'm just frustrated that It's not working with me.
 

Attachments

No, I think you did wrong by enlarged it to be 1026 then shrink to 1024. It is just like nothing has been done at all.

Please read my tutorial here. http://www.fsdeveloper.com/wiki/ind...:_How_to_eliminate_lines_between_each_polygon

I mentiones clearly that you should make a new layer of your photo by CTRL-A to select the whole photo then CTRL-V to paste over the previous layer. Then use transform and shrink the new layer by using "Scale" to be 99.6 % to get the new layer 2 pixels smaller. The unwrap the polygon to fit this layer. You will get two pixels of the same picture around the new layer.
Please read and try it in Photoshop. It is step by step tutorial. Not difficult to do.
 
I disagree with you Tic, I think the op did it basically correctly, but I can't be absolutely sure as I need enlarged view of the uvw unwrap image, but it appears that the first two pixels are truelly duplicated in that image. HOWEVER, in your previous screenshot the first two pixels were NOT duplicated. So, check by zooming in that the first two pixels are identical in the finished 1024x1024 image, finally, check to make sure the dxt version of the image ALSO has the duplicated pixels.


Tic, I appreciate we are both trying to help this guy. You must not understand the difference between an increase in canvas size followed by copy/paste edge pixels, followed by resample back to original size if you say "nothing was done".. All your method does differently is substitute photoshops scale tool for its resample tool. (and you use layers....sheesh..we get to the same place, although my way may be better as in resample you can choose the algorithm to use.

If you wish I'll back away from trying to help, you can have the glory. :}}
 
I finally understood the concept of resample the image size. I had the same thought as Tic, that It didn't make any difference. It makes all the sence now.
Even though I didn't use to understad before I did all the steps correct. But I did everything again from start, new textures, and this is the result:
1.jpg
(in MCX)
So I thing it's very positive, it's almost not noticeable (the texture is very zoomed in).
Maybe I was not getting the results because of the textures, maybe I've done something to them before, I don't know, but now with the test I made from zero it seems very legit.

Thank you very much for your help ;) I'm a fast learner, but I was not getting this at all. But it's ok now. Thanks for your pacience.
 
bob5568 said:
I disagree with you Tic, I think the op did it basically correctly, but I can't be absolutely sure as I need enlarged view of the uvw unwrap image, but it appears that the first two pixels are truelly duplicated in that image. HOWEVER, in your previous screenshot the first two pixels were NOT duplicated. So, check by zooming in that the first two pixels are identical in the finished 1024x1024 image, finally, check to make sure the dxt version of the image ALSO has the duplicated pixels.


Tic, I appreciate we are both trying to help this guy. You must not understand the difference between an increase in canvas size followed by copy/paste edge pixels, followed by resample back to original size if you say "nothing was done".. All your method does differently is substitute photoshops scale tool for its resample tool. (and you use layers....sheesh..we get to the same place, although my way may be better as in resample you can choose the algorithm to use.

If you wish I'll back away from trying to help, you can have the glory. :}}
Click to expand...
I would like to know your way as well. If you can write the detail with photos to explain how you do that, I will appreciate that.
However my method is base on my understanding. Gmax/max has difficulty in mapping the very last pixels of the plan. It may caused by mipmap too. The way we can fool the program is making extra pixels beyond the real map. In my method I have original photo behind to make those extra pixels. The new layer will be the one that we have to unwrap to match. So, I have the plan mapping correctly to the 1022x1022 and I have extra 2 pixels beyond the 1022. That's works for me.
For my understanding, enlarging the picture o 1026 then shrink back to 1024, you will get the same picture. You map at 1022 on this, you will "exclude" the last two pixels out of mapping. So the photo cannot match between each tiles.
 
We share the same goal, for the same reason, and our two methods are different ways to acheive the same result. I read your method and it would surely work. I prefer to use resample, as I get the benefit of selecting the resample method, perhaps scaling achieves the same thing, in which case the methods are completely identical.

See attached images. Note that when I'm done the resultant original data is exactly captured in the middle 1022 x1022 px portion of the final image, with a duplicated set of pixels at the edge
I took the OP's image labelled "14". First image in the attached is that original, 1024x1024, all data in the pixels is original. Second image is a zoom that shows the upper right corner of the orignal image, with unique data in the edge row and column and the row/column 2nd in. The third image shows me using canvas size to make the image 1026x1026, note the original data is left unchanged and lives in the inner most 1024x1024 region of the image. The forth image shows that I've copied and pasted the 2nd row/column inboard and pasted it in the empty pixel region at the outermost row and column. Now I have a 1026x1026 image with duplicate first and second rows and first and second columns. Finally, I resample (image 5) which returns the image to 1024x1024 but now you see the duplication in data in the first and second row/column. Not at all the same as image one, now that you have the buffer needed to crutch gmax uvw mapping.


The only difference in your method is you use scaling of the 1024x1024 data and overlay it over a layer of orignal data.
 

Attachments

Ok, I got it bob. I think we got the same result.
Whatever method works for you, it is the best.
 
I tried both, but had no results because of the texture. I don't know but probably I screwed up some pixels and that didn't work, so I started from scratch and worked.
Since I think this is more and less the same topic:
Even now after getting the fix this still happens:
12.jpg
There is no fix for this, is there?
(only happens on distance, when getting close it starts fading)
 
what am I looking at? The terrain poking through the polygons? You should be flattening the terrain and I think most folks raise the ground tiles an unnoticable amount.
 
not that. the line between the polygons. where the red arrow is. it gets dark and noticeable from distance.
 
Did you enable mip-maps in your texture? I generally disable mip-maps for this kind of work. Try that.
 
I did not enable mip-maps. Just converted to .dds, the format is 32 bit. Did again with other textures and still happens.
Now, I feel like I'm beeing pretty unlucky. I'm sorry to keep asking you for help.

EDIT: You're refering to the "Create MipMaps" option in imagetool.exe right?
 
Last edited:
What else but mip mpas would change the appearance of ground poly textures with distance? (sort of throwing that up to the rest of the experienced devs)
 
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.
 
Last edited:
well, I've searched all over the internet ant didn't find anything about this.
And then, I noticed that actually all of the polygon edges look like having a "gap": some pics:
But only when distant:
2016-1-11_23-24-8-344.jpg
When close:
2016-1-11_23-24-24-702.jpg
Looks like their not touching each other.
 
You must log in or register to reply here.
Back
Top