(Linux) Incompatible with 3.1?

[TheSHEEEP]

Using the current 3.1 release on linux, I can build the module just fine and the demo loads as well. However, checking the actual procmeshes, I do not see any script (should be the .gdns, correct?) assigned.

And when creating a new mesh and assigning the .gdns as the script, Godot freezes and in the console I see these errors spammed continuously (same when trying to assign it to existing meshes in the demo):

ERROR: surface_remove: Index p_idx=26404876 out of size (surfaces.size()=0)
   At: scene/resources/mesh.cpp:892.
ERROR: surface_get_name: Index p_idx=26404875 out of size (surfaces.size()=0)
   At: scene/resources/mesh.cpp:958.
Removing unused surface 
ERROR: surface_remove: Index p_idx=26404875 out of size (surfaces.size()=0)
   At: scene/resources/mesh.cpp:892.
ERROR: surface_get_name: Index p_idx=26404874 out of size (surfaces.size()=0)
   At: scene/resources/mesh.cpp:958.
Removing unused surface 
ERROR: surface_remove: Index p_idx=26404874 out of size (surfaces.size()=0)
   At: scene/resources/mesh.cpp:892.
ERROR: surface_get_name: Index p_idx=26404873 out of size (surfaces.size()=0)
   At: scene/resources/mesh.cpp:958.
Removing unused surface 
ERROR: surface_remove: Index p_idx=26404873 out of size (surfaces.size()=0)
   At: scene/resources/mesh.cpp:892.
ERROR: surface_get_name: Index p_idx=26404872 out of size (surfaces.size()=0)
   At: scene/resources/mesh.cpp:958.

And yes, the p_idx is crazy large and always decreasing. I did not try and wait for it to become 0 ;) Also, Godot's memory usage starts blowing up, which would no doubt eventually lead to a crash.

I did change the .gdnlib file, but only added an X11.64=[ ] to the dependencies tag. And I also changed the godot-cpp submodule to the 3.1 release (the gdprocmesh repo checks out a slightly older version).

Not really sure what is causing this, if it is an error in the gdprocmesh or Godot itself, or related to linux, etc.

[TheSHEEEP]

I tried this in a completely fresh project, in which I simply copied the "addon" files with my self-compiled binaries. Now, I can actually assign the .gdns file without a massive amount of errors. However, it still does not work, since I am getting this error:

   At: modules/gdnative/gdnative.cpp:488.
ERROR: terminate: No valid library handle, can't terminate GDNative object
   At: modules/gdnative/gdnative.cpp:393.

I tried looking for this error, but so far the only hints were a version incompatibility. This cannot be the issue in this case, however, as I made sure to use Godot 3.1, and compiled the module using both the 3.1 versions (using the 3.1 branch on Github) of godot-cpp and godot_headers.

My guess is that the above error spam has the same root cause, it just leads to the spam due to the pre-existing stuff in the demo scene.

[BastiaanOlij]

I've never tried on linux, it should work just fine on 3.1. The error in the logs do suggest that the module isn't being loaded.

I haven't touched this in a while so I may indeed have broken something. loading existing scenes would just load the ArrayMesh data, the module doesn't do anything until you make a change to the graph.

[BastiaanOlij]

Just made the master in sync with godot-cpp 3.1, noticed there was an old api.json file in the root, removed that as it is no longer needed.

Compiles and runs for me on Windows, if its still having problems on Linux make sure the SConstruct file comes up with the correct godot-cpp library name and that the the gdnlib file indeed points to the correct procmesh library.

[TheSHEEEP]

The demo project behaves exactly the same as before (error spam and no .gdns assigned). A fresh project, with the files copied over and only the .gdns file created anew (and pointing to the .gdnlib file, which has the correct paths), also the same as before (no error spam, instead the error message when it tries to load the library).

Very strange, indeed, and the error message is not really helpful at all. Unfortunately, I know nothing about GDNative modules other than the setup and building steps (and those work fine), so all we really know is that something isn't quite right on linux ;)

[BastiaanOlij]

