textures showing up in strange places..xtomdl warning...

[astaticmusic]

12:20 AM XtoMDL Warning warning : Degenerate poly detected in file (C:\KDAY NEW EXPORTS\GP87\tmp1916.x) mesh (Part1)...etc...

after looking for this "poly" in the model, there is nothing there. ( i used a effect placement with the coords of the "poly" to see where is was located in MCX, then looked into the model - it was a blank area)

the texture that was getting splayed all over - no pattern decernible - i deleted it and made a new textue sheet, then retextured all the places again. the second time it wasnt as bad but it still shows the NEW texture like it was showing the 1st one.

this only happens after i run the GP wizard, when i make a regular bgl out of the model, it doesnt happen.

1st version...
.

in the sim

after i redid the texture and replaced all the previous ones...

has anyone ever seen this before ? is there anyway to fix this? deleting all the previous textures and redoing them all with a brand new texture sheet didn't work, it just did the same thing with the new texture sheet.
Need some help here!! Thanks!

(sketchup for the model.)

 

[=rk=]

You need to keep the model very clean and tidy. This is likely a consequence of reversed faces and "hidden" geometry. Remove all textures and confirm that all default faces show the same color orientation. You must not apply textures to grouped and closed parts of the model, if you texture a closed group, then the backside of every polygon in that group gets textured undesirably. Research and download clean up extensions to remove unwanted clutter and geometry.

 

[GaryGB]

https://www.fsdeveloper.com/forum/t...ange-places-xtomdl-warning.443652/post-806367

12:20 AM XtoMDL Warning warning : Degenerate poly detected in file (C:\KDAY NEW EXPORTS\GP87\tmp1916.x) mesh (Part1)...etc...

after looking for this "poly" in the model, there is nothing there. ( i used a effect placement with the coords of the "poly" to see where is was located in MCX, then looked into the model - it was a blank area)

the texture that was getting splayed all over - no pattern discernible - i deleted it and made a new textue sheet, then retextured all the places again. the second time it wasnt as bad but it still shows the NEW texture like it was showing the 1st one.

this only happens after i run the GP wizard, when i make a regular bgl out of the model, it doesn't happen.

The fact that SDK XtoMDL is involved here tells us that you are not making a SCASM / ASM non-MDL-type of G-Poly in this particular scenario.


So now I am compelled to inquire:


Which SDK XtoMDL was used by MCX G-Poly Wizard when output to the BGL seen in screenshots above (...displayed in FS and also re-imported into MCX) : ?

* FSX

...or:

* P3Dv4.x


If P3Dv4.x SDK XtoMDL was used for output, was Z-Bias also assigned as a Material Property by MCX G-Poly Wizard ?


Which of these options in MCX G-Poly Wizard were used when output to BGL: ?

* Slice Polygons (100 Meters)

...or:

* Group Polygons (ex: 500 Meters)

...or:

* 'Both' of the above options for slicing / grouping (...at thier respective Metric vertex intervals on-ground)


GaryGB

 

[Aviasim]

I've had this issue before and corrected it by splitting up the element that uses the texture.


So if you have all of your markings that are on that texture sheet collapsed to one mesh.. try separating it so each texture within the sheet is it's own geometry

 

[astaticmusic]

THanks Rick, I am testing a thomthom: CleanUp v3.4.3 to see if it would be of any help at the moment. may possibly be a good idea - even without running into trouble first!

Thanks Gary, I am using the p3dv4 xtomdl, and yes, under the optimize tab in mcx i followed the steps to optimize (i think i did it right - if the color green lights up on the texture, then you should use the cooresponding side correct? that was always a little fuzzy on that, being that arnos demo of the optimize was a tad bit older and mcx has undergone significant changes since the video was made)
I also had the group polygons unchecked, there was no slice option i am aware of either.

EDIT: sorry Gary, i just saw that the slice polygons(100M) was checked

Thanks Darren, when you say element - you mean the textured face right? what exactly do you mean by "separating it so each texture within the sheet is it's own geometry "
i will be glad to try anything. Is this basicly the same idea as to cut the long stripes (runways edge) into smaller parts mabey?

i am here now and for the rest of the day i will be working on this. Cheers!

 

[astaticmusic]

Update: somewhere between the cleaning of the GP and cutting some very long textures down to smaller chunks, I got it to work. I always try to work very cleanly when building something so complex but occasionally some things get by.
Thank you for your help.

 

[GaryGB]

https://www.fsdeveloper.com/forum/t...ange-places-xtomdl-warning.443652/post-806393

Thanks Gary, I am using the p3dv4 xtomdl

https://www.fsdeveloper.com/forum/t...ange-places-xtomdl-warning.443652/post-806384

If P3Dv4.x SDK XtoMDL was used for output, was Z-Bias also assigned as a Material Property by MCX G-Poly Wizard ?

GaryGB

https://www.fsdeveloper.com/forum/t...ange-places-xtomdl-warning.443652/post-806393

..., and yes, under the optimize tab in mcx i followed the steps to optimize (i think i did it right - if the color green lights up on the texture, then you should use the corresponding side correct?

(I) that was always a little fuzzy on that, being that arnos demo of the optimize was a tad bit older and mcx has undergone significant changes since the video was made).

IIUC, you refer to this tutorial video by Arno:

ModelConverterX - Optimize model

IMHO, where- and how- one might use this MCX option, will depend on how "clean" one's 3D model is to begin with when it is (re_?)-imported to MCX G-Poly Wizard;

MCX - Optimize model functionality will become more clear on repeated viewing of Arno's tutorial.


