do the jme3 have some util can auto calculate my mesh Normal?
This may help.
For complete meshes:
I might be wrong, but I guess this does not generate normals. AFAIK it’s for generation tangents using the mesh normals.
And note, for anything other than flat shaded, there is not a 100% accurate-in-every-case way to automatically compute normals.
@mitm I noticed in Terminology wiki there are missing descriptions for PBR textures like metalness and roughness.
Normals usually come from the Editor, specifically their direction could be inverted when auto computing
Something like this?
Yes, but not if you do voxel/iso mesh. or any other auto-generated meshes.
and i belive he do something like auto-generated mesh.
Then the math generating the mesh already knows the normals.
Based on your response + Darkchaos response = you say that this topic is wrong, because he dont need calculate normals because in all cases he already have them. (where i dont agree, because his math could not calculate them trully so he ask for some math)
and i think its directly related to screenshot you see in:
If a mesh is being generated then the math generating the mesh already knows the normals… it must by definition. At any rate, it will know it way better than any triangle based approach.
For example, block worlds = normal is an axis vector based on the quad being emitted. Anything else is 100x more work.
For terrain height maps = normal is the gradient… vector orthogonal to the first derivative, basically. Calculating by triangle will probably be wrong as you need to sample at least four neighbors, 8 if you want to be thorough.
Generating from an isosurface, the normal is the direction vector of the field.
…and so on… and so on…
Only when flat shading each triangle would the mesh math be irrelevant. And then JME already provides a function for that.
MyMesh class in the Heart Library (available free from the Software Store) includes 3 public methods to calculate mesh normals:
addSphereNormals()for normals that point outward from the mesh origin
generateNormals()for per-triangle normals (facets)
smoothNormals()to smooth per-triangle normals into per-vertex normals
I agree with @pspeed. In the past, for heightMaps/waterSurfaces, I have successfully applied central finite difference calculations to get the normals, performed alongside the math that calculates the vertex positions.
However, I do not believe that normals are the culprit responsible for the issue raised in the OP’s other post on simpleWater transparency. AFAIK, simpleWater uses a simple quad mesh/geometry which already has proper normals provided. There, aside from the fog/transparency issue, the reflection looks like it is being rendered correctly. Whereas if the normals were incorrect, you would likely see different artifacts across the entire quad (quite a familiar artifact for me ).
Any errors or suggestions let me know.
oh, didint seen.
anyway i mean look at:
Its misleading there are general texture information, while PBR is in different TAB like.
but its ok, i just didnt seen it.
Just added it.
The way topic nesting is used here for the headings may be what you refer to when saying different tab like?
This is a side effect of how things are formatted for the side bar navigation. Menu items can only be three deep and they are based off topic heading size. i.e h1 to h3 will nest in the sidebar navigation but h4 + will not show. I will see what using a list or maybe just plain text the sub headings does to break this up.
Is this better?
PBR is a sub topic still because it needs to be. The information about it is described elsewhere via the links.
idk if there is some special cache, but i dont see changes if you made some. under [#materials-textures] there are no pbr.
but like i said, its ok. it was just me who didnt seen it in different Tab.