• Content Count

  • Joined

  • Last visited

About Ned

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi @jerome Thanks for your reply. I did compare the normal exported from Blender and the one derived by ComputeNormals All configs are the same but normals outcomes are slightly different. Maybe it's due to the differences between two algos. From your comments, I think the smoothness/normalization of normals is the key to this case? However I find it's pretty hard to insert the "average value" idea into the Normal Computing Process without manual works? Don't know how to define where artifacts take place. Is it possible to apply entirely normalization through the long array of normals or other approaches to solve it? Another question here, why the bad shading mesh part turns out regularly-trimesh behavior? (half light triangle + half dark triangle , repeated ... ) Thanks again and again for your great insights Ned
  2. Hi @JCPalmer Thanks for your great insight. Sorry I didn't explain it clear. I try to solve the ComputeNormals things because I thought shapekey morphing in TOB-output-js is done with helps of ComputeNormals function. Are there any ways to workaround? ( vertex deformation in correct material display without computing normals ) I follow the suggestions and do some experiments independently. (A) Separate Meshes and set them to parent mesh (B) Build all materials into one Sadly, I still face the normal-line condition. I referenced your great post reply in the past here, You said you faced some normal calculation problems and provide a good method, Do you think we can solve our case with other calculating methods? I also study the great post by @jerome which explains the algo in an excellent way I try some [options] inside the ComputeNormals . Still not work. But maybe there are some chances to make it but I fail with some misunderstanding myself. haha Hopefully shape key morphing could work well regardless of vertex/material group boundaries! Thanks for your expert advice again
  3. Hi @JCPalmer @Sebavan, Thank you for the great explanation. Really looking forward to the new version you are working on ! The demo you've shown seems to have the same issue. As you can see in my playground , the shapekey group is already removed, however is still having issue after doing ComputeNormals. So it is not caused by shapekey group, possibly material group or something else? In our condition, it's really sad that maybe .babylon exporter is not the suitable choice. Because our mesh is going to own plenty of keys and shape groups. Do you suggest any workarounds on this topic? Thank you again!
  4. Hi, I'm a newbie on BJS. Recently, I export the TOB js file from blender. When I use MeshFactory Class to import the mesh on BJS , Everything is alright. (pic1) When I start to apply the vertexDeform function in QueuedInterpolation.1.1.js , the morphing works well in positions However the texture turns out discontinuous effect. (pic2, triangle discontinuous dark shadow) It seems like something incorrect. Maybe normals or shadows or something else? After tracing the code in QI, I found that the compute normals is involved in vertexDeform related function So I try to cut down the problematic mesh part and remove the shape group in blender and export again, just wanna try if ComputeNormals could work well or not. But the new TOB js shows the same outcome. (Procedural is simple : (1) instance the mesh (2) Re ComputeNormals in BJS ) (a tiny clue : the fail area is just around the boundary of two different materials, don't know whether it's related) Call helps for the experts in this forum 1. What causes this issue? 2. Are there any recommended solutions to deal with this problem? (I'm afraid the vertexDeform/Morphing of Blender output mesh should always do the ComputeNormals function) The playground is as following ( Mesh.js without shape group. Just want to make sure the ComputeNormals works well or not)