Sounds like it, I'm afraid I don't work with Linux at all. If you're on IRC/Riot look us up on #godotengine-gdnative, there are a couple of guys there who do work with Linux, they may know what needs to change.

[BastiaanOlij]

@TheSHEEEP I think everyone is on holiday, just noticed you popped in on IRC, I asked yesterday too but it's been quiet the last few days.

[beniwtv]

Both the demo and my own test project worked.

I did have to compile using LLVM though - GCC gave me errors about ambigous overloads in various PoolArray classes. Also the HDR background does not load for some reason.

Now, as for the spam, this seems to be caused if you wrongly attach the .gdns to the MeshInstance. It needs to be assigned to the underlying ArrayMesh as described in the readme.

[Windfisch]

Have you git-cleaned the godot-cpp repo? It caused lots of issues to me that scons -c does not clean everything (most importantly: src/gen/ and include/gen), git clean helped there. Other than that, I'm having some issues with NativeScript1.1 under Linux. Maybe using my patched "working" branch of godot-cpp can help you? (https://github.com/Windfisch/godot-cpp/tree/working?files=1)

If you like, on Tuesday i can try it out again

[BastiaanOlij]

Now, as for the spam, this seems to be caused if you wrongly attach the .gdns to the MeshInstance. It needs to be assigned to the underlying ArrayMesh as described in the readme.

I really need to find a way to protect against that, for me it just crashes when I do that :0

[BastiaanOlij]

most importantly: src/gen/ and include/gen), git clean helped there

I very often delete those manually (leaving the .gitignore file as the only file there), IMHO that really should be part of the generate_bindings script.

Btw, the nativescript1.1 branch is pretty much dead, that was the original logic (probably should be deleted), just use the 3.1 branch

[beniwtv]

@Windfisch This was a clean clone from GIT, so I did not clean anything

[BastiaanOlij]

@beniwtv I think windfisch was directing that to the OP :)

[beniwtv]

Ah might be :)

[TheSHEEEP]

Hey, thanks for the suggestions so far. I'm not at my main PC right now, so testing this will have to wait until after the holidays. However, for one I definitely did assign the .gdns to the MeshInstance, not the MeshArray (I followed the video and despite looking at it like 10 times, I did not notice this detail. Oops). This is an easy mistake to make and if it can anyhow be brought to the user's attention if it happens, that would be great. Maybe that was already the problem, though it doesn't really fit the errors I was getting later on.

Additionally, I'll try another fresh build, just to be sure (or git clean on the repo). I don't think I'll need to use LLVM, as GCC 7.3 compiled everything just fine and I'd rather not introduce another compiler to my pipeline if it can be avoided.

[BastiaanOlij]

I wish I had more time to take the next step with this project. You have no idea how often I am making the mistake of assigning the script to the meshinstance and crash my project :)

[TheSHEEEP]

Alright, some progress. Kinda. I basically did everything from scratch, git cleaned, etc. Now, when I assign the .gdns to the MeshArray properly, there's no crash and no error. It just gets assigned as it should.

However, the additional tab for the node editing ("Procedural Mesh") does not appear. Neither for a fresh project nor for the demo project. There's no error in the output or the console, either. In the video, you deselect the ArrayMesh after assigning the .gdns and re-select it. When I do the same, nothing happens.

Only this appears in the console:

No vertices in surface
No vertices in surface

But I'm not sure if that is even related.

[BastiaanOlij]

The no vertices in surface means no shape was created. My best guess is that the GDScript part of the plugin wasn't enabled, make sure that in your project settings the add on is known and enabled.

[BastiaanOlij]

Note that the editor part of the plugin is all GDScript, it's only the logic that builds the meshes that is GDNative

[TheSHEEEP]

After enabling the plugin in my other test projects, why would I remember to do so the third time around? Oof...

The plugin works just fine now, thanks. I think the only problem that wasn't an OSI layer 8 was the initial compilation with the pre 3.1 godot-cpp (and possibly git clean really was required, hard to tell).

Since all is good now, I'm fairly sure it can be closed.