Problem with Hanger Model

Pyscen

Resource contributor
The tests you did, they are just colors right?The colors don't play well in P3D v4.4 or v4.5... also what SDK are you using in MCX,.. what textures is it asking for as textures?

A screen shot of the material editor please.
 

Cédrice

Resource contributor
My last test is an export of Blender "Blender2FSXP3D" is in ".mdl" and opens in MCX in ".MDL" directly the requested texture is in ".DDS" as on the screen.

I used the Blender base cube and the result is correct in the sim :rolleyes:

A.png


B.png


C.png


D.png
 

Pyscen

Resource contributor
Your first picture is representing PBR materials or (ALL). Make sure you have set accordingly at the top (see picture).

NonPBR_materials.png


and when saving to a model, make sure to use (see picture):

Save_as_nonPBR.png


I assume you didn't keep the P3D SDK v4.3 around somewhere or did you purchase P3D after v4.3?

The problem in testing (especially when using just black and white as colors), the shader doesn't work well. This is why in your original testing you had problems (compared to the one you did recently). The white color, in particular, can cause the sparkling effect that you mention in your original post. You know and I know you are not wanting to use PBRs but after v4.4 the Shader engine doesn't know. Whether you intend to use PBR or not the shader will interpret as a PBR (since v4.4 was released). The diffuse maps compared to an albedo map is the difference in that one has directional light information (diffuse). Any white color with the diffuse/albedo maps can be misinterpreted by the shader. The possible workaround is to use an off-white color (add a little color to it - such as yellow - so it's more of a cream color). Unfortunately, there isn't a way to turn off the PBR shader.

Let get back to your 3ds file and why its looks or appears de-arranged... give me some time to locate a test object - unless you would like to share your ".blend" file with me?
 

Cédrice

Resource contributor
I have done a lot of testing in different export formats today without any good results except when I use a primitive mesh of blender.
-I saved the SDK4.3
-I send you my file ".blend" file
 

Attachments

Pyscen

Resource contributor
If you have uninstalled the SDK v4.3, go ahead and re-install it.

Within MCX options (under the Exporter settings), have the P3D v4 BGLComp path pointed to the ...\Lockheed Martin\Prepar3D v4 SDK 4.3.29.25520\World\Scenery\bglcomp.exe.
Again, under the Exporter settings, have the P3D v4 XtoMDL path pointed to the ..\Lockheed Martin\Prepar3D v4 SDK 4.3.29.25520\Modeling\3ds Max\3DSM2012_x64\Plugins\XtoMDL.exe.

Everything else should be left as is. This should help when using non-PBR textures since you are using an SDK that was prior to PBR materials were interduced. Unfortunately, though the simulator within v4.5 could misinterpret the colors - white and black within the diffuse/ albedo map.

Give me some time on your ".blend" file to see if I can't get it to appear correctly within the Sim.
 

Pyscen

Resource contributor
OK...

Exporting from Blender ".3DS" file (see picture). If you do not see this side panel there should be a plus symbol at the top left corner:

3ds_export.png


Make sure the Forward is set to Y Forward and Up is set to Z Up before continuing with the export. I did notice that for some reason the texture isn't being called correctly upon export. I had to replace it within the material editor within MCX. Other than that, within MCX everything appeared as in Blender.

Another option to you is to export it as a ".fbx" file (see picture):


FBX_export.png


Make sure the Forward field is set to Y Forward and the Up field set to Z Up before continuing the export.

I didn't have to replace the texture with the ".fbx" export within MCX.

Keep in mind that the simulator may not like the white color within the diffuse/ albedo map. Other than that, within MCX everything appeared as in Blender.
 

Cédrice

Resource contributor
Thanks Doug !!
the import ".fbx" seems the best option because it keeps the position of the model of Blender only the scale needs a simple conversion
1 = 0.01
the textures do not twinkle I wait tomorrow to do more checking.
-Export 3ds is less interesting because it does not keep the position

the first screen to realize how good the position and the scale are, the second one with the ".BGL" set OFF

A.png


B.png
 
how are you doug i were in naran valley on a trip from my home for days. like to see you again in conversation. how are you doug. i have completeed my jf-17 aircraft model perfectly will soonly uploaded.
 
Sorry I’ve been away for so long. And no, the hurricane didn’t even affect me! Got busy and forgetful

I looked through the previous posts, and believe that Cédrice’s issue in the images may be the same issue. (With the lines at 45 degree angles). Mine were mostly visible because I had a “light source” behind the walls.

Is the solution to “Make sure the Forward field is set to Y Forward and the Up field set to Z Up before continuing the export.”? I’ll give it a try and see what happens.

And interestingly enough, I haven’t witnessed this on other computers my models are on. Not saying it’s not there, but I didn’t see it.

TB2
 

=rk=

Resource contributor
Marion County? I live over by Hood River County, actually across the river in Bob Songer's county, but I have a mailbox in HR.
The lines in the hangar walls are caused by missing polygons, the pattern is unmistakable. You will find, upon close examination, that there are two vertices that are extremely close together and you have a polygon closed by one of those vertices, that you want to be completed by the other. For example, you have your hangar door corners placed directly over the intersection of walls and roof. A wall polygon, or a roof polygon, has been joined to a door vertex and light shows through the gap. You can even see, in your first image, how the light tapers off. Despite being a render of an extremely subtle issue, you can still see the light diminish further away from the door at the narrow end of the extremely long and narrow triangle that is formed by this condition.

Tom mentioned weld vertices, but unfortunately, when the voids are beyond tolerance and the gaps remain, it is no solution. What you need is an available vertex at the head of your gap and it probably wouldn't hurt to disconnect the errant vertex, although these "loose welds," have a tendency to form a natural looking round over, or fillet.
Your solution would be to carefully assemble each face. The problem becomes visible when errant lines from non planar polygons, form incorrect polygons and then leave visible gaps. The hangar has no curves, so this difficulty is minimized.

If you scale the model to extreme size, it is easier to zoom in and examine the problematic intersections. In Sketchup, there is a way to lock polygons, so they can be used for placement and scaling, but the polygons placed will not join or interact with the locked ones. A similar state in Blender could allow you to finalize assemblies, like hangar doors, before joining them to larger objects, whose polygons might intersect.

And interestingly enough, I haven’t witnessed this on other computers my models are on. Not saying it’s not there, but I didn’t see it.
If it is acceptable for you to lower your resolution, such that these details become invisible, it would comprise a solution. Ultimately, it is a render anomaly and micrometric cracks, such as these, actually exist in real life, albeit lacking the geometric absolutism and they would never spill light in this fashion.
 
RK: Yes, I live in Marion County, but in Florida. Quite a distance from you. ;)

