Notifications
Clear all

[Closed] Select Alternating Polygons?

I have a very specific problem which I suspect can be solved using Max Scripts, but I’m not certain, so I’d like some help.

I’m converting some models from Rips that I’ve made with the Ninja Ripper tool (1.5.2), and Ninja ripper has a knack of inverting normals for seemingly no reason.
If ALL of the normals were inverted, this would of course not be a problem, but the normals usually end up looking like a checker-pattern, which makes me think a max script can be used to select alternating polygons, and then the Flip command can be used to flip only those normals, without going through the long process of manually selecting those polygons.

Here’s a common example of what I’m talking about:

So as you can see, the shape is complex, which prevents me from using something like Dot Loop, but it’s very clear that there’s a pattern to how the normals are oriented.

I mainly work with .OBJ files, and I suspect that we can achieve the desired result by writing a custom .OBJ importer script, which would flip every other normal as it is being imported. (I’m not sure if 3dx max preserves the order that the polygons are imported in, so this may be the only option)

Any input would be greatly appreciated.

15 Replies

To illustrate what I mean with the .OBJ importer script, this is a notepad view of the .OBJ file which is in the viewport of the 1st picture.

You can clearly see when the normals are being flipped.

Oh, and I forgot to mention earlier, but the “Unify” command in 3DS max doesn’t work in this case. it changes the normals to be out of pattern, but still not unified.

It’s not a terribly big problem for low-poly models, but I recently did a higher-poly model with this problem and it took near an hour just to solve this normals problem…

what happens when you convert to editable mesh and select all faces and press unify ? (ok just read the second bit)

I don’t think the normals are to be blamed here as they are discarded by max anyway and recomputed… it’s probably face vert order issue some faces are cw and some ccw (so when max recomputes the normals they are reversed)

can you post a sample file ?

Probably won’t work, as you mention in your second post, but just to know.

Without having an object to test it is hard to know if there is a pattern, but you could try:

Add an Edit Mesh modifier
Select all verts and weld them
Add a Normal modifier and check Unify Normals
Convert back to Poly

See if Flip Normals needs to be on or off.

Yeah, I’ve tried using the proximity based auto-weld feature and then using Unify, but it was more or less the same result (as Unify without weld)
Doing a manual weld would probably work, but it would be just as inefficient as manually flipping normals (at best).

Here’s the sample files. I know the UV is also messed up, but that part is much easier to fix manually.

https://pastebin.com/raw/71hcF4LD

Another thing which I just thought of, is maybe we could edit the MaxScript which is used to import the .RIP files… That way the normals are imported without being flipped.
Here’s the text of the .RIP importer:

https://pastebin.com/raw/JXAVmpPZ

And because I know someone will ask for it, this is the .RIP file which is intended to be used with the .MS script:

https://drive.google.com/open?id=1A8Tz3xbKzFUzxOG-5DfG0OLWajGGS3mk

@Klvnk I think you’re right about the vert order.
I think what the importer does, is it “keeps” vertices any time it can, that way it only loads 2 new vertices into memory if the current triangle shares a vertex with the previous one.
The side effect of this efficiency would be that the vertex order (ccw vs cw) would alternate for each adjacent triangle.

If we can force the .MS script to read all 3 vertices in the correct order for each new triangle, I think that will give us the result we want.

Not automatic, but if I import the test model as a Mesh (not Poly), with this little script it took me 5 seconds to fix the flipped faces.
Just click on Unify Normals and then select the flipped elements and flip those faces. Not sure if it will work with other models.


(
    try destroydialog ::RO_QUICK_NORMAL_FLIP catch()
    rollout RO_QUICK_NORMAL_FLIP "" width:152 height:104
    (
        button btn1 "Unify Normals" pos:[8,8] width:136 height:40
        button btn2 "Flip Faces" pos:[8,56] width:136 height:40
        
        on btn1 pressed do
        (
            max modify mode
            
            if iskindof $ editable_mesh do
            (
                meshop.unifynormals $ #all
                subobjectlevel = 5
                
                setfaceselection $ #{}
                
                xviewchecker.setactivecheckerid 5
                xviewchecker.on = true
            )
        )
        
        on btn2 pressed do
        (
            if iskindof $ editable_mesh do
            (
                meshop.flipNormals $ #selection
                setfaceselection $ #{}
            )
        )
        
    )
    createdialog RO_QUICK_NORMAL_FLIP
)

EDIT: Just checked the UV’s and they are a complete mess.

Yes the UV’s are a bit ugly because I didn’t touch them up. I believe that’s because of the perspective mutation that the models go through when they get rendered, and then I extracted after the mutation.

I see what you mean with the script, but it took me about the same amount of time to use Element and Flip Faces in your script as it would normally take using Flip Normals Mode for Edit Mesh.

I really think Klvnk is correct when he says the Vertex order is the core cause of the issue. If we can solve that mystery, I think the normals will be imported correctly, potentially saving many hours of normal flipping.

1 Reply
(@polytools3d)
Joined: 1 year ago

Posts: 0

Yes, pretty much the same, if you first do:

  • Import the model as mesh
  • Unify the normals
  • Turn on the XView Checker to quikly identify the flipped faces

But you previously said:
“Oh, and I forgot to mention earlier, but the “Unify” command in 3DS max doesn’t work in this case.”

Can you upload that model that took you near an hour to fix?

yeah, if you import the obj with normals from file checked then the normals are correct for a completely “faceted” model (so they are for all intents and purposes junk) and all the normals are then set to explicit (max will not recompute them) There is an issue with face vert orders so because normals are explicit Unify makes the model look odd. Uncheck normals from file on import (use auto) and then Unify will work correctly and as above I think the normal data is useless junk anyway, (looking at it with the editnormals mod)

DING DING DING! Looks like we’ve solved the mystery!

Even works with the more complex models! This is amazing, thank you so much!
I’m going to have to share this with some other rippers, because literally every tutorial for Ninja Ripper on youtube or otherwise just uses the Flip Normals Mode.

Oh, and PolyTools3D, Here’s one of the more complex models. This was actually ripped using 3D Ripper DX, so it doesn’t have the same pattern, but Klvnk’s method above works for this as well…

https://pastebin.com/raw/9zDCWSwS

3D Ripper DX may seem to be better than Ninja Ripper because it doesn’t mess up the UV’s, but it generally has lower compatibility because it’s not being updated any more. It can only do DirectX9 and earlier. Also, it doesn’t have the checker pattern with the UV’s.

I’ve got some really stubborn models now, which are refusing to Unify, even with the method we used for previous files.

Here’s the samples:
https://pastebin.com/raw/iVaKF401

Here’s a list of things I’ve tried: (none of them worked)
-Importing normals from file and Unifying
-Using Auto-normals and Unifying
-Welding vertices first, and then Unifying
-Welding vertices, exporting, importing with auto-normals, and then unifying

And, there’s no pattern in the normals like the previous files.
So I’ve really got NO idea if there’s any way to fix this one.

Page 1 / 2