Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
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 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.
This is something I never knew existed until I ran into the wall of being limited to one texture per scenery object for X-Plane11. Certainly the advantage of having only one texture is an increase in performance (draw calls) over an object that has 4 or 5 textures and an increase in draw calls. I'm fine with that, although I always allowed MCX to build the texture sheets and I just went with whatever it came up with, so it's more work but better in the long run to have just one texture.
What I don't get. . .at all. . .is the idea of maintaining the same pixel per inch over the entire process (from original hi-res texture to it's reduction for the texture sheet) and ultimately to the final product in the Sim. I produced a texture sheet and assumed that the higher the pixel count the better so I set it 300 pixel per inch for a 4096x4096 sheet and the end result on the object was ok. I decided to check one of Bill Womack's sheets for Nantucket as a comparison. Same texture size (4096) and his work is exemplary and his sheets are 96 pixels and look far better than what I have.
There's probably something my brain is missing because that doesn't make a whole lot of sense to me. Anyone know of a tutorial that explains this concept. . .or have a simple way of explaining it?
I thought pixels per inch/cm was relevant when printing graphics, not applying them to 3D models where mapping and texture file resolution (1024, 2048, 4096 pixels etc) determine the end result. Or am I over-reading this?
I thought pixels per inch/cm was relevant when printing graphics, not applying them to 3D models where mapping and texture file resolution (1024, 2048, 4096 pixels etc) determine the end result. Or am I over-reading this?
That was my original thought as well, but it seems that's not the case. . .at least not the way It sounded when a few folks explained it on the X-Plane Scenery Design Forum. It could also be that I'm the one that's over-reading it Tom.
It's not relevant for 3D objects, it's related to printing on paper. What can be relevant is that you use the same pixels per meter resolution when mapping the texture to the object. Else there can be issues when switching mip maps.
I thought pixels per inch/cm was relevant when printing graphics, not applying them to 3D models where mapping and texture file resolution (1024, 2048, 4096 pixels etc) determine the end result. Or am I over-reading this?
It is! Pixels per inch/cm is only relevant to the media you want to use the image for.
For example: if you’re printing an image on paper, there’s a difference in the amount of pixels per inch/cm you can use. On photo paper you can print more pixels on an inch of paper compared to the type of paper newspapers use. That’s because the ink spreads out on the paper as you print. The higher quality paper, the more pixels you can print on an inch of that paper.
TV and computer screens can only show 72 pixels per inch. So it’s no use setting this value higher. The more pixels you squeeze into an inch, the smaller the dimensions of the image will be. When you downsize the dimensions of an image for digital use, you go down from 4096 to 2048. If you upscale an image (the dimensions) for print you’ll end up with more pixels in your image.
There is a lot that merits consideration regarding texture image 'pixel dimensions' when mapped onto 3D models.
As Arno alluded to above, run time LOD / MIPMAP switching is based on the mapped texture Material "Pixels per Meter" when measured horizontally in the graphic image being displayed on the monitor screen, although the actual FS run time 3D MDL object 'visual' display radius' distance can be tweaked by several methods.
Arno describes how MCX computes 3D model LOD / MIPMAP switching based on object size / pixel extent ...here:
The run time physical dimensions of a 3D model 'Face' onto which an image (nested within other images on a Texture Atlas / Sheet) is mapped, will determine the actual mapped texture Material display resolution in "Pixels per Meter" more-so than the overall dimensions of all images (and the 'empty' spaces between them) on a ex: 1-piece Texture Atlas / Sheet.
This sets "Pixel Dimensions" in a way comparable to mapping texture images for FS SDK Resample custom photo-real terrain.
The distance between adjacent mapped Texture Pixels (aka "Texels") in an area ...may also be referred to as "Texel Density".
[EDITED]
In a 3D modeling application we work with Cartesian Coordinates; with SDK Resample we work with Geographic coordinates.
"QMID (Quad Mesh Identifier) values are an internal system used to optimize the textures required to represent the Earth, depending on the altitude the aircraft is flying at."
AFAIK, "the altitude the aircraft is flying at" is a 'visual display radius' from user aircraft camera to Z-sorted terrain / 3D objects.
Another practical consideration is the FS run time 3D MDL object 'visual' display radius' distance, which although it can be tweaked, will only show higher LODs at closer physical distances between a user aircraft and the 3D model, ex:
As stated by Richard Ludowise (aka "rhumbaflappy"):
"The radius of the LOD20 wouldn't even extend beyond the nose of a large jet... you would never see it from the cockpit !".
"The terrain grid system is radial around the current viewpoint, and, depending on level of detail, radius can be up to 4.5 tiles in either direction, something like 64 tiles. So there is plenty of work to go around. Autogen is more constant, with a 2 km extent being batched."
AFAIK, "with a 2 km extent being batched" means that "Batched" Materials mapped onto 3D models placed as Autogen objects, may 'effectively' result in their being rendered at run time with a texture resolution expressed as Pixels per Meter.
Yet Z-sorted 3D objects with transparency may require multiple "DrawCalls", according to ACES' Adrian Woods (aka "Torgo3000"):
AFAIK, 3D models with "Batched" Materials placed as Autogen are still dynamically switched between LODs / MIPMAPs as a function of visual display radius from user aircraft camera to each Z-sorted 3D object ...just as occurs with terrain objects.
IIUC, for optimal performance in FS at run time when rendering 3D objects placed by BGLComp and/or Autogen annotation, minimal numbers of "batchedDrawCalls" are required, and involves images mapped onto 3D models at UVW coordinates from 1 or more Texture Sheet / Atlas.
Reportedly, LM-P3D now refuses to render Autogen 3D objects unless they are compiled using "Draw Call Batching".
But, IIRC, MS-FS 3D library objects placed as Autogen have always had the 'option' to use minimal numbers of "batchedDrawCalls" from (1) ormore Texture Sheet / Atlas.
However, default FS library objects only have (1) such Texture Sheet / Atlas) UVW mapped onto 3D model 'T-verts':
NOTE: The same UVW Texture Vertices (aka "T-verts") are used by each Texture Sheet / Atlas for Seasonal Variations
Arno previously posted some interesting test results pertinent to factors involved in this aspect of 3D scenery modeling:
Also, a wiki here at FSDeveloper discusses the considerations which apply to the factors cited above when 3D modeling:
Modeling and texturing for optimal performance
"For the usage of textures the basic rule is to choose the right resolution for the object you are making and to use a similar resolution on all parts of your object. "
When 3D modeling in Sketchup, one normally is prompted during creation of a new Material, to declare the intended "Real World" size as an "Area" (based on height and width) at which the texture image is to be displayed,
It is easy to overlook this consideration in Sketchup if directly importing a texture image source to be mapped onto a Face.
One 'can' just drag an image across a Face to size it 'closer' to the intended Face size of a desired 'part' within the image.
But... those wanting to be more precise with 3D modeling in Sketchup may wish to use the default Material dialogs to set the intended "Real World" size at which the mapped texture image 'Material' is to be displayed in FS.
Also, a Ruby plugin script "Goldilocks" by Adam Billyard may prove useful in analyzing the texture pixel (aka "Texel") density and relative complexity of a 3D model:
One can then make them 'unique' for the mapped Face, 'combine them for adjacent coplanar Faces, and resize the combined mapped texture image to the desired resolution / Texel density for the finished 3D model at an 'assigned' resolution using a Ruby plugin script "Make Unique Texture++" by Aerilius:
PS: For those wanting to minimize the "cartoonish" or "legacy era" appearance due to a lack of dynamic range in color depth seen in many X-Plane scenery objects, one might wish to use 24 or 32 bit *.DDS textures for final output from ex: MCX ...instead of*.PNG textures which, although non-lossy like LZW compressed TIFFS for overall image storage, *.PNGs do have an inherently lesser bit depth and dynamic range of color fidelity.
Pixel/inch might can apply to the model but not in Photoshop. Forget about pixel/inch in Photoshop. But thinking that you model is the printing media (paper). Pixel/inch of that model will show how detail it is. If you make a detail texture and map it on a 1 inche square box, the side that you map with 300 pixels looks better than 150 pixels for sure.
I am sorry, I believe this is too complex for the OP, because I can't really understand it. Arno said it largely, although the media is usually described as a modern computer screen, any defined print/render space applies.
Pixels per inch (PPI) is a measurement used to define the resolution of a computer display. This metric evaluates the picture/image quality that a particular computing or output display device is able to display.
Pixels per inch is also known as pixel density. https://www.techopedia.com/definition/2741/pixels-per-inch-ppi
Now, the condition Falcon409 is describing is not the definition of PPI. The 4096x4096 texture sheet will only display 300 PPI when it is a full resolution on the monitor and as the view focus moves in or out, the PPI changes, of the texture, but not the ultimate resolution of the display. I think it's important to settle this distinction.
One of the issues confusing me/us, is how details are applied from these various image densities. Let's for a moment, imagine pixels are only black and white. We will say that a 4096 PPI image has 2048 black pixels and 2048 white pixels on each side and that a 96 PPI image has 48 black pixels and 48 white pixels on each side - a checkerboard, if you will.
Now, can you see that every intersection of four pixels in the 4096 sheet, looks exactly like the intersections on the 96 PPI? This intersection is intended to represent a detail that might display well. Can you see that if you had a 40,960 PPI texture image, that if you zoomed in close enough to accurately cover a four pixel intersection, that the resulting image would be much blurrier and less detailed, than either the 96 PPI texture sheet, or the 4096 texture sheet, zoomed in to view a four pixel intersection? Can you also see that the 4096 texture sheet holds a LOT more image data than the 96 PPI texture sheet does?
Maybe try this idea, for your details, Falcon409. Say you are making a hangar. You have the top, the sides, etc, all laid out photographically, like a peeled orange. Let's say this image was recorded at 300 ppi resolution, for a 4096 pixel square image. Now get larger, or higher resolution images of the man doors, light fixtures and other details and place those in the open areas of your hangar texture. Done the way I describe, a man door may be as large as a hangar door, on the texture sheet, but projected onto the model, it will be its proper size and display much more detail, than if it had been zoomed up from the same size it had, relative to the hangar door in the original texture image.
By using these kinds of tricks, you can achieve the clarity of Bill Womak's 96 PPI textures, while affording yourself the texture real estate of a 4096 image.
Here is a push back tug texture. Notice how the fire extinguisher and instrument cluster are very large in comparison to the vehicle body itself. You can see the orange blur to the left becomes the dirty, worn tow hook.
In my previous post I warned against having different resolutions for different parts of the model (e.g. the fire extinguisher in the example above). In previous versions of FS mixing resolutions like that could result in the wrong mip map to load and thus in blurry textures to show. So IMHO it is best to make sure the entire texture sheet is modeled at the same resolution (number of pixels mapped onto a meter of the model). If P3D still has this blurry texture issue I'm not 100% sure by the way.
May I ask about mipmap?
How the program consider which mipmap to be picked up to display in the scene? I guess the number of the pixels displayed on the screen compare to the diagonal of the screen. So different resolution on different parts cause wrong mipmap to load. Let's assume that fire extinguisher on this push back car is mapped with twice pixels compare to the whole car. But the whole car displayed on the screen has more pixels than the small fire extinguisher, why the program does not pick the whole car as the main thing to pick up the right mipmap texture?
...it would seem that all geometry and (*.DDS) Direct Draw Surfaces are rendered as "quads" and 'triangles':
IIUC, all texture Materials mapped onto all "surfaces" of an object rendered at run time ...'should' be (1) LOD / MIPMAP level ?
AFAIK, this would facilitate FS rendering engine Z-sorting to calculate a "visual display radius distance" from camera to object, and calculating a size for the objects 'surface' area, ...in order to decide which LOD / MIPMAP to display.
IIRC, when the texture Material mapped onto a 'surface' does not have a MIPMAP available for the object's calculated LOD, the rendering engine must 're-sample' the mapped Material to generate a 'missing' LOD / MIPMAP level 'on-the-fly'; this may cause adverse run time rendering performance.
In my previous post I warned against having different resolutions for different parts of the model (e.g. the fire extinguisher in the example above). In previous versions of FS mixing resolutions like that could result in the wrong mip map to load and thus in blurry textures to show. So IMHO it is best to make sure the entire texture sheet is modeled at the same resolution (number of pixels mapped onto a meter of the model). If P3D still has this blurry texture issue I'm not 100% sure by the way.
I respect your opinion, if you are referring to specific examples, like panel gauges, where needle visibility is critical, or perhaps airplane liveries, that demand the best resolution, but I disagree that it is always best to make sure an entire texture sheet is mapped to a model at the same resolution level, for several reasons.
First off, falcon409, due to his simulator constraints, is required to use a single texture. He can only indirectly refer to Bill Womack's techniques and my hybridization of resolutions, so far as I can tell, is the only way he can add both field of coverage and higher detail to an X-Plane model, using a single texture file. The second example, a push back, is also modeled as a part of a scenery. You are implying, I think, that the instrument cluster will never have visible needles in the sim, correct? But it will look like the blurry rendition of an instrument cluster from the cockpit of a plane, which it is pushing back, I'm pretty sure.
To encounter issues with improper mipmap rendering, one would have to have one of the lower resolution sub images, rendered onto an area that requires higher resolution - so the printing can be read on the extinguisher, for example. How would this occur? Zoomed in, looking directly at an extinguisher, the full image would render, correct? So as the view pulls back, eventually a smaller image can be rendered, or interpolated and the extinguisher? I think it's already too small to be more than a red blur, by the time a lower resolution image starts to render anyway...
Mipmaps are invoked to conserve render resources, by allowing a smaller dimension texture image to be rendered when detail is not required. Consequently and imo, texture density management, as relates to mipmap rendering, should be carefully considered, when high detail is required.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
