Anyone volunteering to make a new UV Unwrapper?

[reduz]

Godot is currently using Thekla Atlas for unwrapping UVs on mesh import. Unfortunately, this implementation is very slow and quite buggy. We need a replacement, otherwise the current light mapping workflow (which is needed for pretty graphics on low end) will continue to be a hassle.

The only other open source unwrapper is Microsoft's UVAtlas, but it's windows-only so it needs porting. Also, it does not support specifying a texel size, which makes it no so useful.

There are a few papers on implementing this algorithm:

• LSCM (2002)
• SLIM (2016, more modern)

Would anyone be interested in giving a try of implementing one of these algorithms in Godot, make it work with a texel size parameter, and make it as optimal as possible?

[AbhimanyuAryan]

I'll have a week holiday from work. I'll give it a shot. Where can I get any help if needed? Do we have Gitter channel for GodotEngine?

[avril-gh]

@AbhimanyuAryan
IRC
chat.freenode.net
#godotengine-devel
#godotengine-doc
#godotengine

[laverneth]

We can team up, I know the computation of injective maps quite well. I just don't really where to start within godot...

[reduz]

Sorry, should have posted this before. You can check here how thekla atlas is integrated:

https://github.com/godotengine/godot/tree/master/modules/thekla_unwrap

should be pretty much creating another similar module and disabling thekla

[reduz]

and Godot has most of the math types and container types in core:

https://github.com/godotengine/godot/tree/master/core/math

so no need to write your own

[laverneth]

I can't find support for sparse matrix and sparse linear solver, I can write my own in the library. Should they be kept separate? Le ven. 22 juin 2018 à 14:30, Juan Linietsky <notifications@github.com> a écrit :

…

and Godot has most of the math types and container types in core: https://github.com/godotengine/godot/tree/master/core/math so no need to write your own — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19710 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1nWa9yCsUhw88DKmCSDefRulztz80Oks5t_ONRgaJpZM4UzCVj> .

[reduz]

yeah, godot only has basic linear algebra types, as sparse matrix/linear solvers are not that common or difficult to make generic. If you want to write your own for this and put it within the unwrapper code, it's fine

[laverneth]

Well that's seam feasible. Still, I have few questions. 1)What I intent to do is create a new thirdparty lib as theakla and then wrap it into a module as you sent? Or shoudl I develop everything inside the module (in that case I guess I can have access to godot classes, such as meshes)? 2)Is it ok to depend from stl, because for the sparse matrices it would make my life easier if i can have std::vectors. If I am in the module I'll depend on godot' vector implementation 3) I'm not sure to understand 100% the use case. Is for uv unwrapping a single mesh or do we have also to unwrap several patches (seamless parameterization section6 of the latest article reference you sent)? 4) YOu said Theakla was slow. What's the expected speed ? On which size of meshes? Would you have one or two testcases (meshes)? Thank you very much Juan and all Le ven. 22 juin 2018 à 16:21, Juan Linietsky <notifications@github.com> a écrit :

…

yeah, godot only has basic linear algebra types, as sparse matrix/linear solvers are not that common or difficult to make generic. If you want to write your own for this and put it within the unwrapper code, it's fine — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19710 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1nWSQN_RFOblWqVlLdgeZfZUtHkvepks5t_P2AgaJpZM4UzCVj> .

[reduz]

@laverneth This is really up to you. If you want to make a standalone library for us to bind and for others to use too, it's fine. This is really lacking in the open source gamedev scene and I'm sure many will really appreciate it. You can write it in your own github repo, and we will just copy it to Godot repo from now and then if you make updates. If you go this way, please make sure to not depend on external libraries (like third party libraries for math), and keep everything as compact as possible, so it doesnt make engines that may include it more fatty.

If you just want to make it within Godot, It's also fine (I did this with CSG) as I can understand it's less work as all the math code is pretty well tested. In this case, if someone wants then she/he can extract it and make it standalone. In this case, then also I guess it will be better if you use Godot container templates instead.

Either case please make sure to use the MIT license, and we will include it in in our license authors files.

[ddiakopoulos]

For an initiative like this it might make sense to attempt to validate + profile against a large database of potential input models. One possibility is https://ten-thousand-models.appspot.com/ and another here: http://cvgl.stanford.edu/projects/objectnet3d/. The 10k dataset has many degenerate cases so it's very helpful. What these datasets lack is geometry that is more game-specific (like terrain), but likely to be used for target lightmaps.

