Hi, some of us really enjoy making completely custom pavement via the ground
poly method and then import them using the “Projected Mesh” option via the
SDK. The obvious (huge) setback here is that texture quality is at least
sliced in half, if not more, when object is inserted as “Projected Mesh”. If
we import the exact object as a “Scenery” object, the resolutions is perfect.
Please, we really need the “Projected Mesh” to offer full resolution textures.
Thanks. (photo credit FINNI)
Hello! Thanks for reporting this. I think it’s more of an Idea than a
Question, but we’ll already do some digging. Did you also post your question
on the forum thread for the next live SDK Q&A;?
<https://forums.flightsimulator.com/t/sdk-q-a-scenery-editor-
questions/406757/22?u=sonantalpaca524> (I’m asking because the same question
was posted here a few minuts ago 
So if it wasn’t by you, you can definitely
vote Up for this in the forum!)
Hello! Thank you, yes I did post it for the Q&A; sesh. BTW its says it will be
on the 16th, but do you know what time?
No official confirmation yet, but it will most likely be at the same time as
the previous one (which was at 8pm in France)
Hello, I just watched the SDK Q and A from yesterday and noticed the devs were
looking for more information regarding the issue mention above. They claim
that it’s for performance reasons that ground textures (specifically -
PROJECTED MESHES) are not full resolution, but why is it that we are able to
add the same object as a regular sim object without any performance hit yet
have full texture resolution? If only we could have that regular sim object
contour to mesh, we’d be VERY happy. Please SDK Dev’s, I plead you look
further into this. Thanks in advance.
I’m joining to this Idea/Question. My other problem with the projected mesh
that it always has a kind of gravel normal map eventough the projected meshes
contains completely flat normal maps. Somehow still the “ground” overwrites
the projected mesh normal maps.
Hello, have you changed the “type” of surface in the properties window? I
believe “unknown” clears any gritiness. Also, as I just posted, SDK developer
Eric yesterday said on the stream that high resolution is not possible due to
performance, but my question then is, why don’t I see any performance impact
when it imports as a standard scenery object? I’m surprised that this has not
been not been brought up more often considering many of us use ground polys to
make our pavements and pavements are an absolute large part of airports,
obviously.
Hello lapalabra, I thought you were talking about a difference in resolution
between the projected meshes and the other ground textures, which would have
been surprising. But if you’re talking about scenery objects, then that’s
normal. We can’t match and cover the whole terrain with the same pixel/meter
ratio you can reach with small and localized objects in the scenery. Nothing
prevents you from putting an 8K texture on a 1cmx1cm square in your scenery
and we obviously can’t match this, a limit has to be found. The terrain
textures in which projected meshes are rasterized have their resolution
adjusted to get the best result/performance ratio. Regards, Sylvain
Hi Sylvain I understand the choice, with a view to optimizing you could tell
me the maximum resolution you have on the projected mesh in terms of pixel
meters, (also indicative) so that the textures I create do not waste precious
memory space if they go beyond the maximum resolution. Thank you! Alessandro.
Thank you for the reply, Sylvain. I understand to some degree, but still a bit
confused. A flat, 2D plane the size of all my entire airport is imported as a
scenery object and displays at full resolution, yet has NO impact on
performance. We’d use it, but unfortunately it doesn’t contour to mesh as
projected meshes do. Would you please further explain why the projected meshes
DO cause performance issues? Thank you. Also, I too would please like to know
what resolution the maximum is that projected meshes can produce so I don’t
waste space with higher resolution textures. Many thanks! -J
Hi Sylvain, The main problem to get high quality ground (apron, taxiways,
markings…) is that MSFS compresses original textures resolution and makes it
blurry. I don’t want to use 4K for everything, just maybe 2K or 1024. Other
problem is that every apron surface covered by only one detail texture -
asphalt. But how about concrete? Or maybe to create apron without detail
texture, for example, if we need to apply layers with winter textures with a
condition for dates(after releasing the seasons feature). To get something
like that (FS9):
was my question for your Q and A. <https://forums.flightsimulator.com/t/sdk-q-
a-scenery-editor-questions/406757/16?u=artairxbox> I really hope you guys pay
attention to this imperfection) We really need some improvements in scenery
editor. Regards
Thank you ArtAir! The more we have showing that this indeed is a huge
setback, the more we hopefully convince them to improve it. As I’ve said
before, performance is NOT an issue here considering the SAME object
is imported as standard scenery objects with 2k or 4k textures has ZERO impact
on performance. I apologize if I keep beating a dead horse here, but I will
until a detailed explanation is given as to why it can’t be done or an actual
improvement is made as this is something that holds many developers back from
delivering some amazing pavements. With much respect and passion, -La Palabra
Regarding the downgrading. To be honest it does not happen always. At least
sometimes the editor shows it blurry but in the sim it is okay. On the other
hand I do not understand the downgrading if it really happens. I can cover a 1
sqkm land with 4 1024x1024 textures or with 1 4096x4096 texture. Not the
texture size should be the key but the pixel density. Anyway let the add-on
developer decide how many textures in what density will use.
In my experience, importing via projected mesh ALWAYS downgrades
quality. The picture in my original post post above is a perfect example of
how detrimental this downscaling is to the objects. It looks awful. The
mystery remains - WHY is this necessary? Performance is NOT a valid reason
as I’m able to import the same size object as a standard scenery object at
FULL resolution with ZERO performance hit. Please, Asobo, we need
answers here. We’re living in times where we can have **AMAZING **pavements,
but are just ONE step away …
Hello, I’ll give some more details on how our system works so you can better
understand its limitations. When using the Scenery Editor Taxiways, Aprons,
Polygons, ProjectedMeshes, these elements are baked into the terrain textures.
Among other advantages, it reduces the polycount and can be terraformed. But,
logically, It means your asset quality can’t have a better resolution than
what has been defined for the terrain textures. The terrain tile system is
based on this : [Bing Maps Tile System - Bing Maps | Microsoft
Docs](https://docs.microsoft.com/en-us/bingmaps/articles/bing-maps-tile-
system) … but we increased the resolution for higher LODs so we have a
better quality for airports. In the end, the resolution you get is around
4cm/pixel at the equator. We can’t match the resolution you will have for your
source asset using this rendering technique since the amount of needed VRAM is
growing exponentially when we go further in the LOD tree or increasing the
texture resolution. Set your “Terrain level of detail” option to its maximum
value to get the best resolution possible We are open to discussing
improvements of the system but can’t simply match the very high resolution you
can have with textured meshes. If you have requests or precise ideas on how
this system can be improved like defining your own detail maps for example; I
suggest you create ideas about this. Regards, Sylvain
"Other problem is that every apron surface covered by only one detail texture
- asphalt " The detail map can be chosen from the properties of the projected
mesh layer.
Thanks Sylvain for the answer, it is as I imagined, I think that implementing
the possibility to choose a custom detail for the textures of the projected
mesh would help a lot without increasing the overall resolution, sometimes the
default detail does not match at all with the custom materials. The assignment
of the detail could take place through a dedicated mask (perhaps in shades of
gray?) to match the different details to a specific area of the projected
mesh.
Hello Sylvain, Thank you very much for taking the time to carefully explain
the limitations of the system and now it does make a lot of sense to me. I
suppose, as Alessandro suggested, having the ability to import a custom
“detail” layer would be wonderful as I also agree that the default “details”
are not exactly what we’re looking for. I will make an “IDEA” post regarding
this. Thanks again! La Palabra
Hello La Palabra, Yes, creating an idea about this is the appropriate action.
Thank you for your feedback. Regards, Sylvain
I appreciate Asobo’s answer but the main issue with that line of reasoning
(mapped to terrain) is that this more-or-less requires us to make our own mesh
if we want to have sloped terrain on the airport. The problem is that the old
way of making ground polys (i.e. using flat polys) means that you get terrain
elevation bleed-through. This is a very frustrating aspect of the sim for me
as well; taxiway lines at my airport are between 15 to 30cm wide, which means
at 4cm/pixel I have a budget of maximum 6 pixels for the line. That quality
will just not work for markings. That, and the fact that a surface overlay
(asphalt/concrete/paint) ruins the texture as well. I understand that you
don’t need 4cm/pixel resolution for, say, a large concrete apron, and that in
that case it should be more than enough. However, detail work is impossible
and there is no proper workaround (unless I want to model the entire airport’s
terrain myself) using projected meshes. I would second/third/etc. the request
for a seperate detail layer or setting that allows for a much higher
resolution, or even another category that automatically prioritizes it above
the terrain but follows the contours properly.