The test result is not as good as expect on my OBJ file

[oneshotyj]

I use Instant Mesh to remesh obj file downto 5K and tested with the quick_start.py, looks not as good as your example , I do not know if it's because the bandwidth, threshold parameters not set correctly? Do we need to use diffrent parameters for diffrent 3D models?

[zhan-xu]

could you send the model to me? zhanxu@cs.umass.edu
seems to me your model is not centered or normallized. i will try on my side.

Update: I have added the normalization in the quick_start.py. Could you try? Just use the default parameters (bandwidth=None, threshold=1e-5). Still, it would be interesting if I can also try your model on my side.Thanks.

[oneshotyj]

Thanks for your quick response . It's fixed by your new code and I have sent the model files to you , too.

[oneshotyj]

sorry , just found run out of memory issue to move forward by your new code and here is log.
( Configuration of my laptop is 16GB DRAM + GTX1060 6GB +Win10 )

loading all networks...
joint prediction network loaded.
root prediction network loaded.
connection prediction network loaded.
skinning prediction network loaded.
creating data for model ID 2222
gathering topological edges.
calculating surface geodesic matrix.
surface geodesic calculation: 10.093571186065674 seconds
gathering geodesic edges.
predicting joints
predicting connectivity
predicting skinning
calculating volumetric geodesic distance from vertices to bone. This step takes some time...
Traceback (most recent call last):
File "quick_start.py", line 422, in
mesh_filename.replace("_remesh.obj", "_normalized.obj"))
File "quick_start.py", line 265, in predict_skinning
geo_dist = calc_geodesic_matrix(bones, mesh_v, surface_geodesic, mesh_filename)
File "quick_start.py", line 220, in calc_geodesic_matrix
pts_bone_visibility = calc_pts2bone_visible_mat(mesh_trimesh, origins, ends)
File "F:\AI-PHOTO\RigNet\geometric_proc\compute_volumetric_geodesic.py", line 64, in calc_pts2bone_visible_mat
locations, index_ray, index_tri = RayMeshIntersector.intersects_location(origins, ray_dir + 1e-15)
File "D:\ANCD3\envs\py37torch13\lib\site-packages\trimesh\ray\ray_triangle.py", line 107, in intersects_location
**kwargs)
File "D:\ANCD3\envs\py37torch13\lib\site-packages\trimesh\ray\ray_triangle.py", line 66, in intersects_id
triangles_normal=self.mesh.face_normals)
File "D:\ANCD3\envs\py37torch13\lib\site-packages\trimesh\ray\ray_triangle.py", line 227, in ray_triangle_id
line_directions=line_directions)
File "D:\ANCD3\envs\py37torch13\lib\site-packages\trimesh\intersections.py", line 385, in planes_lines
projection_ori = util.diagonal_dot(origin_vectors, plane_normals)
File "D:\ANCD3\envs\py37torch13\lib\site-packages\trimesh\util.py", line 638, in diagonal_dot
return np.dot(a * b, [1.0] * a.shape[1])
MemoryError: Unable to allocate array with shape (100365736, 3) and data type float64

[zhan-xu]

Yeah, the calculation of ray-surface intersection cost much time and memory and should be optimized somehow.. For now I suggest you further decimate the mesh with fewer faces (the intersection is calculated in ray-triangle pairs). btw, I haven't got your model. Maybe I can take a look at the face and vertex number of it?

[zhan-xu]

Hi, thanks for sending me your model for debugging. I just updated the code. On line 280 of quick_start.py, now "calc_geodesic_matrix" takes an extra parameter "subsampling". By default it is False. If you set it as True, the function will subsample the vertices of the model, calculate intersections, and then upsample the results back to original vertices. As I tested, now it takes at most 9-10 G memory.

There is one more problem with your model. The original mesh has multiple groups, which make the skinning transfer from the remeshed model to the original model incorrect. Currently the algorithm only supports models with a single geometry group. A more robust OBJ parser, as well as rig format are needed to support skinning transfer to models with multiple geometry groups. I will update the code if I have time to figure this out.