[ddiakopoulos]

There are also very recent techniques with permissively-licensed open-source implementations. The APIs might need work to make them integration-friendly, but otherwise might provide promising alternatives to the other libraries mentioned above.

• Boundary First Flattening
• AutoCuts (GitHub)

Both come with interactive editing modes to help users create ideal parameterizations, but it's not too much effort to get reasonable results automatically I think.

[rotoglup]

About UVAtlas,

The only other open source unwrapper is Microsoft's UVAtlas, but it's windows-only so it needs porting. Also, it does not support specifying a texel size, which makes it no so useful.

@reduz Do you need texel size to specify padding/distance between charts ? I saw in UVAtlas.h the gutter argument for this case. I may miss something as I don't use Godot or UVAtlas :}

//  gutter - The minimum distance, in texels between two charts on the atlas.
//           this gets scaled by the width, so if gutter is 2.5, and it is
//           used on a 512x512 texture, then the minimum distance will be
//           2.5 / 512 in u-v space.

[reduz]

@rotoglup No.. unless there is something I misunderstood, texel size is needed to compute the actual texture size. When you call the unwrapper, you have to feed it a mesh and a texel size (in the same units as the mesh). As a result, the unwrapper needs to figure out the final texture size.

In UVAtlas, you have to supply texture size beforehand, so it's not possible. Otherwise, I'm not sure how gutter could be of use for that (without having to call unwrap twice)..

[JFonS]

The BFF linked by @ddiakopoulos looks very promising and uses the MIT license. So it might be better to try integrating it into godot (just a part of it) instead of reinventing the wheel.

[JFonS]

@reduz also, the texel size is only used when generating and packing a texture. Thekla seems to be using nvidia-texture-tools for that, so it should be possible to integrate a different UV mapping algorithm with this texture packer.

[laverneth]

I don't know if that's a problem but BFF uses Cholmod (from eigen) which is under GPL 2.1 licence for fast performance. Moreover it only produces conformal maps, whereas the SLIM approach can also produce isometric map, and other different maps depending on the choice of energy. It's still up to the community to decide what's best, just a heads up :-)! Le sam. 23 juin 2018 à 15:16, JFonS <notifications@github.com> a écrit :

…

@reduz <https://github.com/reduz> also, the texel size is only used when generating and packing a texture. Thekla seems to be using nvidia-texture-tools for that, so it should be possible to integrate a different UV mapping algorithm with this texture packer. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19710 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1nWd55S-FyPih9f7pm1SlguJrABivMks5t_j-rgaJpZM4UzCVj> .

[reduz]

@laverneth whathever we use needs to be MIT compatible, else it forces the whole engine to use a more restrictive license. It may seem that BFF is also restricted to manifold with no holes, which is likely a problem. From what I understand, the only two algorithms I know that actually work well are LSCM and SLIM.

[reduz]

