Can't build on linux

[mdilena]

Hello,

first of, thanks so much for releasing this plugin as open-source, it looks really cool! I found a few issues when compiling this on linux though, seems like the code is using some of the Visual Studio templates (like dot) and there are some undeclared variables here and there; I don't have much c++ competence though, so I added a stack trace of what I'm getting out of cmake:

TwistSpline_cmake_log.txt

A few errors that I tracked down already are:

• twistSplineNode.cpp
  • line 33 #include <maya/MFNPluginData.h> is duplicate and also has a capital N letter, remove the line
• riderConstraint.h
  • riderConstraint:: on MObject assignment, apparently this only works in Visual Studio, removing that will fix one issue
• mpkdtree.h
  • dot seems to be a microsoft's custom template for Visual Studio, a workaround to make the build pass that issue was to copy the custom dot template from twistSpline.h to mpkdtree.h and commenting it out in twistSpline.h, so it won't be declared twice
• twistSpline.h
  • line 117, &v variable looks like it's not assigned but it's called from that line, I couldn't understand what was going on with that last function so I stopped here

I hope this helps tracking down build issues!

Cheers! Matteo

[tbttfox]

Thanks for this. I'm primarily a Python dev myself, so I'm just stumbling my way through a lot of the c++ gotchas. Also, I haven't really been following a lot of best practices since I've been the only guy looking at it 'till recently.

• twistSplineNode.cpp: That was probably a fat-finger case change on my part. Easy fix.
• riderConstraint.h: Didn't know that was a VS only thing. I was using another file as a template and kept the style. Another easy fix.
• mpkdtree.h: The kdtree isn't really well tested at this point. The intention was to use the dot template defined in twistSpline_maya.h. Maybe it's an include order thing? I'll have to investigate. Also, TwistSpline::buildKDTree isn't actually called from anywhere. I should probably do the right thing, pull that out of master, and move it to a dev branch.
• twistSpline.h: That's a lambda comparison function to build a vector of indexes that would sort params, so it should look at that instead of &v. That function is also unused in the rest of the project (kinda like buildKDTree ... I sense a pattern). It seems like maybe VS doesn't actually compile functions that aren't called? Again, I should probably be smart and pull that out to a dev branch.

[tbttfox]

Also, I'm using some c++14 features, which are apparently turned on by default in VS. All those nullptr errors in your log should go away if you enable that. I think adding this to CMakeLists.txt should work: set (CMAKE_CXX_STANDARD 14) If you could check that for me, I would appreciate it.

[tbttfox]

Hmm, dug into this a little more. I grabbed FindMaya.cmake from Chad Vernon ages ago for a different project, and I wasn't working in git at the time, so I just copied the file manually. It has since been updated quite a bit. So I'm going to add a PR to set that up as a submodule. Hopefully that'll help.

[mdilena]

Thanks for all the notes, I'll try that tomorrow and come back with the result!

[mdilena]

Hey, I was finally able to build this the other day, but I still had to fix a few things. Here's a new error log: TwistSpline_cmake_log_09-25-2018.txt

• I had to comment out all the mpkdtree stuff around because the compiler won't like it, even if it's not used;
• twistSpline.h line 519: remove the = double assignment from typename Float
• twistSplineNode.cpp lines 417, 425, 434remove the reference from &trans, &norms and &binorms, I think the reason why it's because that's their first assignment and they can't reference from anything (I asked a collegue but again, my knowledge of c++ is basically none);

Plus I found out that for linux you have to specify a add_definitions(-DLINUX) somewhere in the CMakeLists.txt because (or better, that should go to FindMaya.cmake, I'll see if Chad is ok with it), if your system is LINUX_AMD64, there's an autodesk header file (MNativeWindow.h or something) that is hardcoded to just LINUX and it won't compile, throwing anUnsupported platform` error.

That should be everything hopefully, but anyway after fixing this stuff locally it compiled and worked pretty well. Still have to do some proper testing but looks cool!

Cheers!

[tbttfox]

Your first point: Yeah that's fine. I'm going to play around with the kdtree more when I have time (or I when get a request at work).

Your second point about twistSpline.h: You're removing a default template argument. Line 288 of your cmake log says: default template arguments may not be used in function templates without -std=c++11 or -std=gnu++11 And you're also still getting those nullptr errors. Did you update the version of the C++ standard you were compiling with? If the adding that cmake variable didn't work, you should go looking for other ways to fix it. You shouldn't have to remove the default template argument.

And your third point: I think that works. The functions assigning those variables aren't returning references (perhaps they did in the past?), so that shouldn't cause any unnecessary copying. I'm still fuzzy on the lvalue/rvalue stuff.

[mdilena]

Oh snap, sorry for the wrong log. I replied while I was waiting for some stuff at work and recompiled on the fly with the default repo, so I didn't add the c++ 14 flag and still got those in. That cmake argument actually got rid of a lot of errors, when I compiled after your first reply, but the default template comes from another thing (actually, I now realize I left that answer half way yesterday): basically you are declaring the TwistSpline class twice in the twistSpline.h file, both in line 138 and then again at 519, and the gcc compiler doesn't like the fact that there's a default template argument assigned twice. The problem is I couldn't get an experienced c++ guy to have a look at the compiler errors and explaining me what was really happening, so that is me just messing around to make it through :) The only thing that I was able to ask him was that referencing thing, as I know that removing that kind of stuff randomly could blow up everything; so he looked at both those lines and the function they were referencing to and said that the reference wasn't valid (I can't remember the exact explanation) and that the compiler was right flagging that as an error.

