Problem with Hanger Model

[TBryson2]

Excellent discussion, but WAY more involved (for me) than I had hoped. My intent was IF there is a problem with one of the programs I'm using, then it (probably) needs to be addressed. Perhaps this discussion will lead to that. I also like the way it was worded

"The Blender function simply removes, or adds, dividers between vertices, it never moves vertices. The thing is that the simulator does not support these "quads."

It is the divider where I'm seeing the light leakage, (whether that divider has been dissolved or not), or even the divider itself in P3D/FSX on my models. IF it's true that the simulator does not support these "quads", and always converts them back to triangles, then why only on MY models do I witness this? What can I do at my level to eliminate this issue? I believe I have left one of my models as "triangles" and it still had "light leakage", so that wasn't the answer.

I was initially wondering if the way I've been doing this was the culprit. I select a model in FSX, (.bgl file). I use MCX to "extract" it, convert it to a 3ds then import that into Blender. When I import any model into Blender as 3ds, every face is a triangle. To make my work easier, I convert (alt J) them into Quads. Then using Blender2FSX/P3D, I export the model as a .x or .mdl for MCX, then save my model as part of my scenery (.bg.). Perhaps my method is whacked, but works for me.

Thanks all!

 

[TBryson2]

I couldn't find a way to just send RK my file(s), so I placed a hangar I made into DropBox and can be downloaded here: https://www.dropbox.com/s/azeo82bn97f6ds3/Hangar issues.zip?dl=0

It should have all of the files necessary for dissecting. Also has blender file.

TB2

 

[Pyscen]

Is the P3D version of the model still functioning correctly? or is it both now (FSX and P3D)? What is the reason that you are taking it from SketchUp to Blender?

 

[TBryson2]

I have been working on my airport ONLY with FSX for so long now, I haven't even fired up P3D in awhile! But I did just go in and verify that I'm NOT seeing the "light leakage" in P3D. (I had forgotten this, and apologize).

I have never used SketchUp. Only Gmax, and now Blender.

 

[Pyscen]

OK... Have you exported from Blender as an FBX file and imported into MCX?

 

[=rk=]

To make my work easier, I convert (alt J) them into Quads.

I understand the option is there and I understand how this might allow one to be less careful when modeling for programs that accept these complex polygons, but it seems self evident that in the case for software that does not render multifaceted polygons as flat, it doesn't make the work easier. Case in point, this thread and the broken hangar.

Let's break it down divider by divider, so to speak. Here it is in MCX, to show we're properly oriented.

Now the same view in wireframe mode. Notice the diagonal divisions are exactly aligned with the light leaks in the image earlier in the thread. I have highlighted one, which we will take a closer look at.

Now these divisions are present in all non complex quadrangles and in normally rendered triangular polygons, they are quite normal and subtle, only showing as edges of facets under certain viewing conditions, but now let's take a closer look, bearing in mind, you've performed an operation that arbitrarily removes these diagonal dividers and then upon compiling with any version of the SDK, you just as arbitrarily added them again - and by arbitrarily, I mean to say, you've only loosely controlled the operation, allowing software algorithms to define the details. In this case, the details matter.

Within the area that I have very coarsely circled, we have two planes joining, along the pink line that rises vertically. It and the other pink link mark the polygon with were not concerned. Of concern are the two dividers visible in the plane we're considering, what would be a complex polygon. One will be the diagonal we highlighted above and the other is likely a diagonal from another plane. The problem is that there are too many points, piled into one, that you allowed algorithms to place and I guarantee you that they do not all terminate at that same vertex. One is offset, just a little, within tolerance, but combined with the simulators way of rendering illumination light wash, it becomes "highlighted." What is happening is that there is a tiny sliver of a triangle, missing, formed from the intended vertex, the software generated vertex and the one all the way down at the other end of the diagonal. If you drill right down to that corner, first expand your model to extreme dimension, you can see it yourself. I've edited a million Maya models, 3ds Max models, etc and I can tell you which software made a model, just by these miniscule flaws.

I've provided ample of advice how to avoid this, make the model without complex intersections of faces, isolate individual faces to insure they are composed of only two, triangular polygons, don't allow software to remove diagonals that other software will have to replace, things like that.

 

[TBryson2]

OK... Have you exported from Blender as an FBX file and imported into MCX?

No. Any advantages to doing it this way or just as an experiment?

TB2

 

[TBryson2]

I understand the option is there and I understand how this might allow one to be less careful when modeling for programs that accept these complex polygons, but it seems self evident that in the case for software that does not render multifaceted polygons as flat, it doesn't make the work easier. Case in point, this thread and the broken hangar.

I've provided ample of advice how to avoid this, make the model without complex intersections of faces, isolate individual faces to insure they are composed of only two, triangular polygons, don't allow software to remove diagonals that other software will have to replace, things like that.

