topic Re: MNMesh ComputeRenderNormal gives Access Violation in 3ds Max Programming Forum

MNMesh ComputeRenderNormal gives Access Violation

duncan_rowland — Thu, 01 Aug 2024 09:55:21 GMT

Hi,
I having trouble computing render normals on an MNMesh.

For example:

   If I make a 1x1 plane (i.e. 1 face, 2 tris), convert it to an Editable Poly, and run the following,
   the DebugPrint looks ok to me (below), but I get an access violation,
   (and other, more complex polys are similar).

Strangely, if I zoom the viewport in and out before running the script, no violation...

Many thanks in advance, -Duncan.

def_visible_primitive(ComputeRenderNormal, "ComputeRenderNormal");
...

INode* node = static_cast<MAXNode*>(arg_list[0])->to_node();
const ObjectState* object_state = &node->EvalWorldState(MAXScript_time());
Object* object = object_state->obj;
PolyObject* poly_object = dynamic_cast<PolyObject*>(object);
MNMesh* mnmesh = &poly_object->GetMesh();
mnmesh->CheckAllData();
mnmesh->MNDebugPrint();
mnmesh->ComputeRenderNormal(0,0); <-- Access Violation 😞

MNMesh Debug Output: 4 verts, 4 edges, 1 faces
2024/08/01 10:26:20 [19564] : 68656ms : Vertex 0:
2024/08/01 10:26:20 [19564] : 68657ms : ( -23.065, -21.422, 0.000)
2024/08/01 10:26:20 [19564] : 68657ms : Edges: (
2024/08/01 10:26:20 [19564] : 68657ms : 0
2024/08/01 10:26:20 [19564] : 68657ms : 3
2024/08/01 10:26:20 [19564] : 68657ms : )
2024/08/01 10:26:20 [19564] : 68657ms : Faces: (
2024/08/01 10:26:20 [19564] : 68657ms : 0
2024/08/01 10:26:20 [19564] : 68657ms : )
2024/08/01 10:26:20 [19564] : 68658ms :
2024/08/01 10:26:20 [19564] : 68658ms : Vertex 1:
2024/08/01 10:26:20 [19564] : 68658ms : ( 23.065, -21.422, 0.000)
2024/08/01 10:26:20 [19564] : 68658ms : Edges: (
2024/08/01 10:26:20 [19564] : 68658ms : 2
2024/08/01 10:26:20 [19564] : 68658ms : 3
2024/08/01 10:26:20 [19564] : 68658ms : )
2024/08/01 10:26:20 [19564] : 68658ms : Faces: (
2024/08/01 10:26:20 [19564] : 68658ms : 0
2024/08/01 10:26:20 [19564] : 68659ms : )
2024/08/01 10:26:20 [19564] : 68659ms :
2024/08/01 10:26:20 [19564] : 68659ms : Vertex 2:
2024/08/01 10:26:20 [19564] : 68659ms : ( -23.065, 21.422, 0.000)
2024/08/01 10:26:20 [19564] : 68659ms : Edges: (
2024/08/01 10:26:20 [19564] : 68659ms : 0
2024/08/01 10:26:20 [19564] : 68659ms : 1
2024/08/01 10:26:20 [19564] : 68659ms : )
2024/08/01 10:26:20 [19564] : 68659ms : Faces: (
2024/08/01 10:26:20 [19564] : 68659ms : 0
2024/08/01 10:26:20 [19564] : 68660ms : )
2024/08/01 10:26:20 [19564] : 68660ms :
2024/08/01 10:26:20 [19564] : 68660ms : Vertex 3:
2024/08/01 10:26:20 [19564] : 68660ms : ( 23.065, 21.422, 0.000)
2024/08/01 10:26:20 [19564] : 68660ms : Edges: (
2024/08/01 10:26:20 [19564] : 68660ms : 1
2024/08/01 10:26:20 [19564] : 68660ms : 2
2024/08/01 10:26:20 [19564] : 68660ms : )
2024/08/01 10:26:20 [19564] : 68660ms : Faces: (
2024/08/01 10:26:20 [19564] : 68660ms : 0
2024/08/01 10:26:20 [19564] : 68661ms : )
2024/08/01 10:26:20 [19564] : 68661ms :
2024/08/01 10:26:20 [19564] : 68661ms : Edge 0:
2024/08/01 10:26:20 [19564] : 68661ms : verts (2 0), face 0
2024/08/01 10:26:20 [19564] : 68661ms :
2024/08/01 10:26:20 [19564] : 68661ms : Edge 1:
2024/08/01 10:26:20 [19564] : 68661ms : verts (3 2), face 0
2024/08/01 10:26:20 [19564] : 68661ms :
2024/08/01 10:26:20 [19564] : 68661ms : Edge 2:
2024/08/01 10:26:20 [19564] : 68661ms : verts (1 3), face 0
2024/08/01 10:26:20 [19564] : 68662ms :
2024/08/01 10:26:20 [19564] : 68662ms : Edge 3:
2024/08/01 10:26:20 [19564] : 68662ms : verts (0 1), face 0
2024/08/01 10:26:20 [19564] : 68662ms :
2024/08/01 10:26:20 [19564] : 68662ms : Face 0:
2024/08/01 10:26:20 [19564] : 68662ms : verts (
2024/08/01 10:26:20 [19564] : 68662ms : 2
2024/08/01 10:26:20 [19564] : 68662ms : 0
2024/08/01 10:26:20 [19564] : 68662ms : 1
2024/08/01 10:26:20 [19564] : 68662ms : 3
2024/08/01 10:26:20 [19564] : 68662ms : ) edges (
2024/08/01 10:26:20 [19564] : 68663ms : 0v
2024/08/01 10:26:20 [19564] : 68663ms : 3v
2024/08/01 10:26:20 [19564] : 68663ms : 2v
2024/08/01 10:26:20 [19564] : 68663ms : 1v
2024/08/01 10:26:20 [19564] : 68663ms : )
2024/08/01 10:26:20 [19564] : 68663ms : Map 1:
2024/08/01 10:26:20 [19564] : 68663ms : MNMap Debug Output: 4 verts, 1 faces
2024/08/01 10:26:20 [19564] : 68663ms : UVVert 0: 0.000000, 0.000000, 0.000000
2024/08/01 10:26:20 [19564] : 68663ms : UVVert 1: 1.000000, 0.000000, 0.000000
2024/08/01 10:26:20 [19564] : 68663ms : UVVert 2: 0.000000, 1.000000, 0.000000
2024/08/01 10:26:20 [19564] : 68663ms : UVVert 3: 1.000000, 1.000000, 0.000000
2024/08/01 10:26:20 [19564] : 68663ms : Face 0:
2024/08/01 10:26:20 [19564] : 68664ms : 2
2024/08/01 10:26:20 [19564] : 68664ms : 0
2024/08/01 10:26:20 [19564] : 68664ms : 1
2024/08/01 10:26:20 [19564] : 68664ms : 3
2024/08/01 10:26:20 [19564] : 68664ms :
2024/08/01 10:26:20 [19564] : 68664ms :
2024/08/01 10:26:20 [19564] : 68664ms :
Exception thrown at 0x00007FFCE5DD64DB (MNMath.dll) in 3dsmax.exe: 0xC0000005: Access violation reading location 0x0000000000000008.

