New Data Transfer tool - Call for good .blend test files

Hey everybody,

As some of you may already know, I’ve been working quite hard since two months on a tool to transfer data between meshes - without any requirement about sharing same topology or so, of course.

The tool is now in active review stage (thanks Campbell, btw :wink: ), and we’d need some good testing files for it too, that is:

  • Files that are reasonably simple (we do not want a whole complex full-featured scene, but rather two or a few more meshes, sources and destinations).
  • Files that reflect real-life situations, workflows. Simple tests with cube and Suzanne we can do ourselves, but they do not reflect real usecases.

Currently, you can transfer pretty much every mesh data (vertex groups, vertex colors, UVs, among the most important ones), except shape keys, which have been kept for later.

Any contribution will be greatly appreciated! :smiley:

PS: I did some first testbuilds a few days ago, but code has already changed quite a bit since then, so take them as-is (, see also ).

Here is a blend.

Hi mont29,
The Data transfer build that i got from here is giving me empty ui so just windows without letter. I will be happy to help if i have a working build :wink:

@3d solar etc. Thanks, though there’s not much data to transfer here… :wink:

@erickBlender sounds strange… Anyway, just updated the builds (same link,, please give it another try! Checked these, they work fine for me (and are built same a release ones, so expected to be ‘universal’).

Moved from Beginning Blender Code and Development, since this is a request to artists about a feature which is of general interest (requested many times), and not so much about beginning development :slight_smile:

mont29, sent you a PM. I’ll give the datatransfer build a go.

OrAngE thanks a bunch! Nice but heavy model, though, takes time to compute here (shows we’ll likely have to multi-thread that too :confused: ).

Anyway, ‘Nearest interpolated’ method (for face corners) is expected to give best results here. This showed an issue though - faces that map onto seams splitting a same island (i.e. where neighbor faces get on opposite side in UVMap) get ‘streched’ UVs accros the whole map. Will have to check for a nice solution to this, does not seems trivial…

UVs are the worst data to transfer (because of those islands, precisely)! :wink:

Well, that’s one of the real life situations the tool might be useful for. It’d be great if you guys could multi-thread it!!! I was checking my CPU usage while I was testing it and noticed the CPU usage.

On that note, considering it’s quite a heavy mesh, I didn’t experience anything crazy in terms of waiting for the tool to do it’s thing. The only setting that was considerably slower to compute is: Ray Radius. Depending on some of the other settings, it could take several minutes to compute on i7-2600 @3.4GHz. As mentioned, everything else was reasonable, in the range of 8-20ish sec.

I was just about to post my results from playing with it, when I saw your reply.

Here are some of the results I was getting while testing out the tool.

For the test I used 2 meshes. A HiRez Dyntopo sculpt without UVz used as the Target, and a decimated LoRez unwrapped mesh used as the source.

This first screenshot is the LoRez mesh showing the UVz that I will try to transfer to the Dyntopo sculpt

With my brief test, this is the mode that produced the closest match to the Source.
As you have mentioned, for this case, it was Face Corner Mapping: Nearest Face Interpolated that was the most important setting. Again, as you mentioned, there is still some issues on the seams. I’m hoping you can tackle it somehow. I’ll be glad to help with testing, or suggestions. Feel free to contact me.

Here are some of the other results:

The “Face Corner Mapping” was the main setting from what I figured. and the screenshots show all the different results.
In my tests I did not catch any noticeable difference on the “Face Mapping” options (obviously the “Topology” would not apply here).
With this specific test I did not notice any difference when using Ray Radius (sometimes I would even hang when tweaking it). Same with “Object Transform” and “Only Neighbor Geometry”

Thanks on tackling this tool! Much appreciated!

I have to ask… in 2014, why not just assume that things should be multi-threaded where possible? I know it’s more work, but I doubt there are many serious users who would need a feature like this still sitting on a single core processor.

I have some models I used to test GATOR for SoftImage back in the day, I’ll see if I can dig them up and get them cleaned up for Blender to test with this as well.

I thought I’d just through in a couple of screenshotz. Although that is pretty much what you stated.

Here’s a screenshot of the Transfered UVz:

These are the islands that transfered with an error:

Taking a look at the Source mesh (the decimated mesh that was used to transfer the UVz), we can see where the problem is. Any island that wraps around a mesh and needs a seam to split it. In this case going down the center (X=0) line did not transfer.

In addition here is the model from the front, there’s no seams on the center. All those islands transfered well.

No, you do not want to multithread everywhere it’s possible. In many case, you’ll only gain a level of complexity in code, with no performance boost at all (can even become worse). Further more, there is one thing you do not want to do ever, it’s multi-threading a code that has not yet been tested thoroughly. Especially when the code is fairly involved, with thousands of lines, and many parameters which can lead to tons of different behaviors…

That said, yes, it will be threadified (it’s not really complicated, btw) - once it is ready. :slight_smile:

@OrAngE Yep, that’s exactly the issue I found while testing your file… I’ll call it the ‘Tube case’ (because it’s usual way of unwrapping a tube…). Have one or two ideas, but that’ll make the code here even more complex.

Anyway, regarding mapping methods, yes, nearest interpolated is logically the best choice here, since both source and destination have the same shape and size. Raycast should work pretty well too, provided you give a bit (0.001 or so) of rayradius (issues with raycasting and islands are not yet 100% resolved). Other modes should be more useful when transferring from highres to lowres (not on precision of result, but on speed of computation).

And face transfer in UVs case only affect texture indices affected to each face in a given UVmap.

Hi mont29,

I just wanted to show what i m getting when running the latest data transfer tool testbuild. i m on win 8

I should have said “where possible, and where advantages are already proven”. Systems like GATOR and the transfer tools in Maya have been fully featured and threaded for years now. It shouldn’t come as a surprise that it will need to be threaded for heavy meshes in Blender as well. But I agree, get everything working and then thread is the way to go.

No luck finding the GATOR test files. May have lost them in a hard drive crash, but I’ll keep digging.

@erickBlender Hrrrm… Can you please start Blender from a command line, and paste here everything that gets printed in that command line?

That kind of bug usually happens when there is an error in py scripts handling UI, but it’s strange it does not show up in linux build. :confused:

@m9105826, its not such a big deal to make this threaded AFAICS, but better first do basic user testing.

Here is the log copy from cmd

@erickBlender Well well well… Have to say I have no clue here, unless maybe there is some kind of mismatch/interference with pyscripts from some other Blender installation… But that’s not expected at all.

Will try to find some time tomorrow and try the build on my win VM, but if other people around could confirm that issue or not on Windows, would help too. :slight_smile:

I’m on Win7 64, no problems here.

Evening guys, quick word to say I updated builds on; new builds should fix (most of) nasty issues with UVs islands as raised by @OrAngE.