can you use Interface::CurRendererRenderFrame and just create the objects before it’s called then delete after and repeat for all frames. or simila…
attaching as editable poly will preserve the specified normals but the underlying faces will still be flipped e.g the following planes2.jpg1276x790…
planes.jpg1276x790 20.8 KB the problem with specified normals is theres no way of replicating the plane on the left without them, Max will always s…
I don’t think so, not exactly, you could possibly change the underlying mesh to be more “correct” ie flipped. But Max always sets the object normals b…
it doesn’t it just restores the normals to match the face vert order… the explicit specified normals have been edited somewhere down the line to face …
without recourse to the SDK I don’t think so.
that’s the way the actual faces are arranged. the object has it’s normals specified in the other direction. Add an edit normals mod and reset the nor…
( fn GetScreenBounds obj = ( maxy = maxx = -99999999.0; miny = minx = 99999999.0; gw.setTransform(Matrix3 1); msh = snapshotasme…
if you’ve found the verts already don’t call the threshold routine use this DllExport void MeshDelta::WeldVertSet ( Mesh & m, BitArray vset, Poin…
you may well run into similar issues the the built in functiona have when it comes to getting a guaranteed same order
mapping is easy to fix same as the geometry, copy the specified normals to a map channel before the weld fix as above then restore from the map channe…
you could convert this too a c++ that works directly with poly delete objects global sp0, sp1, sp2, _m fn sort_verts sobj cobj = ( …
that doesn’t help… 4 possible solutions all equal in every sense a 64 sided sphere could have 64 solutions for top to bottom vert!
it can also have more than 1 correct solution depending on the mesh