Sorry, but this isn’t an option. It’s GPL or nothing with Blender add-ons. Other open source licenses don’t apply.
Blender’s Python API is an integral part of the software, used to define the user interface or develop tools for example. The GNU GPL license therefore requires that such scripts (if published) are being shared under a GPL compatible license.
A good new (Free !?) Remesher would be fantastic, of course.
P.S.
Don’t let the licenses bother you.
Licenses exist for reason and people (users, developers) have to respect them.
Maybe you could take a look at Jeremy Hu’s Auto Remesher code (GPL v3):
Unfortunately you have to bother with them, I do wish I didn’t have to worry about Blender’s GPL hurdle, but I will jump over it. It’s just taking time away from developing things that are actually useful for users, which is a shame.
Maybe you can check how quad Remesher is licensed, because i think only the python addon is gpl licensed but not the engine itself (which is written in c+ i think and other license)
UVPackMaster also does the same thing where the python code (the bridge) is free and opensource but the binary engine is payed for and uses a difference license.
I think the loop hole is that they can’t be shipped together, so you would need to have your bridge (the python code) and your binary files separate from each other.
Correcto that’s what I meant
@MichaelBenDavid @Lamia
Yes I’ve been doing a lot of research on this and that’s exactly the plan more or less.
I think the loop hole is that they can’t be shipped together
Not really a loop hole per se, but it makes it more obvious that they are separate works. Anything that makes it obvious that it’s not a derivative work under copyright but separate programs running separately is what you want.
But even then the FSF wants to argue that if enough complicated data is moving between them then it’s part of GPL, which I think is utter nonsense, the truth is they have no idea either because none of this has ever been taken to court. They even admit they have no idea in the GPL FAQ.
Personally at that point I believe they’re starting to infringe on my rights as a developer of my own, separate work. And that makes me a little angry.
Now what does one have to do with the other?
I wrote Memm not to let it bother him and not that he should disrespect the license
Well known.
And as you probably read, it hasn’t been updated in 2 years.
Haha yeah, I’m convinced they’re dancing around the linking issue because they know they’ll get destroyed in court over it. Actually even if they win, it would do irreparable damage to FSF and GPL in the software community because nobody would touch GPL after that, not even open-source developers.
Here’s an interesting read on that topic.
If not a single lawsuit has been filed in 30 years that can only mean it’s a can of worms they don’t want to open. So the best they can do is spook you with scary language in the FAQ and hope you don’t do any more reading.
That said it’s still a good idea to separate your work from whatever you’re linking to as much as possible for many other reasons.
So you feel like doing this addon to come true? To leverage your work on this try first research on available opensource remeshers on how they approach this, because of technical reasons we don’t have a fully reliable (and free or even paid) remesher for artists to work with so that can sooth all these technical time consuming (expensive too) workflow, because otherwise we could had use them in complex designs (think about hard surface not just a silly organic model) which these days require all manual work mostly. Also remember that artistic (or directing the engine rather) control is important, we don’t want just a random result based in polycount limits or something, but an smart engine and having an smart guides system will be required for optimal control, for example looks at this how quad Remesher performs with it’s algorithm on this simpler but rather not mesh The big Blender Sculpt Mode thread (Part 2) - #892 by Metin_Seven
Yeah you maybe can find papers somewhere in the internet where there’s some development of these, btw this YouTube channel posts new papers related to cg of course https://youtube.com/@TwoMinutePapers
Alright everyone, it’s back!
New download link, click here.
NOTE: This release is for Windows.
Install as a normal Blender plugin, but once you enable it you’ll see a button to download the MemmGraphics utilities which is required for seam generation.
There’s also now a nifty update feature to keep the plugin updated when there’s a new release.
AND I’ve included a small update in the seam generation that further increased performance.
Merry Christmas and Happy New Year everyone.
Hi Memm,
many thanks for the Update.
I have a small request.
By installing in C:\ProgramData\MemmGraphics, Blender can no longer be used portable.
Please build, for example. a “query” to see if MemmGraphics is in the UnwrapMe folder.
Many thanks!
Hmmm, I see. I think I can solve this by letting you choose where you want to install the extra downloads, I’ll put it on my todo list.
Just wanted to voice my interest in a Linux version. Regardless if you plan to open source this or sell it I would financially support it, if it works nicely, which it looks like it does.
There’s no reason it won’t be on Linux eventually, but I can’t promise when I’ll get around to it.
Wow, impressive bit of software here. I just discovered this plugin today (19Dec22 release), and ran it through a “quick” torture-test and comparison against full-auto UV results from Substance Painter (Oct 2021 release) and RizomUV (2022.1 release). The test subject was to auto-unwrap a decimated 300k tris .STL detailed human sculpture designed for 3D-print/manufacture. Maybe not the most common use-case for most. Long story short, UnwrapMe was by far the slowest - it took over an hour. The competitor options took around 1-3 minutes to process the same mesh. However, UnwrapMe was hands-down better than Substance Painter’s auto-unwrapper - no contest (at least, for the somewhat dated version I have!). So, for a lot of more common use cases, UnwrapMe is really onto winner by this comparison alone. Comparison against RizomUV is more complex, because Rizom is a dedicated UV tool and has several algorithms on offer, as well as many manual or “assisted” unwrapping tools. Probably unfair to make direct comparisons here, but a few quick tests demonstrated to me that UnwrapMe still holds up favourably. While UnwrapMe took much, much longer to process, I’d say the resulting UV maps were generally more “human readable” (useful for additional manual edits, at the least) and there were fewer seams overall, which is a bonus for my particular use case. With some manual edits and an order-of-magnitude processing speedup, UnwrapMe would probably become my favourite of the lot. Of course, my use cases are atypical. Don’t even ask me why I’m messing about with unwrapping dense STLs - I have my reasons ;).
Will look forward to further developments on this - very intrigued. Thanks so much for sharing!
Thanks for testing it!
I have a ~230k tris mesh that I test on, could you tell me what settings you were using? Also please note there are two algorithms at the moment, procedural (it grows charts sequentially) and lloyd iterations. Procedural might take a long time for a high poly mesh, but lloyd should be done in a couple minutes for 300k tris with a modern multi-core CPU.
For me it takes about 10 minutes for procedural and 90 seconds for lloyd, with a 6 core AMD processor from 2012, which is pretty old now, on a ~230k mesh. So it’s very strange that yours ran for an hour and I’d like to find out why. If possible could you send me the .blend file so I can test it?
It was just a quick test, so I only tried the default settings which used the procedural algorithm. I’ll give it another go with the lloyd iterations and maybe try some more tests over the holiday period/break from work next week. I’m running a fresh install of Blender 3.3 LTS (with a ton of plugins, admittedly) on an 11th gen i7 11700k (2021) processor. Unfortunately I can’t send the particular test scene because I was using an asset covered by NDA, but I could easily bash together something with similar topology/density from a more general-use asset for future tests.