I remember seeing a thread where someone posted a WIP UV packing method using physics. Anyone know where that is?
You mean Gravity Packer?
Damnit - I sporadically rememberd that this was going to be implemented but the project seems to be dead by now, isn’t it?
ABF+ and LSCM as well as the packing algorithms really aren’t up to speed any more. Anyone know if there’s a project on the horizon addressing this?
Except that everyone wants it, no. At least not in the main channels of developers, I don’t know if they’ve though in that.
They are currently focusing on 2.8, that’s why it is rather unlikely to see improvements in this area.
They still merging some branchs to merge in some future with master (normal tools,…) but the SLIM branch does not have any update since almost a year. When you ask by the situation in the developer thread they don’t reply. ANd they never have talk about it.
PD: Every single of my messages don’t need to be put in context by you.
As far as I can see, the branches they are merging are basically finished. That’s not the case for this one. Just merging would not be sufficient.
If you build SLIM branch is perfectly functional except some bug. BUt I have a custom build in my PC to make some hard Unwrap and I never found any problem.
The implementation needs some changes/additions as mentioned here where the developer even has a list of topics that need to be finished:
https://developer.blender.org/D2530
As long as this is not done, it is not considered finished and won’t be merged. It certainly has to work as expected, but there are other criterions as well which have to be met in order to include it in master.
- Add timer to live-unwrap
- Do some testing / bugfinxing
- release test-build on graphicall
- improve upon feedback / bug reports
- done
Is basically complete implementation and only polish work.
But yes, you can quote me other time and write something to tell that you are right and I don’t. That all we know that is the only reason why you quote me every single time.
What you call polishing work can take a huge amount of time. There is a missing feature, but what usually takes far more time than estimated are the improvements and bug fixes from user reports. That usually requires several iterations and can be very time consuming. It is the last 10% of the work and as in many other areas too, it is not unusual that they require the same amount of time as the first 90%. That’s the reason why developers have to actually finish their tasks before they are merged.
That is not only the case in Blender, but it is a common practise in software development.
It is not unusual in this forum that several discussions take place at the same time. It is easier to follow discussions if people are being quoted in my opinion. I do it to avoid confusions and that is the only reason why I am doing it. I am not only doing that in discussions with you, but with everyone on pretty much every topic.
Hi
Now that I think about what I had said in the other thread, maybe I can successfully build the branch not only because of the changes that Lukas made, but also because now I am in Kubuntu 18.04 (when failed, I was in Kubuntu 14.04).
That message that you get surely are the last lines of the terminal, but more information about the error must be shown before those lines.
Just in case you try to update dependencies again running "./blender/build_files/build_environment//install_deps.sh” script.
Ok, I could make it work with this command:
git checkout 'uv_unwrapping_slim_algorithm@{2017-05-24 17:23:54}'
which is supposed to get the version of the branch at the date given at the end of the line.
It responded with this warning:
warning: Log for 'uv_unwrapping_slim_algorithm' only goes back to Fri, 15 Feb 2019 18:01:50 +0100.
but I guess it only concerns the logs, not the actual code.
Also, when running “install_deps.sh” I had to add --skip-osl because it failed installing but it doesn’t affect the SLIM UV part.
1 Like
i have goof hopes for blender 2.81 ^____^
1 Like
Is anybody actively working on including this to 2.81?
nope.
We’ll have to be patient (or pay a developer as a little group?). It’s always possible to build the branch though. Takes quite many files for just one feature but Blender 2.79 doesn’t take much space in modern memory drives.
1 Like
just to take away a curiosity, are these related links or what you mention is another “piece of branch of the SLIM algorithm”?
SLIM Unwrapping algorithm
https://developer.blender.org/T48036
Implementing the minimization of the symmetric dirichlet energy with ceres. Experimental.
https://developer.blender.org/D2531
Implementation of UV unwrapping with SLIM as discussed on T48036.
https://developer.blender.org/D2530
1 Like
@anon27868450 Your first link is a task (its identifier starts with a T). Tasks, by themselves, don’t contain any piece of code. They present a project and state what it’s about. They can also be requests from users (bug reports, feature requests). They may over time contain links to differentials, which contain code that differs from existing branches in some parts, but tasks are not bound to a single branch since they’re just project statements and discussion. They can link to multiple branches.
Differentials (which identifiers start with a D) however, are bound to specific branches, since they are bits of code that were changed from an existing branch to make it different. As you can see in the Diff detail area, the D2531 (second link) is bound to the uv_unwrapping_slim_and_ceres branch, which is not the one I’ve made instructions for. The D2530 though (3rd link), is bound to the uv_unwrapping_slim_algorithm branch, which is the one the instructions were made for.
1 Like
Hi. I use this paid one since few months with batch blender obj export then back to blender.
It really shows off that the best algorithm for unfolding are many who simulate artist workflows.
I did not found any problem since some months and longest unwraps take 10s. Average less than one second.