That was a really in depth reply, had to wait a few days until I had time to digest it. (was a bit tough for me).

For your reply, did you (somehow) get a copy of my model? Or are you speculating? I do not have missing polygons. (Yes, I do have missing "faces", those which will never be seen behind or underneath ground, walls, etc. but no floating or disconnected vertices.) ALL of my vertices are joined, Example, all of the vertices in a single wall are joined. ALL of those vertices are joined with other walls so the model is a solid single piece. (This is getting increasingly hard to convey). I do not have any doubles, and keep the model as clean and tidy as possible. I understand "light" seeping through gaps caused by edges that are not connected, but in all of my cases, (complaints?), the edges that the light is coming through should not exist! I have a SINGLE plane for a wall. There should be NO center edge where the light is coming through! I convert all of my triangles to quads and by doing so, should eliminate the edge that joins the two and make a single plane. However, it appears that this "dissolved" edge is still visible. (That is what I am seeing in the example above with the airport vehicle also).

I experimented one day by taking a simple cube. I made sure that it was totally made of quads, ALL 8 vertices were "welded", NO open gaps of any kind. I created an inner cube (NOT touching or close to the outer cube walls), and (using "LM" or night textures) made the inner cube brighter than the outer cube. Exported to MCX, then using MCX created the bgl for that cube and placed it at an airport. In FSX/P3D ONLY, the outer walls of the cube looked as if they were still triangles, and not a single plane. It still had light leakage where it should not have been and I still saw an edge as if it was being compiled as a series of triangles. I do NOT see this behavior in MCX when looking at the model! Only in FSX / P3D.