Re: MNMesh ComputeRenderNormal gives Access Violation

denisT.MaxDoctor — Thu, 01 Aug 2024 17:02:42 GMT

I recall some problems with ComputeRenderNormal, but I've always wanted all normals, so I use buildRenderNormals...

I am sure ComputeRenderNormal also works, but you need to invalidate something in the MNMesh as usual 🙂.

Re: MNMesh ComputeRenderNormal gives Access Violation

denisT.MaxDoctor — Thu, 01 Aug 2024 18:40:49 GMT

I could be wrong, but as I can guess the ComputeRenderNormal was designed for "manual" (soft) rendering. This method has been out of use for a long time and you can't find it in the SDK examples now. Its functioning is related to GraphicsWindow, and in the modern world, it implies some form of caching. You need to force the node containing the MNMesh to cache something, which is what happens when you zoom a viewport.

Re: MNMesh ComputeRenderNormal gives Access Violation

denisT.MaxDoctor — Thu, 01 Aug 2024 18:47:34 GMT

Also, ComputeRenderNormal implies that you are working with triangular faces, which can cause more headaches at the polygon level. In general, I advise working with built render vertex normals or using the Mesh instead.

Re: MNMesh ComputeRenderNormal gives Access Violation

duncan_rowland — Fri, 02 Aug 2024 12:23:02 GMT

Thank you for replying,
I'm working with a PolyObject (a TriObject works fine). The PolyObject works when I zoom in-and-out so it does seem to have cached what it needs like you say.

For reference, buildRenderNormals also causes a similar violation unless I call buildNormals first.

If it's a case of causing the cached data to be generated, is there a ref you can post on how I'd add that to my code?
Thanks again, -Duncan.

INode* node = static_cast<MAXNode*>(arg_list[0])->to_node();
const ObjectState* object_state = &node->EvalWorldState(MAXScript_time());
Object* object = object_state->obj;
PolyObject* poly_object = dynamic_cast<PolyObject*>(object);
MNMesh* mnmesh = &poly_object->GetMesh();
mnmesh->ComputeRenderNormal(0,0);

Re: MNMesh ComputeRenderNormal gives Access Violation

klvnk — Fri, 02 Aug 2024 13:14:34 GMT

have you tried the Editable Mesh version ? e.g. does it also throw an exception ?

Re: MNMesh ComputeRenderNormal gives Access Violation

duncan_rowland — Fri, 02 Aug 2024 14:06:52 GMT

Yes, exactly, the "mesh" version works fine when passed an Editable Mesh:

INode* node = static_cast<MAXNode*>(arg_list[0])->to_node(); const ObjectState* object_state = &node->EvalWorldState(MAXScript_time()); Object* object = object_state->obj; TriObject* tri_object = dynamic_cast<TriObject*>(object); //<--Changed to TriObject Mesh* mesh = &tri_object->GetMesh(); //<--Changed to Mesh mesh->ComputeRenderNormal(0, 0);

