Full Version: MOI mesh export issue

Show messages:  1-3  4-23  24-43  44-49

>>>So chances are it's also a matter of file format + DCC/Render Engine.
(.FBX is probably better to use to deal with Ngones ?)

Bad mesh is bad in any DCC. MOI's export preview is rather schematic and hides the bare truth :)
On attached pic: The default triangulated fbx inside Sketchup without any fancy metallic shader.
You know where I see TONS of those ugly fillets? On furniture manufacturers sites like Vondom, Kettal, B&B etc.. They design their master pieces in NURBS programs like Rhino and then translate models with defaults settings to FBX\OBJ\3DS - the results are awful almost on any fillet.
I really hope Michael could find some elegant solution..

Image Attachments:
su.png 

---

Hi rom, when you export with n-gons, there aren't any triangles stored in the file. The receiving application will generate its own triangulation of the n-gon, or with FBX it's possible to use triangulation from the FBX library code which is what tends to make FBX have more uniform behavior.

I wonder if your render engine and current settings are particularly sensitive to skinny triangles.

Does your renderer use raytraced shadows? What happens if you turn that off, do the darkest spots go away?

- Michael

---

I know nothing about Sketchup, but this example here looks like "you" simply f**** up the baked vertex normal.

While I do agree about the issue pointed previously (that again can be fixed using the centroid .ini option), what you call 'bad topology' is irrelevant if you handle the baked vertex normals correctly, meaning, don't touch it, don't discard it, don't post modify the topology unless you know what you are doing.

Also it would be more productive if you give a little more info about the DCC/Render engine you are targeting. I did created tons of large rendering (8-20k) using mesh coming from MoI without much issues, at least no more that all the crap you can get with 'traditional' modelling. (usually coming from mistakes not really visible when working in the viewport, but get revealed at rendertime).

---

Hi Michael, I guess the "non centroid triangulation" tri-export will showcase those tiny triangle connection problem in any render engine really, especially on reflective surface, but also on self ray-trace shadow (along with the usual shadow terminator problems).




... once centroid option is activated everything is fixed.



Do you think the Ngones .FBX internal triangulation could benefit from this centroid triangulation too ? I don't trust my Hou setup that much :P

Image Attachments:
CentoidTriangluationRender.JPG  NonCentoidTriangluation.JPG  NonCentoidTriangluationRender.JPG 

---

SketchUp was never really designed to have curved objects in it at all. There isn't any way (at least last I checked in the SDK) for it to contain vertex normals so it's inevitably going to have shading problems.

However, with this particular case it looks like maybe the skinny triangles might be reversed as well. That may be the larger problem.

re:
> Do you think the Ngones .FBX internal triangulation could benefit from this centroid triangulation too ? I don't trust my Hou setup that much :P

I guess so but that would be a long process to try and get Autodesk to change that.

I kind of remember there may be an option to supply a triangulation, maybe I should do that.

- Michael

---

I see, I didn't know that would involved Autodesk :S

---

Hi rom, so it's not that the skinny tris are reversed exactly, it's that the n-gon that they are carved off of is non planar enough that they are ending up pivoted quite a bit.

Here's what I mean, this is a side view of one of them:





Then it seems like your render engine does not like having a little face that has a face normal deviating quite a bit from surrounding other face and vertex normals, it probably gets the surrounding area dark by thinking it's in a shadow. (if there is an option for raytraced shadows bias factor bumping it up could reduce this "self shadowing" effect)

Was this fillet made in MoI v5? It kind of looks like there is just a little too much of a gap between the fillet surface and the cylinder which looks like it contributes to making the n-gon more non-planar. If this is coming from the new ACIS fillets in MoI v5 it would probably help if I tightened up the fitting accuracy for the conversion from ACIS just a little bit more.

If you turn on the moi.ini flag CentroidTriangulation=y as mentioned above, it should prevent these types of tris from being generated. With that enabled, n-gons will get triangulated like "slices of pie" from each n-gon edge to a centroid point (when possible).

Also this problem should automatically get reduced with an increased density of polygons. That's because when n-gons are larger and span a larger area of a surface the degree of non-planarity is also increased. As n-gons get denser they occupy a smaller region of a curved surface which naturally acts more and more like a plane instead of a curve.

So there are a few different things I can try to prevent this. First is if it's a new problem showing up particularly with fillets done in v5 I can probably tune the accuracy of that up. I have a few other ideas to experiment with as well.

Thanks, - Michael

Image Attachments:
skinny_pivot1.png  skinny_pivot2.png 

---

I Am getting the same artifacts from Rom's model when I get close. So I made my own and I am not getting them I uploaded the 3dm file and the blender file.

Attachments:
test.3dm
test.blend

---

>>>Hi rom, so it's not that the skinny tris are reversed exactly, it's that the n-gon that they are carved off of is non planar enough that they are ending up pivoted quite a bit.

