Feature Request: Support Explicit Normals in Instanced Meshes

[wallworm]

I would like an option in the Mesh Builder > Instanced Geometry to turn on Explicit Normals. When on, the normals will be derived from explicit normals of the source meshes instead of the face normals. This would help game pipelines where the incoming meshes already have normals set explicitly to render better in game.

[wallworm]

Adding onto this thread, it would be nice if Instanced Geometry, Standard Leaves and Leaves Mesh had a some explicit normals options to project normals out from a few specific points:

 

• Out From Distributor Point (project from where this object spawns)
• Out From Parent Distributor Point (Project from the parent distributor spawn)
• Out from Oldest Distributor Point (Project out from deepest ancestor distributor point)

[Eduard]

Hi Shawn,

 

Yes of course, we'll try to add this feature. Now I'm still studying how to implement it.

Thanks!

[wallworm]

Awesome!

[artmonky]

Hi. Has there been any progress with this? Really need this feature for Game asset production.

[wallworm]

I'm just posting to see if there is any progress on this front?

[Eduard]

14 minutes ago, wallworm said:

I'm just posting to see if there is any progress on this front?

I just didn't find a detailed description of how to use it in MaxSDK. But we'll try to add it asap.

Thanks!

[wallworm]

Here is a snippet of code for setting the explicit normal of Mesh class mesh (I yanked this from one of my plugins, hopefully it makes sense even if out of context):

 

                // Normals
                mesh.SpecifyNormals();
                MeshNormalSpec *normalSpec = mesh.GetSpecifiedNormals();
                normalSpec->ClearNormals();
                normalSpec->SetNumNormals(numVerticies);
                normalSpec->SetNumFaces(numFaces);

//verts

                for (int vertID = 0; vertID < numVerticies; ++vertID)
                {

                        //here you would set verts, uvs

                        //now set normal

                        normalSpec->Normal(vertID) = Point3( normal, normaly, normalz);

                        normalSpec->SetNormalExplicit(vertID, true);

                }

 

                // Face indicies
                for (int i = 0, j = 0; i < numFaces; i++, j += 3)
                {
                   //set face verts, mapping, smoothing

                   //now assign 

                    MeshNormalFace &normalFace = normalSpec->Face(i);

                    normalFace.SpecifyAll(true);

 

                    //below n0,n1,n2 would be index of normals
                    normalFace.SetNormalID(0, n0);
                    normalFace.SetNormalID(1, n1);
                    normalFace.SetNormalID(2, n2);

 

                }

 

 

//near end before invalidating geom or top caches

                normalSpec->SetFlag(MESH_NORMAL_MODIFIER_SUPPORT);//Might be necessary to keep normals and edit them
                normalSpec->SetAllExplicit();

[Eduard]

23 minutes ago, wallworm said:

Here is a snippet of code for setting the explicit normal of Mesh class mesh (I yanked this from one of my plugins, hopefully it makes sense even if out of context):

Oh, thanks a lot!

 

I guessed that we need to use the MeshNormalFace class.
As I understand, here you create Specified Normals from scratch, but I need to get them from an existing Instanced object.
I'll try to use GetSpecifiedNormals(); maybe this will be enough...

[Eduard]

Hi Shawn,

 

Just experimenting with normals, I noticed that everything works fine if you turn off the Combine meshes, because in this case the mesh of each object is displayed in the viewport as it is:

 

 

 

 

But if you turn on the Combine meshes, then the IG objects are displayed incorrectly. As I understood this is a problem that needs to be solved.

 

 

So now you can try to turn off the Combine meshes...

 

Thanks!

[wallworm]

That's awesome Eduard. I wish I had discovered this in my tests over the last two years!

 

Note, it would be ideal if work on this includes some of the options in post #2 above for standard leaves and leaves meshes. Being able to make game-friendly normals especially for the low poly standard leaves would be a godsend. I would even add a couple new options than in list above:

• Out From Mesh Center
• Out From Element Centers.

[Eduard]

13 minutes ago, wallworm said:

Note, it would be ideal if work on this includes some of the options in post #2 above for standard leaves and leaves meshes. Being able to make game-friendly normals especially for the low poly standard leaves would be a godsend. I would even add a couple new options than in list above:

• Out From Mesh Center
• Out From Element Centers.

 

Maybe add this in version 2.0? There we can implement a separate node (eg. Change Normals) that can be connected to any mesh node, even Cylinder for example

[Eduard]

Hi Shawn,

 

Finally, it seems works fine with Combine meshes:

 

 

 

 

Need to test more. I can send you an update...

Thanks again for your tip!

[wallworm]

Brilliant! I want my hands on it the second it's ready!

[Eduard]

Hi Shawn,

 

I sent you an update by email.

Thanks!

[wallworm]

Eduard,

 

Thank you so much for looking into this!

 

I tested the new version and have a few items to suggest.

 

• I noticed that the function only works if the source geometry has an edit normals modifier. This is an OK assumption but there are certain geometry types that are always explicit normals and perhaps they should not require the modifier. One important to me is WallWormMDL geometry class ( class id of #(0x4e8b048c, 0x732e564d) ). Others that might also want to be automatically using this is Linked FBX geometry. There are probably others. This is just a convenience idea.
• I noticed that the normals always point toward the original direction of the source normals in the world. In other words, they do not change orientation with the geometry as the objects are transformed from the distributors or morphed by modifiers. This leads to unexpected lighting. This issue is very important to address.

I think that the second item might be computationally expensive but it is certainly necessary to get the results desired.

[wallworm]

Eduard,

 

I see that in your screenshot above the normals do seem to follow the transforms. I will have to see what might be different in my scene. 

[Eduard]

Hi Shawn,

 

I just check that the normals exist in the mesh like this:

MeshNormalSpec* normalSpec = mesh->GetSpecifiedNormals();
if (normalSpec && normalSpec->GetFlag(MESH_NORMAL_NORMALS_BUILT)) {
	// use the normals data
	...
}

Can you please advise how best to check this data?

Thanks!

[wallworm]

Yeah, that's probably correct. I noticed it doesn't detect this class. I think it may be that they are scripted geometry objects. The meshes are actually generated with the SDK but then used in the buildmesh of the scripted class (this is more convenient for my needs as developing UI and scripted functions is so much easier/quick in MAXScript).