I've been building models for some time now, but only recently using Blender. (I used to use Gmax, but that was years ago). I'm far from an "expert", but familiar enough to be "dangerous". LOL! I truly do not believe it is anything wrong on "my" end, (and would be happy to send you an example), but feel that there is an issue with either Blender, Blender2FSX/P3D, or MCX that is causing this anomaly. To me, for some reason, it will not compile single planes, but converts them back to triangles.

It would be interesting to see someone else's model (on my system) to see if I get the same results (that they do not see on their end).

TB2
 

Attachments

Interested readers may wish to review a related discussion of the OP's hangar display anomalies in this thread: :pushpin:


[EDITED]

I believe it would be a prerequisite for posting relevant info in this thread ...to first read the above cited entire thread. ;)

Of particular note is Page-2 of that linked thread, and these (2) posts with:

OP's linked Hangar 3D model

OP's linked Hangar 3D model exported via MCX ...NOT via Blender2FSX_Toolset


[END_EDIT]


GaryGB
 
Last edited:

=rk=

Resource contributor
For your reply, did you (somehow) get a copy of my model? Or are you speculating?
Whelp this is the problem, int it? Maybe you could set us up a copy of this model and I will graphically demonstrate that to which I refer, otherwise I think we're good here.
I experimented one day by taking a simple cube. I made sure that it was totally made of quads, ALL 8 vertices were "welded", NO open gaps of any kind. I created an inner cube (NOT touching or close to the outer cube walls), and (using "LM" or night textures) made the inner cube brighter than the outer cube. Exported to MCX, then using MCX created the bgl for that cube and placed it at an airport. In FSX/P3D ONLY, the outer walls of the cube looked as if they were still triangles, and not a single plane. It still had light leakage where it should not have been and I still saw an edge as if it was being compiled as a series of triangles. I do NOT see this behavior in MCX when looking at the model! Only in FSX / P3D.
This is a good example about which I am referring, which you seem unaware. In the absolute purest of 3d terminology, you cannot compose a polygon as a square, or any complex shape, with more, or fewer, than three vertices. While certain 3d programs will recognize these "complex polygons," FSX and P3D most assuredly will not and - this is the important part - when the compiler encounters a vertex that cannot complete a triangle, it most assuredly leaves a void. So, if you are not "counting your triangles," so to speak, as this statement implies
It still had light leakage where it should not have been and I still saw an edge as if it was being compiled as a series of triangles.
then you might want to reconsider what I wrote about carefully assembling each face. Make sure the wall, is only that. Count the polygons, there have to be exactly two, for each four sided face. It often helps to offset things like doors, so the edges don't line up. The whole idea of deleting hidden faces is good practice, but really shouldn't amount to any appreciable performance increase with a simple hangar. I write that because without this constraint, you can construct your doors as a complete assembly and set them aside, walls, reinforcements, etc. and not have to rely on their geometry being tied to that of the overall model.

Finally, in your cube experiment, you did not mention any provision to rule out z bias issues, when you ran your test. As a general rule, you do not want to model lighted faces behind opaque faces. The problem arises in that it's a simulator and this is all done with math. As the distance from the viewer changes, the relative distance between the hidden face and the exposed face changes. Depending on the circumstances, this distance becomes the mathematical equivalent of zero, at which point z-flashing usually occurs. You could predict that this is most prevalent with extremely minute distances between the two faces, relative to the viewer and extremely large relative distance between the viewer and pair of faces and it's something to take into account.
 
GaryGB; Thanks!

RK; if my modle is the issue, I’m anxious to learn how to rectify this issue. I will not be available for the next few days, but when I can, I’ll PM you so I can send you an example. Your explanation is (at the moment) a bit over my head, so perhaps you can dissect my hangar and get back to me.