Slim example is under GPLv3.. I wish people would stop using this license for academic stuf.. :(
https://github.com/MichaelRabinovich/Scalable-Locally-Injective-Mappings

[laverneth]

Do we have access somewhere to a svd decomposition, line eigen? I need it for decomposing the jacobian. Otherwise I will include the TNT but it will make the module fatter... Le 23 juin 2018 4:51 PM, "Juan Linietsky" <notifications@github.com> a écrit : Slim example is under GPLv3.. I wish people would stop using this license for academic stuf.. :( https://github.com/MichaelRabinovich/Scalable-Locally-Injective-Mappings — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19710 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1nWdnVKJIsCyDR60P6QZgviWlK1c7hks5t_lYCgaJpZM4UzCVj> .

[reduz]

Do we have access somewhere to a svd decomposition, line eigen? I need it
for decomposing the jacobian. Otherwise I will include the TNT but it will
make the module fatter...

No, in general these are implemented per each algorithm depending on the needs. Bullet has code for this, but it's meant mostly for solving physics constraint for a 3D physics engine. Here I imagine you need it for 2D to relax the edge constraints, so i don't think it can be reused. Worst case, does not seem like it should be too much code to copy from an existing MIT licensed library, if you need that.

[laverneth]

The TNT has no particular license, they juste want to be credited. I will. https://math.nist.gov/tnt/ Le sam. 23 juin 2018 23:16, Juan Linietsky <notifications@github.com> a écrit :

…

Do we have access somewhere to a svd decomposition, line eigen? I need it for decomposing the jacobian. Otherwise I will include the TNT but it will make the module fatter... No, in general these are implemented per each algorithm depending on the needs. Bullet has code for this, but it's meant mostly for solving physics constraint for a 3D physics engine. Here I imagine you need it for 2D to relax the edge constraints, so i don't think it can be reused. Worst case, does not seem like it should be too much code to copy from an existing MIT licensed library, if you need that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19710 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1nWcnPFxPbRvivvntwaafC9nkT4yBAks5t_rAbgaJpZM4UzCVj> .

[Calinou]

The TNT has no particular license, they juste want to be credited. I will.

When no license is attached, no permissions are granted.

If any code is copied, it should be permissively-licensed without ambiguity; please contact its author(s) to ask for permission to use the code under the MIT license.

[hpvb]

* This software was developed at the National Institute of Standards and
* Technology (NIST) by employees of the Federal Government in the course
* of their official duties. Pursuant to title 17 Section 105 of the
* United States Code, this software is not subject to copyright protection
* and is in the public domain. NIST assumes no responsibility whatsoever for
* its use by other parties, and makes no guarantees, expressed or implied,
* about its quality, reliability, or any other characteristic.

according to the header files. I don't think anyone needs to be contacted, or legally speaking credited.

[razcore-rad]

That looks like a license to me, remember a license is just some text, it doesn't actually have to be one of the know ones, eg. MIT or whatever, it just needs to be some text compatible with whatever you're using. The above seems pretty compatible

[laverneth]

Can someone explain me when the call to thekla is effectively done? I see it's done in the lightmap_unwrap, what should I do to trigger this functions? Many thanks! Le dim. 24 juin 2018 à 07:42, Răzvan C. Rădulescu <notifications@github.com> a écrit :

…

That looks like a license to me, remember a license is just some text, it doesn't actually have to be one of the know ones, eg. MIT or whatever, it just needs to be some text compatible with whatever you're using. The above seems pretty compatible — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19710 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1nWTwkqbxCS2Y8GBYy0m1Rd71moFYPks5t_ybNgaJpZM4UzCVj> .

[reduz]

Here in the documentation of light mapping you can see the two use cases (manual and on import), basically the most common use case is as an import flag, but the manual method allows you to debug it more easily

[reduz]

sorry, forgot link - http://docs.godotengine.org/en/3.0/tutorials/3d/baked_lightmaps.html

[reduz]

If you want to iterate faster, remember you can run Godot editor from the command line with a test scene like:

godot -e test_unwrap.scn

[lassade]

What about this implementation http://alice.loria.fr/index.php/software/4-library/23-opennl.html it's under the 3-Clause BSD License, is very compact (4 files) and static linked.

[jamesdolan]

I had pretty much have been facing the same dilemma for my own project. Thekla was way too crashy for my liking but UVAtlas seemed to be pretty robust but being Windows only was a bit of a downer.

UVAtlas allows you to run Partitioning and Packing as different steps. The partitioner is resolution independent and I am quite happy with its output, its the packer that needs work. As you point out it doesn't let you set a target density, but its pretty easy to compute surface area before packing and calculate your own scale to target a specific density.

The bigger problem IMHO is that the tetris-style packer does a rather poor job compared to Thekla in my experience. Leaves lots of dead space, specially when there is a large ratio between the biggest charts and smallest charts.

The other nice thing about UVAtlas is its actually under active development and tested in production.

My recommendation after taking a quick glance at feasibility is instead of forking it and porting it, someone should build a compatibility layer that re-defines the macros and types it uses so that its easy to take updates from the mainline and push changes upstream (guessing MS wouldn't take a pull request that de-microsofts it). That is my long-term plan, but not sure when I would get to it... so if someone else does it, even better! :p

[AbhimanyuAryan]

@reduz may I ask what bugs are you facing with Thekla Atlas? Are you getting charts with too much distortion, or worse, that self-overlap?

[reduz]

@AbhimanyuAryan No, Thekla works more or less well, the problem is that it's huge, depends on unmaintained third party libraries, it's crashy (code has no checks for geometry it does not like), and the main problem above all, it's really really slow. It's simply unusable on complex scenes.

[jpcy]

I did some work removing unused code from thekla_atlas a while back here. Got it down from about 18kloc to 8kloc.

Some easy performance fixes:

• Use packing_quality of 1 instead of 0. Like the source says, 0 is too slow.
• Disable printing to stdout.

Testing with dabrovnic sponza (~66k triangles):

• packing quality 0 - 60 seconds
• packing quality 1 - 25 seconds
• packing quality 1, printing disabled - 4 seconds

[reduz]

@jpcy oh wow, amazing work! definitely need to give it a check. Are you up for merging fixes? ( think i did a few to thekla that resulted in crashes in bad input geometry )

[jpcy]

@reduz After looking through the Godot changes, I added checks for zero length edges and zero area triangles. Zero length edges were definitely causing crashes.

[laverneth]

I have been making some progress about implementing the SLIM paper. For the moment I'm focusing into initializing the (u,v) property by minimizing the dirichlet energy on the surface by constraining the longest boundary loop to be immersed one a circle. However I do have some trouble to make a proper test. I am importing a .obj as a mesh instance but I have some inconsistent number of vertices and faces. I was wondering if the .obj import of godot was'nt broken OR the way I have created this file. I have imported the stanford bunny (file format .ply) inside blender and exported it as .obj before reimporting it. Does anyone knows anything about similar issue? I've checked the .obj file and the number of vertices and facets seems to be consistent. Cheers Le sam. 14 juil. 2018 à 12:51, Jonathan Young <notifications@github.com> a écrit :

…

@reduz <https://github.com/reduz> After looking through the Godot changes, I added checks for zero length edges and zero area triangles. Zero length edges were definitely causing crashes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19710 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1nWSHZuvxvYvFCS46bwX9ft-B-4epnks5uGc0sgaJpZM4UzCVj> .

[Calinou]

@laverneth Have you tried triangulating faces while exporting in Blender, either by adding a Triangulate modifier and checking Apply Modifiers in the OBJ export dialog, or by checking Triangulate Faces in the same dialog?

In general, it's best to perform triangulation in advance — it avoids some quirks that can arise when you let an engine triangulate meshes for you.

[laverneth]

I used the default, which is "Apply Modifiers". I'll check with the triangulate faces. Thanks! 😀 Le lun. 16 juil. 2018 à 16:26, Hugo Locurcio <notifications@github.com> a écrit :

…

Have you tried triangulating faces while exporting in Blender, either by adding a Triangulate modifier and checking *Apply Modifiers* in the OBJ export dialog, or by checking *Triangulate Faces* in the same dialog? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19710 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1nWYR5HCH2OcnJeD5OrLrCCF1Y636jks5uHKKGgaJpZM4UzCVj> .

[huxingyi]

Hi, how is the progress on this? I used Thekla Atlas for unwrapping UVs also, but cannot bear it with the crash on bad meshes. Actually, I looked this issue about two months ago when I was trying to find an alternative, finally I decided write it on my own, I use the MPL2 licensed libigl’s parameterization implementation (ARAP and LSCM). It works well on my project.
Here is my UV unwrapping library, here is how it’s been used,
And here is the screen shoot of unwrapping:

If you are interested, I’d like to integrate it into godot.

BTW, I saw you @reduz request an alternative for cork, currently, I use CGAL, it works quite well on mesh boolean operations, but I have decided try to write it on my own also, because I cannot go with the CGAL license, here is the project, although, empty yet, because I just start it by today :-)

[laverneth]

Wow that looks good! On my side I tried to have a look into godot' code to see what was needed to do it inside. My conclusion is the following: we need a proper mesh boundary description to initialize the mapping with the Tutte method and a proper linear solver. Both of those represent a big amount of code (in particular a good linear solver) and I doubt that the godot' community would like to see its codebase grow so much for parametrization code. However, we should ask to @reduz , maybe?

[fire]

Has anything changed? What is the status of this?

[huxingyi]

Thanks @laverneth for the update. And I didn't got any reply from godot since I posted here, so I don't know what's the status of this, and I am quite busy at the moment, so I am out on this issue.

[KoBeWi]

Thekla Atlas was replaced by Xatlas, but I don't know any more details.

[Calinou]

With Thekla Atlas being replaced by Xatlas and further tweaks made to optimize Xatlas, this issue can be closed.

[Ben-Mack]

I've noticed XA_RECOMPUTE_CHARTS enabled in xatlas usually results in a lot of small and unnecessary charts. Both original and Godot's modified version suffers from this problem.
It would be great if someone could take a look and discuss ideas to improve: jpcy/xatlas#84