[oneshotyj]

The out of memory issue be fixed after set subsampling to True.Hope you can fix the multiple geometry groups issue someday when you have time , thanks.

[potie1013]

Hello,I reused the 17872.obj,and the output 17872.fbx‘s performance was basically in line with reality,then I reused the 13.obj which you provided as input, and the output 13.fbx file just include three joints,also I tried 4270.obj 4347.obj 4518.obj,All of the output .fbx files were more or less problematic in the calculation of joint points and weights,Is there something wrong?

[zhan-xu]

did you try other provided examples in the quick_start folder? Does it only work for 17872, or basically work for all provided examples, but not other test models?

[potie1013]

Thank you for your reply,I tried smith 15930 15446 14510 14501 17882 11814 4347 4518 4347 in the quick_start folder,except for 14501 4518 4347 ,the other results are pretty good,the output 14501.fbx file has a bad skeleton, 4518.fbx has a problem that the left and right leg joints infuence each other's weights,in 4347.fbx the weight of the model'head is not controlled by the head joints. Then I tried 13 in the ModelResource_RigNetv1_preproccessed\obj_remesh folder, the output also has a bad skeleton.

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "zhan-xu/RigNet" <notifications@github.com&gt;; 发送时间:&nbsp;2020年11月30日(星期一) 中午12:29 收件人:&nbsp;"zhan-xu/RigNet"<RigNet@noreply.github.com&gt;; 抄送:&nbsp;"周亚敏"<591283291@qq.com&gt;;"Comment"<comment@noreply.github.com&gt;; 主题:&nbsp;Re: [zhan-xu/RigNet] The test result is not as good as expect on my OBJ file (#9) did you try other provided examples in the quick_start folder? Does it only work for 17872, or basically work for all provided examples? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[potie1013]

Sorry for making you confused. 14510 14501 17882 4347 4518 were originally in the&nbsp;ModelResource_RigNetv1_preproccessed\obj_remesh&nbsp;folder. I moved them to the&nbsp;quick_start folder when I tested them.

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "zhan-xu/RigNet" <notifications@github.com&gt;; 发送时间:&nbsp;2020年11月30日(星期一) 中午12:29 收件人:&nbsp;"zhan-xu/RigNet"<RigNet@noreply.github.com&gt;; 抄送:&nbsp;"周亚敏"<591283291@qq.com&gt;;"Comment"<comment@noreply.github.com&gt;; 主题:&nbsp;Re: [zhan-xu/RigNet] The test result is not as good as expect on my OBJ file (#9) did you try other provided examples in the quick_start folder? Does it only work for 17872, or basically work for all provided examples? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[zhan-xu]

I see. You can set bandwidth to None and threshold to 1e-5, which are the default parameters. However it doesn't guarantee to work for every test model. One way is to tune the bandwidth and threshold for each test model, but it will require some manual work. Also, due to randomness, different runs sometimes get slightly different results.

[potie1013]

OK,I understand, thanks for your reply

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "zhan-xu/RigNet" <notifications@github.com&gt;; 发送时间:&nbsp;2020年12月1日(星期二) 凌晨3:09 收件人:&nbsp;"zhan-xu/RigNet"<RigNet@noreply.github.com&gt;; 抄送:&nbsp;"周亚敏"<591283291@qq.com&gt;;"Comment"<comment@noreply.github.com&gt;; 主题:&nbsp;Re: [zhan-xu/RigNet] The test result is not as good as expect on my OBJ file (#9) I see. You can set bandwidth to None and threshold to 1e-5, which are the default parameters. However it doesn't guarantee to work for every test model. Once way is to tune the bandwidth and threshold for each test model, but it will require some manual work. Also, due to randomness, different runs sometimes get slightly different results. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[ibtehajali67]

can you please tell me how you generate *_rig.txt file for own model

[zhan-xu]

Hi the way to get *-rig.txt from .fbx or .dae is bit dirty. You can refer to #38 (comment)

We use a mix of different ways to parse original data, where maya seems more reliable. But you need some scripting to deal with mesh with multiple geometry group.