1. I believe I understand what you are saying, and as a test, (using blender), I separated the roof top and an offending side from the rest of the model, exported the model into MCX, then exported it as part of my scenery. Launched FSX, and the light leakage is gone from the "dissolved" edges of those faces. By separating the roof top, I removed the complex intersections and isolated those (2) individual faces. This seemed to work, but created a new question / problem.

2. By separating the roof tops from the rest of the roof (roof sides), I now have light leakage at the edges that were previously joined. If I cannot weld the vertices, this will leave loose edges that are not joined together and light leaks through.

3. As an experiment, on one of the separated walls (that has no light leak anymore) I "triangulated" that wall in blender, (Ctl-T), exported the model and now the light leak is back in FSX. "Quaded" (Alt-J) the wall, exported it and the light leak is now gone in FSX. So by converting the quad to two triangles actually made the seam leak. Converting it back to a quad resolved it. Or at least I think it did. I've done so many back and forth experiments today I've burned myself out. Not sure where I left off. I know this doesn't help anyone, but it is what it is. I'll get back to experimenting one day when I'm not so overwhelmed.

Working with quads does not (necessarily) make one careless in what they are doing. It simplifies a lot of procedures, and texturing. (Just my opinion).

TB2

 

[=rk=]

I think an allegory to help understand is that FSX just "isn't as smart." The quad procedure simplifies things, because it makes inferences that the simulator can't. A wavy surface of connected polygons can be considered a face, instead of individual triangles to color. The thing you need to get away from, is the little shards of triangles left as voids.
Perhaps there is an attenuation to the quads procedure you could adjust, such that the tolerance of vertex to face, more closely resembles the .mdl format compiler.

 

[Cédrice]

I would be curious to have other blender user feedback if this problem affects others

 

[Pyscen]

Disregard what I asked before...

But... I have done some testing here... and I have not come across the "light leakage" (as of yet!). What was used or how did you create the Mdl file within your "Zip" file?

I plan to do a few more tests tomorrow (Monday, 9th)... and see what happens with them. Plan on including pictures of the recent test and also the tests I do tomorrow.

 

[=rk=]

But... I have done some testing here... and I have not come across the "light leakage" (as of yet!).

It's important to stay focused here. Using above procedure and the illustration of epidemiology, it is entirely possible we will encounter a wholly new version of the common flu, come up with an entire regimen of treatment and cure, only to discover it is only superficially related to the original disease, in symptom and has no effect upon the underlying cause.
I have the strongest suspicion that the issues arises from a nuance in the OP's workflow and this is the path to a solution. It is common and most beneficial, I believe, for posters to provide a list of softwares used and a specific flowchart of procedures, that someone can follow along and discover anomalies, that has not been done and so we're left guessing. We can't blame the artist, as it's indicative of his methodology, so we can only watch and note the facts that occur to him.

This is the way I look at it, ultimately he has an issue and it's causing him distress. I know what it is, I've seen it many times before, but I don't know how he caused it. Frankly, if it didn't allow the visual discrepancy, we could ignore it. One, very valid solution, could be to "mask" or block those cracks with another row of polygons, but that seems coarse and impractical.
I am also starting to see a yawning discrepancy between normal polygon divisions, and those that are located near geometric edges and how the software algorithms deal with them - it's almost like ray tracing for geometry, imo.

I would be curious to have other blender user feedback if this problem affects others

Similar to Doug, I caution about building an archive of dysfunctionality. Some people will have this issue and not know it, some will have an issue that seems similar and some will know more about it than we do. The problem is very subtle and for that reason, I feel it's best to approach these problems on a case by case basis.

 

[TBryson2]

What was used or how did you create the Mdl file within your "Zip" file?

My method of madness is this (I am rebuilding an airport that someone else started years ago. His models are not the best and need a LOT of cleaning up and updating).

Using the original library (.bgl) file, I