Thanks all!

TB2
 

Pyscen

Resource contributor
Hello

Sorry for being late on your return... and glad that you were not affected by the hurricane!!

I re-read the threads in your problem... and 1 thing popped up. You mentioned about you converting all triangles to quads. Nothing should be converted to quads. This is because of the XToMdl will convert it back to triangles or tris. This could possibly corrupt your model's planes or walls, moving the vertices to compensate. The walls of an object/model will always have 6 vertices (or more). A simple box will have 36 vertices (6 sides x 6 vertices). This shouldn't affect textures at all. This goes for both FSX and P3D sims. Nothing in Blender should be used to convert your model to quads, this also goes to SketchUp (there is a plugin that does convert or mimics such).

You stated that P3D model version of works with no problems, has that changed? Are you using the proper SDK in converting the model for FSX/FSX: SE? Don't mix P3D v4.5 SDK to be used in FSX or FSX: SE. I believe you said you were going to check on that before (after the SDK v1.4 install problems were fixed).
 

=rk=

Resource contributor
The walls of an object/model will always have 6 vertices (or more).
This could possibly corrupt your model's planes or walls, moving the vertices to compensate.
Where do you get your ideas? To avoid confusion, it should be understood that polygons and the number of vertices in simple shapes like triangles and quadrangles, do indeed follow intuition. That is to say that a three sided object, a triangle, has 3 vertices and it is how a polygon is defined in FSX and P3D. If you add one more vertex, that is coplanar with the other three, you can create a quadrangle. It will have two polygons, 4 vertices and will function as a wall.

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." Quads are multi-polygon shapes that are coplanar, that's all. You keep using combinations of complex polygons and have the compiler sequester them all into multiples of 3 and there are going to be some gaps left - it is self evident and it gets old restating it.

If there remains any misunderstanding about this aspect of the Blender convert to quads function, here is a link to a video that lays it out in sophomoric cartoon simplicity, one can't get much more basic than this and check the author, BlenderHelixAlpha, one can't get much more authentic either.

 

Pyscen

Resource contributor
Hello Rick

I admit that the word "corrupt" is most likely incorrect in this case, but what I was trying to say was that this step is unnecessary considering that XToMDL will convert it back into tris. I have personally seen it happen with others and well as myself in attempting to convert something to quads (to clean up the model/ object). If not done correctly, it can cause vertices to merge together and "un-weld" walls, not "corrupting" but could cause problems given the tools used for the sims (such as Blender2FSXP3D).
 

=rk=

Resource contributor
I agree with you, there is every reason to avoid this step. Not to digress, but this observation could help to adjust the OP's workflow. I'd mentioned "round overs" previously and in many cases, these can be desirable. The circumstance is, that no quadrangle is exactly, perfectly, in a Newtonian sense, straight. The fourth polygon, is always slightly out of plane with any other three and it forms a fold across the diagonal. Most modern software ignores this infinitesimal bend, there is a tolerance and it allows for the shortcutting of these "complex polygons." Now, as you approach the edge of a model surface, it is often beneficial to have a little softness, a little round over. In these instances, the complex polygons can be folded beyond the tolerance and form a crease. There are even software algorithms I use in Sketchup to make these rounds, or alternatively facets and they do quite well for making things like tires and hatches.

Ok, I think the problem arises in the differing degrees of tolerance in these various algorithms. Consider, you have one set of software, adding dividers, essentially creating vertices, to provide a nice tapered out, trumpet shape. Then you have another software. This one is minimizing polygons, or it's re-triangulating. You think, everything should work out, right? We did this in school, we divided complex shapes into simple triangles and only the dummies got left with one line sticking out. The issue here is that some poly's are biased on the Y-axis, but others are aligned on the X-axis and at these subtle angles, polygons get left out. If this is the case, then you want to avoid these instances. Stick to one modelling algorithm, if at all possible. If you use multiple plugins or helper files, try to stick to the same author. Avoid complex changes in geometry, where polygons can get mistakenly completed, or filleted, across multiple axis.

Something to consider.
 
Top