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

ADE gp 0.0.91

Messages
5,214
Hi all,

Digging further into the mud of gp poly peculiarities, I tried to remedy the errors that were found in the LFST file that was uploaded earlier on and I found the following:
- when ground poly overlap somewhere they give rise to errors (it has nothing to do with their complexity);
- remedying the overlap solved the problem but left a gap between them;
- I substituted the unknown texture bmp's with my own;
- As there were several ground polys I had to do that a couple of times;
- I noticed that the texture size was different and off every time, so that I had to drag and resize;
- there was no way to know how to resize the groundpolys so that the textures of the various polys in FSX would be of the same size.
What IMHO is faulty or lacking is the fact that:
- there is no consistent original texture size showing;
- there is no way to know if the texture was sized before and to what extent;
- the fact that overlapping ground polys cause errors reduces their use to make complex ground polys or join several of them without having gaps in between.
I have not yet checked if, when giving the various ground poly different layers, it would make a difference.
What is your experience?
 
But it does not adress the issues I mentioned, right?
I will post some pictures of the problem after dinner if you do not mind (that is, if you need them to understand what I am trying to say?)?:)
 
Will do, Don (but as I said after dinner:)).

Roby

PS That will give you time to have lunch as well:D!
 
when ground poly overlap somewhere they give rise to errors (it has nothing to do with their complexity);
I'll have to see your pictures to comment. There should be no such effect. GP objects are triangulated individually.

I noticed that the texture size was different and off every time, so that I had to drag and resize;
Dragging has no effect on texture size as applied.

- there was no way to know how to resize the groundpolys so that the textures of the various polys in FSX would be of the same size.
Once you resize a poly you are on your own. If you want the texture application consistent, why are you resizing the poly? That's what makes it inconsistent.

there is no consistent original texture size showing;
The texture size shown is as applied.

- there is no way to know if the texture was sized before and to what extent;
Why do you care what it was before?

As far as I am concerned, the texture size display is virtually useless for anything but general information. It's something I added in the beginning because I thought it might be useful. Now, it would be a lot of work to remove. You can get the same information by comparing the displayed size of the texture with the window dimensions. You seem to attribute so specific value to it. What is that?

I have not yet checked if, when giving the various ground poly different layers, it would make a difference.
Overlapping polys at the same layer will flicker. Layering should have no effect on the issue you seem to be describing since GP objects are triangulated individually.

Don
 
Morning Don,

My texture and line definitions were erased once more:confused::mad:.
Will have to give them in again and see if that solves the problems of the ground poly.
 
Hi,

All evoked problems were (once again:rolleyes:) due to line and texture def entries missing once more:mad:.
Sorry.
 
line and texture def entries missing once more
I'm not clear about what you are telling me. Are you saying that your line style and texture assignments have mysteriously disappeared from the objects to which they were assigned?

Don
 
I think he means he somehow reverted to the default Texture and Lines Def files, or at least those relevant entries are missing?
 
Yes, that is what I mean (thanks again, Tom). All my def entries were gone once more without me noticing it. Stupid, I know, but nevertheless true.
I had not backed up my def entries thinking they would now be save from overwriting as you have texture base files as well. No such luck though.
And I never realized the warning (no def) was also for ground polys. Thought it was only for lines.
 
Roby, as I've said before, the GP editor doesn't overwrite the Texture_Def and Lines_Def files. Are you doing something unusual with the GP Texture Editor?

The only other way I can envisage this happening is of your Texture_Def and Lines_Def are missing when the GP editor starts up, in which case it is assumed this is a new installation and they are created as a copy of the respective _Base files.

Just had a thought. I wonder if this is a language issue. Are those two files actually named "Texture_Def.txt" and "Lines_Def.txt" or some Dutch variant of the same? Please start ADE, open the GP Editor but don't make any changes, make copies of those two files and e-mail them to me at don at stuff4fs dot com.

Don
 
And I am still baffled as to why you think, Don, that resizing is virtually useless.
What do you think I would get if I did not resize the following ground poly?

33xk.jpg


And maybe you can explain to me what the Max. 494x494 texture size means in that case.
Note that the texture is a [no def] but that was what I did not realize until later. But with a texture def added it still shows the same.
 
And I am still baffled as to why you think, Don, that resizing is virtually useless.
That's not what I said (or think). What I said was that the Main Texture Size text boxes (to which you seemed to have attributed some unintended capability) are virtually useless and that their content can be inferred from the dimensions in the display panel.

What do you think I would get if I did not resize the following ground poly?
Why don't you try it and see for yourself. What you'll get is a poly textured by a single tile plus a little more on the two protruding corners.

maybe you can explain to me what the Max. 494x494 texture size means in that case.
It means that the texture - as applied - covers an area 494m square. If you check the manual, you'll find that an undimensioned texture (which is how an undefined texture is regarded) is stretched to cover the shortest of the horizontal or vertical dimension of the object - taking into account the aspect ratio of the texture. In this case, it would appear your object covers a distance of 494m. N/S and slightly more than that E/W.

Note that the texture is a [no def] but that was what I did not realize until later. But with a texture def added it still shows the same
Textures that are present in both the Textures and Texture_Dpy folders are always displayed. The [No Def] suffix is simply telling you there is no Texture_Def entry and that, hence, the texture will be treated as undimensioned.