The "poly" version causes an access violation when passed an Editable Poly
(unless you "zoom in-and-out a bit" first).

INode* node = static_cast<MAXNode*>(arg_list[0])->to_node(); const ObjectState* object_state = &node->EvalWorldState(MAXScript_time()); Object* object = object_state->obj; PolyObject* poly_object = dynamic_cast<PolyObject*>(object); //<--Changed to PolyObject MNMesh* mnmesh = &poly_object->GetMesh(); //<--Changed to MNMesh mnmesh->ComputeRenderNormal(0, 0); //<-- Access Violation Here

Re: MNMesh ComputeRenderNormal gives Access Violation

klvnk — Fri, 02 Aug 2024 23:00:48 GMT

have you tried calling mnmesh->CheckNormals(TRUE) before the call to ComputeRenderNormal ?

Re: MNMesh ComputeRenderNormal gives Access Violation

denisT.MaxDoctor — Fri, 02 Aug 2024 23:51:50 GMT

I did ... 🙂 doesn't help

Re: MNMesh ComputeRenderNormal gives Access Violation

duncan_rowland — Mon, 05 Aug 2024 11:02:26 GMT

Thanks for the help. For interest, I have some further information that may help.

If I make the normals explicit, then the poly code works.

e.g.

Make a Plane

Convert to Editable Poly

Add Edit Normals modifier

Select All Normals

Make Explicit

If I then either select and pass the modifier, or collapse and pass the object to the function, all works.

Re: MNMesh ComputeRenderNormal gives Access Violation

duncan_rowland — Mon, 05 Aug 2024 16:55:32 GMT

An update on making the normals explicit. I now suspect this isn't actually the problem, it's just that the Edit Normals modifier is causing a 'redraw' (i.e. cacheing whatever is needed like zooming in-and-out).

Re: MNMesh ComputeRenderNormal gives Access Violation

denisT.MaxDoctor — Mon, 05 Aug 2024 18:27:13 GMT

@duncan_rowland wrote:
An update on making the normals explicit. I now suspect this isn't actually the problem, it's just that the Edit Normals modifier is causing a 'redraw' (i.e. cacheing whatever is needed like zooming in-and-out).

that's more likely...

however, I am still puzzled and want to find a #software solution to cache/allocate/init poly render normals like #zoom does.

Re: MNMesh ComputeRenderNormal gives Access Violation

duncan_rowland — Tue, 06 Aug 2024 06:57:58 GMT

Yes, I don't have a method that works 100% of the time, some programatic solution is needed. If you find one, do let me know! :0)
What I'm actually trying to do is check the polys for inverted normals. i.e. compare each normal with its associated face and check they're more or less in the same direction. I have a maxscript that does this, but it's very slow for high polys. If these's a better way to get these vertex normals I'm all ears!

Thanks again, -Duncan.

Re: MNMesh ComputeRenderNormal gives Access Violation

denisT.MaxDoctor — Tue, 06 Aug 2024 15:40:36 GMT

@duncan_rowland wrote:

What I'm actually trying to do is check the polys for inverted normals. i.e. compare each normal with its associated face and check they're more or less in the same direction.

Take a look at MeshDelta::PropagateFacing (meshdelta.h)

Re: MNMesh ComputeRenderNormal gives Access Violation

klvnk — Thu, 15 Aug 2024 10:25:57 GMT

why do you specifically need to use ComputeRenderNormal for this ?

can't you use something like....

MNNormalSpec* mnspecnormals = mesh->GetSpecifiedNormals(); if(mnspecnormals) { // use MNNormalSpec functionality to get the face normals // .... } else { for(int f=0; f < numfaces;++f) { Point3 fnormal = mesh->GetFaceNormal(f, TRUE); //..... } }

Re: MNMesh ComputeRenderNormal gives Access Violation

denisT.MaxDoctor — Thu, 15 Aug 2024 19:07:40 GMT

@klvnk wrote:
why do you specifically need to use ComputeRenderNormal for this ?

The "computed render normals", as I see it, are not "specified". A special buffer is used for them, and they should be updated whenever you change the geometry/topology (instead of the specified normals, which you have to rebuild yourself).
If you only want to use some specific normals (faces), computed normals can be much faster. The only problem is that there is no official way to force them to be updated.

Re: MNMesh ComputeRenderNormal gives Access Violation

klvnk — Fri, 16 Aug 2024 15:26:25 GMT

The only problem is that there is no official way to force them to be updated.

forcing the update will cost the same time as computing them yourself, you can maintain your own buffer if need be and force your own update on what ever criteria that suits it's how most modifiers handle this kind of stuff using the NotifyInputChanged function

@klvnk - this post has been edited due to Community Rules & Etiquette violation.

Re: MNMesh ComputeRenderNormal gives Access Violation

denisT.MaxDoctor — Fri, 16 Aug 2024 04:08:27 GMT

It’s not the same as manually update normals. It seems like these computed normals need only allocated memory. What normals should be recomputed are specified by user.