This is precisely what I'm trying to describe (maybe a bit awkwardly - due to the language barrier :) from the first post. If the exporter generates thin faces rotated approx 70-90 degrees to the surroundings (yep, see skinny_pivot1.png) - it will look cr@ppy virtually in any
DCC\Renderer (BTW in Max I use Vray (Vantage) - I declared it earlier, the model was created in vanilla MOI v5, but I think v4's Exporter would generate the same faulty topology)
I just humbly suggest that mesh exporters should to pay closer attention to the seams between sub-surfaces (seams between fillet and cylinders in my example). IDK, Maybe dedicated (visible or invisible in UI) vertex weld radius, aspect ratio, angle between faces settings.
Regards,

---

Hi rom, has this only happened specifically on fillets created in MoI v5 ?

Do you have any other examples aside from v5 generated fillets?

- Michael

---

I think its rather common decease in any NURBS mesh exporter, not just v5.
I'll try to share additional examples later, but its easily reproducible if one doesn't try to hide by injecting higher poly count.
Thank you for attention

---

Hi rom, it looks like it might be more of a problem with fillets made in v5 where there is an unexpectedly large gap between the fillet surface and the cylinder surface.

So it may be fillets that need fixing up more than or in addition to the mesh exporter - I'm investigating it.

However as mentioned above if you set CentroidTriangulation=y inside moi.ini it should fix the mesh export for now, can you confirm that?

Sorry I didn't understand what you wrote originally!

Thanks,
- Michael

---

after ini edit it looks way better, THANK YOU so much!
lets hope your investigation will deliver even more refined results

Image Attachments:
iniedit.png 

---

OK here is another example default fbx export (MOI5, ini edit ON, hope it'd help in exporter polishing
numerous artifacts (long thin triangles fail to maintain the general fillet curvature)
Regards,

Attachments:
New folder.zip

Image Attachments:
Screenshot 2024-08-27 113519.png 

---

Hi Michael,
In 2016 in the old thread about centroid triangulation you wrote:

@metin, re:
> Michael, maybe it's a good idea to add the Centroid triangulation option as a checkbox to
> the mesh export options of MoI V4, to make it more accessible? Thanks in advance.

Yes, that sounds like a good idea to add for V4, if you can remind me about it again when v4 starts up I will add it in.

So i would like to remind you for V5 :-)

---

@rom

Looks again like a vertex normal data problem on your side. That's the .FBX provided directly rendered in Houdini.
I know Max have hundred of options in the .FBX import dialog, there must be something about recomputing vertex normal's, or creating Smoothing Groups that need to be disabled.
The goal is the read vertex normals MoI's created.

Previously you said : `MOI's export preview is rather schematic and hides the bare truth`.

Actually that's not true, the mesh MoI display at export time should look exactly the same in your DCC viewport. If you see a difference, like dark shading area or ugly sharp triangle like you post above using the 'generic' display mode (opengl/directx/Vulkan), it's a good indication that something is lost in the import process, or something get mess-up after the import (vertex merging, attempt to reduce/edit the geometry, normals re-computing using an average method etc).

Image Attachments:
K01.JPG 

---

Hi rom,

re:
> (long thin triangles fail to maintain the general fillet curvature)

Low poly artifacts like that will just generally be what you can expect if you are trying to restrict polygon count.

The main way to make polygons adapt to the fillet's curvature better is to move the slider towards the right so it will have more subdivisions in curved areas.

I don't really understand why you refuse to do that?

For this case put in angle = 8 and divide larger than = 4 and that will make a much higher quality mesh for rendering at just 25k polygons for the whole object.

The defaults are generating just 3k polygons for the entire object, it's just not enough density for rendering quality on something that has tightly curved fillets.

If you want a higher quality result for the default, you can set Angle=6 in moi.ini , that should change what is used for the default angle.

- Michael

---

Hello Michael,

I'm really hope I'm not wasting too much from you time. I'm rebuilding 'my own' centroid triangulation, and I'm wondering what's is the rule used to excluded large ngones form that process. MoI "centroid" doesn't do that horrible cap. Do you just skip it if ngones to process contains too many points ? I can also see that concave ngones can't be triangulate that way, are you exlcuding those one from the 'process' ?

Not super important, I'm doing 'stuff' very far from my comfort zone, but I'm kinda curious tho. !

Image Attachments:
Centroid.JPG 

---

Hi PaQ, there isn't a limit on number of points but it does a test that the centroid triangulation won't make a mess.

That happens in UV space and it's pretty simple. For every edge of the n-gon, make a triangle out of the centroid point and the edge points and calculate the signed area of the triangle. If the area is negative it means that triangle is reversed in orientation so don't do a centroid triangulation on that n-gon.

Signed area of a 2D triangle goes like this:

With 2D points K, L, M

XLK =   L.x - K.x;
XMK = M.x - K.x;
YLK =   L.y - K.y;
YMK = M.y - K.y;

signed_area = 0.5 * (XLK*YMK - XMK*YLK);

The sign will be negative if the triangle vertices are in clockwise order, positive if counter-clockwise.

ref:
A programmer's geometry pg. 62
Adrian Bowyer, John Woodwark
Page 62, chapter 4.1 "Area of a triangle"

You can leave out the * 0.5 in this case since it doesn't actually need the area, it just needs to know if it's positive or negative.

- Michael

---

Oh nice, thanks for the explanation, I will try to apply that logic !

---

Show messages:  1-3  4-23  24-43  44-49