Certainly Rick's advice to use proper 3D modeling practices in the work-space, and when necessary, to use ex: thomthom's CleanUp plugin Ruby script, may have some merit when considering a possible work-flow which generates these types of anomalous results.


Since we are < supposed to be > dealing with flat 3D (sur)-Faces (...segmented by MCX G-Poly Wizard at 100 Meter intervals on-ground along the N-S, E-W Cardinal axes, aligned to the local horizontal plane of- and fitted to- the airport-flatten and not to a variable local geoid of the FS "curved Earth" 3D world model) ...in order to allow Airport AI and Ground Vehicle traffic to operate normally, we must initially maintain relative simplicity in our 3D models by creating only adjacent co-planar Quads that will be later triangulated internally during compilation by SDK XtoMDL.


Thus, in Sketchup, a caveat to consider with G-Polys may be to disable "Smoothing" on initial- if not all- passes of thomthom's Cleanup, which IIRC, is enabled by default in that plugin Ruby script.

Another caveat to consider with G-Polys may be to disable "Merging of Identical Materials" while ignoring their Material Property 'Attributes' on all- passes of thomthom's Cleanup, which IIRC, is also enabled by default in that plugin.

FYI: This "Merging of Identical Materials" process may be performed with better interactive control via Arno's MCX.


Note that other default settings of thomthom's Cleanup, are enabled by default in that plugin Ruby script, so we must carefully review in advance, Cleanup options ...and the resulting impact each has on a 3D model.

And of course, ONLY use thomthom's CleanUp plugin Ruby script on a Sketchup-exported COPY of your 3D model.


We must also be aware of distinctions between ways to maintain model detail via relatively complex geometry, while also striving for better performance without allowing non-coplanar Faces to exist in a G-Poly.


I was made even more aware of issues related to grouping, welding, smoothing ...and MDL statistics for "polygons" (triangles) and vertices versus run time performance, when I researched this SDK XtoMDL "Degenerate poly detected" error.

https://www.google.com/search?source=hp&ei=7hGhW_PNOsOctAW2wpiwAQ&q=FSX+SDK+XtoMDL+"Degenerate+poly+detected"&btnK=Google+Search&oq=FSX+SDK+XtoMDL+"Degenerate+poly+detected"&gs_l=psy-ab.3...2273.48031..49125...0.0..0.199.3858.18j20......0....1j2..gws-wiz.......0j0i131j0i22i30j33i160j33i299j33i10i160.BmMLSawrseM


To better understand an optimal work-flow to avoid this type of anomaly, perhaps we might first review some explanations of the distinctions between a few Sketchup features recently suggested for creating G-Polys:


Soft vs Smooth vs Hidden Edges

http://www.thomthom.net/thoughts/2012/06/soft-vs-smooth-vs-hidden-edges/



Another workflow to preserve detail while also minimizing adverse impact on performance ....is explained here:


Reversible Smoothing in SketchUp via Grouping, Triangulation, and 'Soften Co-planar' Methods

http://rctlounge.com/forums/showthread.php?t=5511



NOTE: If there are graphical anomalies with "smoothing groups" when displayed in MSFS at run time, one may try using "Sketchup Loop Subdivision Smooth Plugin" instead of Sketchup default tools for 'smoothing':

http://sketchucation.com/forums/viewtopic.php?t=43556

http://www.guitar-list.com/download-software/sketchup-loop-subdivision-smooth-plugin



Arno: Please correct me if I am mistaken, but assuming the 3D model in the OP above has been properly (re)-imported into MCX G-Poly Wizard with both the required options 'checked':

* Project flat polygons on ground using normal tolerance (ex: 0.990)

* Filter out non-ground polygons

...the anomalies seen in the OP appear as though MCX - Optimize Model engine may not be warning end users when any further consolidation of a particular mapped texture Material will map too many texture vertices to the same (1) Material, thus, IIUC, breaking a SDK Cardinal Rule of: "T-Verts Limited To 65K Per Material", and allowing ones 3D Model to 'turn to the dark side ", leading to degenerate polys that have an "evil" influence on MDL compilation via XtoMDL.

https://www.fsdeveloper.com/forum/t...ange-places-xtomdl-warning.443652/post-806393

I also had the group polygons unchecked, there was no slice option I am aware of either.

EDIT: Sorry Gary, i just saw that the slice polygons(100M) was checked

IIUC, Arno's MCX is rather forgiving with imported 3D model inter-vertex "snapping distance" tolerance limits, and for 'co-planarity' that allows welding and formation of a DirectX "Direct Draw (Sur)-Face" capable of being UVW mapped with a texture Material ...to output a 'cleaner' MDL more likely to be 'tolerated' by SDK XtoMDL when output to a standard static 3D scenery object.

But one might wonder what may result when improper geometry is present in a 3D model, especially if the 3D model in the OP has NOT been properly (re)-imported into MCX G-Poly Wizard with both the above required G-Poly input options 'checked'.

https://www.fsdeveloper.com/forum/t...ange-places-xtomdl-warning.443652/post-806393

Thanks Darren, when you say element - you mean the textured face right? what exactly do you mean by "separating it so each texture within the sheet is it's own geometry ".

I will be glad to try anything. Is this basically the same idea as to cut the long stripes (runways edge) into smaller parts maybe?

I am here now and for the rest of the day i will be working on this. Cheers!

I'm not Darren, but IIUC, this may have to do with the MDL in question having broken a SDK Cardinal Rule of:

"T-Verts Limited To 65K Per Material"

...with UVW mapping of (1) or more texture Materials ?


Hope this helps !

GaryGB

 

[astaticmusic]

Thanks Gary, Im absorbing the information.