Roby, we have (at least) three different issues being discussed in this thread and we seem to be jumping from one to another without regard to closing any of them. This may not be the most productive approach.

Don
 
Hi Don,

What I meant to say, and maybe then I understood you wrong (but I more or less quoted what you said), is that I need to resize the ground poly because otherwise I would have a very coarse ground texture (like you said about 494x494m) . So I know what I get when I try to apply the texture without resizing it. That was a mere rhetorical question because we both knew the answer.
That I lost my custom texture and line defs, I cannot explain. I just know that somewhere in some recent update they got erased.
I do not see three issues by the way because, as I said, they were solved when I put in a new texture def.
What is not solved is the fact that I had this error message of the program not being able to triangulate as long as there were some overlapping polys (at least that is what I think was the problem because it went away after having adapted the ground poly so as not having overlap any longer).
And no, it cannot be a language issue as the line and texture defs have the same name as on anyone else's computer I imagine(you did not release a Dutch language version of your program, did you?:)).
And lastly, and for the time being, everything I do with the gp_editor still seems a bit unusual;):).
Please bear with me a while longer as I am the prototype of a future gp_poly user and the mistakes I make and questions I ask will probably be made and asked by many others:(.
 
Last edited:
What I meant to say, and maybe then I understood you wrong (but I more or less quoted what you said), is that I need to resize the ground poly because otherwise I would have a very coarse ground texture (like you said about 494x494m) . So I know what I get when I try to apply the texture without resizing it. That was a mere rhetorical question because we both knew the answer.
The way to handle this is not through re-sizing but rather, by defining the distance(s) you wish the texture to cover. That way you get the proper texture resolution for all objects using that texture. Granted, you could get a similar result through resizing an undimensioned texture with a lot of trial and error, but why not do it the easy way.

That I lost my custom texture and line defs, I cannot explain. I just know that somewhere in some recent update they got erased.
Yes. In the initial ADE beta update when Jon took control of updates (about two weeks ago) due to a misunderstanding. But that has now been resolved. You can now update without fear losing your texture control files.

What is not solved is the fact that I had this error message of the program not being able to triangulate as long as there were some overlapping polys (at least that is what I think was the problem because it went away after having adapted the ground poly so as not having overlap any longer).
I must have missed that post. The last one I recall seeing was to the effect that there was no overlap in the poly triggering the message and that you were going to send me some screenshots. If that and the missing texture control file items are no longer issues, great!

And no, it cannot be a language issue as the line and texture defs have the same name as on anyone else's computer I imagine(you did not release a Dutch language version of your program, did you?).
Are your files being overwritten by the GP editor or not? That's certainly the impression I got from your post. If so, the only possible reason is that the GP editor is not recognizing the folder names - which I why I wanted to examine them.)

And lastly, and for the time being, everything I do with the gp_editor still seems a bit unusual.
Without details, this is not helpful. Presumably, you believe the editor is doing something it shouldn't.

Don
 
To amplify what Don said, the best way to handle such "material" polygons (asphalt, concrete, etc.) is to define the *best* resolution in the Texture_Def file (manually or via Tools/GP Texture Editor in ADE). Let's say as an example you find that it looks best when covering 10m x 10m. So set that in the Def file.

Once you have this value set, then (theoretically) whether you create a tiny or huge polygon, each tile of the texture will cover 10m x 10m when you original assign the texture. No resize needed. For tiny polygons, it will only use a small part of the texture, but for huge polygons it will use many tiles of the texture, that hopefully all blend together without looking too repetitive.

Hope this helps,
 
Perhaps an example will make this clearer. I will not resize the texture at all after assigning it:

First I will create a very small GP polygon in ADE, and texture it using the gp_Concrete texture, which is set to be 20 ft on each side in the Texture_Def file. As you can see, the texture covers most of this polygon, 20 x 20 ft:

attachment.php


Now I will create a much larger GP polygon, and the texture covers a much smaller part of the polygon, but again 20 x 20 ft:

attachment.php


Finally, let's look in FS. As you can see, the "size" of the concrete texture is the same for both the small and large polygons - the concrete marks are all the same, not larger or smaller:

attachment.php


Hope this helps,
 

Attachments

  • ade_g1.jpg
    ade_g1.jpg
    83.5 KB · Views: 711
  • ade_g2.jpg
    ade_g2.jpg
    84.2 KB · Views: 687
  • ade_g3.jpg
    ade_g3.jpg
    158.1 KB · Views: 693
Hi Tom,

I really appreciate your explaining it to me and that is exactly what I thought of having done.
Only, this is what I got when I textured a groundpoly with a 20x20ft sized texture:

ppts.jpg


Your explanation led me to once more check what could be wrong then.
And now it turns out that the texture.def entry I made read: "gp_bituminous|20F|20F|20F|true" instead of "gp_bituminous|20F|20F|true".:o
Now that I corrected that mistake everything shows up as it should.

I am afraid that I reluctantly have to refer once more to the last sentence of my previous comment:(.

Roby
 
Glad to help. It's safer to use Tools/GP Texture Editor to edit these files - it doesn't make typos. :)
 
Back
Top