1. Use the latest MCX (1.4.0.0 Dev 11/10/19) and import the scenery library which contains many buildings and objects.
2. Export a selected object (hangar, sign, etc.) from that library as a "3DS Max" giving it a unique filename
3. Import that .3Ds file into Blender and Remove doubles, (there are always a lot of doubles).
4. Convert Triangles into Quads (Alt-J)
5. clean up any loose ends, make sure there are no faces going to nowhere, remove all un-seen faces (bottoms, hidden ones …) remove any vertices that are bogus or merge vertices that are simply hanging on an edge with nothing to do.
6. Resize, rebuild, and generally repair all bad parts. Typically this actually requires me to basically rebuild the entire hangar from scratch. I use the original only for dimensions, but it is possible that some parts are re-used.
7. Texture the model (using Photoshop Elements v7.0)
8. Use Blender2FSX/P3D to export the model (*.x) (I always use the P3D v4 compiler. I know "we" got the FSX compiler to work a few weeks ago, but it stopped for some reason and I haven't tried to fix it yet.)
9. Import that .mdl file into MCX. Correct any texture issues, verify integrity, when satisfied (for FSX) export object as a "FSX MDL object" or for P3d, export it as a "P3D v4.4 Mdl" object.
10. Then using MCX reopen my original library (step 1) and open the scenery objects Editor.
11.. scroll down to the original hangar, and select "Replace Object", select the object saved in step 9, then export scenery back into the original library.
12. Test in FSX (or P3D)

Step 8, I've been using the P3D 4.x compiler for some time now. When I did use the FSX compiler, it didn't seem to make a difference. But, if the general consensus is that I should be using the FSX compiler for all FSX work, I'll get it fixed and try again.

IF I'm doing it wrong, missing a step or getting more involved than I should, please don't hesitate to correct me! For most models, by the time I'm done with step 5, I've realized I should have started all over, and that explains step 6.

TB2.

 

[TBryson2]

RK, don't think your input isn't appreciated, it most certainly is, but a bit over my head. (LOL!). I'm a simple man looking for simple solutions. I do not know the "craft" as well as you nor do I know the language. It is a works in progress for me, more of a hobby. I'll plug away at it and see what happens.

TB2

 

[=rk=]

No problem whatsoever. These discussions serve as a resource and this thread has collected good information from a wide perspective. I think it's especially valuable to express the matters in terms that those that have not yet had years of experience encountering them, are nonetheless able to benefit from the discussion.

 

[Pyscen]

Ok... Sorry about the delay. Real-life interrupted.

Thanks, TB for outlining what you are doing. Unfortunately, we will not be able to assist you with what would be a good workflow at the point of exporting the hangar from the library file. We don't have the library file to work with, but I, personally don't see anything wrong in that part. Though, if the hangar is missing polygons, to begin with, it could cause problems. If you want us to test or follow along with your workflow, you might want to include the 3ds file that you exported from MCX to use within Blender (without any changes done).

The tests that I have done with the model file, I was able to convert it to a library bgl file within MCX. I'm not seeing any "light leakage" from the model within the library file that I created (see picture).

One of the possible reasons could be the Options settings within MCX (that is if at any time it was changed) (see picture - specifically "SmallTriangleLimit" value).

The above tests are only using MCX (latest development release v1.4 - 11/29/2019) with the FSX SDK and the model file that you included in the zip file. I plan on doing an additional test later today (if not tomorrow) using MCX with the P3D v1.4 SDK and the model file that you included in the zip file. I'm not expecting anything different in the results, but I want to be sure it's not the SDK used. I have included the library file that I created.

Dropbox

www.dropbox.com

 

[Pyscen]

3 additional test done and here are the findings:

The 2nd is just like the previous except compiled using P3D v1.4 SDK within MCX. Just like above also, the white areas within the texture are causing highlighted areas along the edges, but not along the tri areas. As expected though, the results were the same as above (see picture):

The next 2 tests involved using the Blender Toolset in exporting the model with FSX SDK and P3D v1.4 SDK. Upon exporting, I assigned new names to each of them, along with different GUID #. After exporting each of them, I imported them to MCX to make a library file for each of them (just like the previous 2 tests). After creating the library for each, I imported into ADE through LOM.

Shown in the picture above, I have placed arrows identifying the areas that need to be corrected. Again, to correct, the areas that are not apart of the UV and white need to be darker (this was mentioned before). If you have noticed also, nowhere along the tri areas have any "Light leaking". Looking at the texture more closely and the model, the vertices might need to be looked at these areas.

I'm at a lost why you are getting the "light leaking" by way of the tri areas. Maybe changing the "texture resolution" (Settings -> Display -> Scenery) within FSX / FSX Steam could help this.

 

[TBryson2]

Thanks Doug for your dedication! Yes, I'm aware of the areas (above) and fixing that texture. (I'm doing a LOT of that lately!), and that was never the issue. But I do appreciate your looking into the "tri areas". This is a big project as there are probably about 20+ hangars that need to be addressed. Only 5 or so have open hangars, which I have interior lighting for. Eventually I plan on working on dynamic lighting, but for now I'm needing to take a break.

I can try lowering the texture resolution and see what that does. I tend to keep mine pretty high. I'll post what I find.

Thanks!

TB2

 

[virtualpilot1460]

Its this still ongoing? I am curious how you managed to get interior lighting going as I'm trying to get some in my own hanger

 

[TBryson2]

No, I kind of got involved with other things and gave up on it. I'm now using dynamic lighting in the hangars (MUCH more realistic!) instead of faking the lighting by making the night textures for the interior brighter than the outside textures.

I'm (slowly) working on making my airport for MSFS anyway. Now what was I just doing? .....

TB2