Now, why visual studio compiles everything without changing a single line of code (I tried that on my windows machine at home), while gcc complains that much, is a complete mistery to me. I hope I will be able to get someone to follow me step by step while debugging the compiler errors. But in the end it worked after those few changes, I was able to build the rig in Maya and it was behaving as expected I guess, but I still need to play with it to be 100% sure that it works as it should.

[tbttfox]

Ah, no worries. I did a quick search, and StackOverflow sayeth I should only have the defaults defined in the prototype, so your fix was very likely correct. Easy enough to do. Thanks again for helping with this. I should have something committed shortly.

[fruityvince]

hi guys, First off, thanks for sharing this, it's great resource, and I'm always happy to look at some other people's work, see how they do it, etc. I'm not building on linux per say, but still on a unix system (mac os 10.14 / maya2019.2), and got some errors as well. Let me share this here, in case it helps someone.

I couldn't make the cmakelists file working, so I just used my own (possibly because of where the mac os SDK is and / or because maya moved its devkit/include directory outside of maya install

• commented out twistSpineNode.h / TwistSplineDrawOverride.fprintf(stderr, message.asChar()); My compiler couldn't deal with the message conversion, and since it's just a debug message, I commented it out
• twistSpine.h: commented out the entire multiLinearIndexes proc. It was complaining about a remap vector it couldn't find. I didn't really investigate, but looks like things are working fine even without this proc
• I also did some of the other fixes, but not all of them (e.g. I also had to set (CMAKE_CXX_STANDARD 14) )

once compiled, under makeTwistSpline, I also had to update a few keywords, but nothing fancy

Also, I was wondering how you managed to keep a consistant up vector for your curve. Looks like you're using rotation minimizing frame method ? I wanted to reproduce the same setup with just regular maya nodes, but it seems tricky ! To keep a consistant up vector, I usually use maya ik spline which seems to work with parallel transport, but not sure what are the differences between // transport and RMF. Time to investigate, but that is definitely exciting stuff =] Thanks!

[tbttfox]

Sorry, I haven't had much time to play with this since ... well ... 2018. Yeesh. Thanks for reporting back, I'm glad you're getting use out of it! Yeah, the multiLinearIndex isn't used. I think it's another part of the "get closest point" mechanism that I never finished. But I'll be honest, I've forgotten about that part.

As for the up vector, If I remember correctly I'm using RMF plus an offset. First I compute the raw frames along the spline. Then at each CV, I get the difference in twist between the controller and the current frame, or I get a twist value, or both (or something along those lines). Those offsets are passed into the same pinning algorithm as the length parameterization, allowing me to dynamically pin the up vector at any CV. I got most of my math from the Bezier Primer, and the RMF stuff came from this section: https://pomax.github.io/bezierinfo/#pointvectors3d Also, according to that, parallel transport and RMF are the same thing.

[fruityvince]

wow, great resource here, thanks for sharing! I'm still not 100% sure, but // transport and RMF might be different: even though the concept is similar, the formula seems slightly different (e.g. // transport uses acos, rmf doesn't, which makes it a better candidate for a vanilla maya implementation). Again, I'm still not 100% sure about that, this is what I understood from various guys better than me ^^

[tbttfox]

So after some research, I just read that if you take an up-vector and parallel transport it along the curve tangent, you get an RMF. So the RMF is a specific case of parallel transport. That's the connection. So then it just comes down to the algorithm we choose to approximate it.

The fun part is, the easy algorithm is actually more accurate according to the paper that described the algorithm. "The double reflection method has the fourth order global approximation error, thus it is much more accurate than the two currently prevailing methods with the second order approximation error" https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/Computation-of-rotation-minimizing-frames.pdf

[fruityvince]

interesting! Indeed, parallel transport is literally offsetting the first up vector by the angle b/w tangent and tangent+1. RMF does a little bit more with this double reflection algorithm, even though I still can't picture it precisely the entire thing yet (luckily the paper provides the pseudocode) Thanks for the explanation! I'm looking into re-implementing the same setup that you did, but with maya nodes! Not sure it is possible / fast enough for production use, but I'll see =]