It’s because you have to do individual raycast calls with Python?
Since most production meshes have a proxy version it’d be cool to have a feature with using the proxy for alignment, which would deform the actual production mesh (even if it’s a separate step). Faces can get quite heavy, an average human can easily be 100-150k for just the head.
yes, exactly, I wanted to implement my own BVH tree in cython or C++ but didn’t find tutorials or explanations on how it works, and the source codes I found in github are optimized to the point of unreadable (for my python programmer standards).
1 Like
yes, I want to do this I’m just trying to find a way to auto-generate this proxy mesh and preview the deformation in realtime.
I made a proposal for non grid unsubdivide - I know that it might not apply for every mesh, but a lot of time production topology can be unsubdivided. There are still some issues with checker de-select I think, but starting with 5 pole verts I think that could be a way to go.
1 Like
I’ve been playing with GL compute shaders. You can also use them in Blender quite easily if you install additional Python lib with PIP: https://gist.github.com/amb/80d598ca896326488992da258ca95dfe
Here’s a couple additional links on compute shaders and BVH:
https://www.scratchapixel.com/lessons/3d-basic-rendering/ray-tracing-rendering-a-triangle/moller-trumbore-ray-triangle-intersection
https://medium.com/@bromanz/how-to-create-awesome-accelerators-the-surface-area-heuristic-e14b5dec6160
2 Likes
I was trying to follow those tuts but realized that bounding volumes are more complicated than I can handle yet, I’ll take more time than I’d like to understand this subject.
I think I’m gonna stick with numpy, since the mesh moves smoothly, there might be a way to cache the last hit triangles in an array and re project them using numpy instead.
finally,i confirm. it is a cloth tool, lol 
It used to be, but now it uses unrealistic motion formulas and approximations to work faster
1 Like
nice tool ! its awesome to see something like wrap from r3ds inside blender, two questions, is it for 2.80? and have you seen the non rigid iterative closest point algorithms? I think wrap 3 uses that maybe you’ve seen it already and its not so easy to implement inside blender any way great work!!
The mix of rigid and non rigid ICPs is really powerful. I’ve seen this work in close to realtime with scans in the millions, in terms of polycount, and giving really clean results with production topology as well… Hao Li had a great paper on it quite a while ago (also, if you haven’t yet and have some time check out his other videos, the one on hair reconstruction is especially interesting) -
Yes
Not yet, I might have accidentally implemented something similar, but I am not sure.
Well, that might be possible in raw C but I am currently limited by python, I am trying to port my algorithm to cython but its being a pain to make the compiler work.
Something that I am confused about, regarding this tool, is the ready made mesh which is adapted on the sculpt mesh: is it not already a whole manual modeling task to create such a mesh for adapting it on a sculpt mesh? So what is the effort and time gain in comparison to go through a normal retopo route?
And do not misunderstand me, this is not a criticism, I just am asking for the sake of understanding.
1 Like
The advantage gained is that you can copy/paste pre-made topology and adapt on new models, essentially you’ll need got through a normal topo route at least once or download pre-made topologies.
1 Like
yes that’s the point, and with a known topology you can automate many things, let’s say hair grooming, auto rigging , auto fitting clothes, mass customizzation of orthotics and apparel, , the meshes can be already uv unwrapped, etc etc, its really valuable this tool, one really difficult but really good feature would be to have automatic correspondence poiints finding between meshes but thats computer vision and machine learning intensive , so it’s far from easy task, but its really interesting!!
1 Like
Thanks Jeacom! I imagined that it should be something so but wanted to be sure. 
I got the BVH construction to work in cython, I’m sure its not faster than blender’s kdop-based bvh but I’m hoping that getting rid of the python overhead will compensate for it.
2 Likes
I got the bvh to work and am already porting the engine to a faster cythion implementation.
Guys, I need your opinion.
I am almost finishing the Cython implementation of the engine and want to make so its interchangeable with the plain numpy version, but with following updates It might be hard to keep both implementations in sync.
The numpy engine file is only 215 lines of code while the cython implementation is 1099 lines of code and its not even finished, I can’t imagine myself maintaining both in sync flawlessly.
Would it be bad if I not keep the numpy version? it would mean that the addon would be compiled only for windows and maybe linux, I think mac users can try to compile it themselves but I cannot guarantee it will work.
1 Like
I don’t see a problem as long as there’s an option to download the last version with Numpy, if the Cython version doesn’t work for everybody.
I think @genics is right, now that I can run it on higher poly meshes, it really looks like cloth.
I swear it wasn’t my intention tho.
11 Likes