Adding the Plugin makes UE4Editor unable to start

[Dragonking3x]

UE Version: UnrealEngine_4.26
Carla Version: github branch master

cloned with
git clone --recurse-submodules https://github.com/brifsttar/OpenDRIVE.git

Project folder

make launch

Setup.sh: llvm-8.0 already installed.
Setup.sh: boost-1.72.0-c8 already installed.
Setup.sh: rpclib-v2.2.1_c5-c8 already installed.
Setup.sh: gtest-1.8.1-c8 already installed.
Setup.sh: recast-0b13b0-c8 already installed.
Setup.sh: Libpng already installed.
Setup.sh: Xerces-c already installed.
Setup.sh: Sqlite already installed.
Setup.sh: PROJ already installed.
Setup.sh: Patchelf already installed.
Setup.sh: CARLA version 0.9.13-2-g0c41f167c-dirty.
Setup.sh: Generating CMake configuration files.
Setup.sh: Success!
BuildLibCarla.sh: Building LibCarla "Server.Release" configuration.
ninja: no work to do.
[0/1] Install the project...
-- Install configuration: "Server"
BuildLibCarla.sh: Success!
BuildCarlaUE4.sh: Using Unreal Engine at '/home/patrickpromitzer/UnrealEngine_4.26'
BuildCarlaUE4.sh: Build CarlaUE4 project.
make[1]: Entering directory '/home/patrickpromitzer/app/carla/git/carla/Unreal/CarlaUE4'
bash "/home/patrickpromitzer/UnrealEngine_4.26/Engine/Build/BatchFiles/Linux/RunMono.sh" "/home/patrickpromitzer/UnrealEngine_4.26/Engine/Binaries/DotNET/UnrealBuildTool.exe" CarlaUE4Editor Linux Development  -project="/home/patrickpromitzer/app/carla/git/carla/Unreal/CarlaUE4/CarlaUE4.uproject" 

Running Mono...

Fixing inconsistent case in filenames.
Setting up Mono
~/UnrealEngine_4.26/Engine ~/app/carla/git/carla/Unreal/CarlaUE4
Using 'git status' to determine working set for adaptive non-unity build (/home/patrickpromitzer/UnrealEngine_4.26).
Invalidating makefile for CarlaUE4Editor (OpenDRIVE.uplugin has been added)
Parsing headers for CarlaUE4Editor
  Running UnrealHeaderTool "/home/patrickpromitzer/app/carla/git/carla/Unreal/CarlaUE4/CarlaUE4.uproject" "/home/patrickpromitzer/app/carla/git/carla/Unreal/CarlaUE4/Intermediate/Build/Linux/B4D820EA/CarlaUE4Editor/Development/CarlaUE4Editor.uhtmanifest" -LogCmds="loginit warning, logexit warning, logdatabase error" -Unattended -WarningsAsErrors -abslog="/home/patrickpromitzer/UnrealEngine_4.26/Engine/Programs/UnrealBuildTool/Log_UHT.txt"
LogCompile: Error: Duplicate class name: ATrafficLightController also exists in file /Script/Carla
/home/patrickpromitzer/app/carla/git/carla/Unreal/CarlaUE4/Plugins/OpenDRIVE/Source/OpenDRIVE/Public/TrafficLightController.h(1): Error: Duplicate leaf header name found: /home/patrickpromitzer/app/carla/git/carla/Unreal/CarlaUE4/Plugins/OpenDRIVE/Source/OpenDRIVE/Public/TrafficLightController.h (original: /home/patrickpromitzer/app/carla/git/carla/Unreal/CarlaUE4/Plugins/Carla/Source/Carla/Traffic/TrafficLightController.h)
make[1]: *** [Makefile:315: CarlaUE4Editor] Error 6
make[1]: Leaving directory '/home/patrickpromitzer/app/carla/git/carla/Unreal/CarlaUE4'
make: *** [Util/BuildTools/Linux.mk:7: launch] Error 2

[brifsttar]

Interesting, both my OpenDRIVE plugin and CARLA have a class named ATrafficLightController. Not really surprising, considering we both deal with driving simulation.

Not sure if this can be solved on my end: I don't really want to start renaming my classes in case they conflict with X or Y other plugin. What you can do is either rename or remove this class from either plugin to bypass the conflict. My ATrafficLightController is actually undocumented and only used for our internal projects at the moment, so I think you can safely delete it from my OpenDRIVE plugin and get on with your project.

[brifsttar]

Also, note that I don't distribute Linux binaries for esmini/RoadManager, so you'll have to build them yourself. Even though the upstream project has Linux support, I might have gone a bit hard on the CMake configuration files cleaning, and so the Linux build chain might be broken. If so, let me know and I'll try to repair that.

[eknabevcc]

You can get the latest esmini binaries releases for your system here:
https://github.com/esmini/esmini/releases
For example: esmini-bin_win_x64.zip

[brifsttar]

Thank you Emil for this information, but there's a small caveat though: the Unreal OpenDRIVE plugin uses a very slightly modified version of esmini. Most notably, I added __declspec(dll...) to some classes in RoadManager.hpp (and probably changed it to dynamic linking? I think it links statically by default, but I'm not sure). This is so that the actual C++ API could be accessible using the DLL, without having to go down to the C API.

Now that I think of it, I'm really not sure that any of that would build on Linux. I'm actually not really familiar with building dynamic C++ libraries on Linux, so I'm not sure how I would get around to getting it to work.

[eknabevcc]

Oh, I see. So you don't use the esminiRMLib or esminiLib?

Unfortunately I have not (yet) experience with Unreal, although it's high on my list :)

In Unity we use the two libs mentioned above. They are in fact shared (.dll in Windows, .so in Linux) but includes everything needed for esmini linked statically within. - like a container including static stuff, but the container itself is linked dynamically.

Maybe you actually need the internal API of roadmanager. Otherwise, it would be interesting to investigate whether the shared libs would provide enough functionality for your use cases.

[brifsttar]

I don't use any of those, but I haven't really checked them out either.

For context, when I started using RoadManager, I don't think any DLL was available. It was before the first RMLib (I don't recall the name) that you used for your Unity project (or right around that time). So back then I just statically linked with RoadManager, because since I was already working in C++, it was the easiest thing to do. Then I got used to the API and had quite a lot of dependencies to it, so I never really gave much thought about the C API.

When I refactored things and decided to use dynamic linking, I think there was the first RMLib, but I don't think it was as complete as it is now. So since I'm very lazy, I just decided to put some __declspec in front of some classes and call that a day :D

I don't really know if the shared libs would be functionally enough. I think I mostly use common and high level features, so it would probably cover most of my requirements. One weird thing I do that comes to mind is to set the lane snapping type to all, because I do like my sidewalks ;)

OpenDRIVE/Source/OpenDRIVE/Private/OpenDriveComponent.cpp

Line 14 in c49479c

_TrackPosCache.SetSnapLaneTypes(roadmanager::Lane::LaneType::LANE_TYPE_ANY);

But it's just so nice to just use the C++ API and have everything available with classes and such, instead of relying on an intermediate C API. Having the ability to use RoadManager's native C++ API (and my other C++ libs) actually was one of the major reason why I chose Unreal over Unity.

[eknabevcc]

I see. Yes the ability to integrate C++ is definitely an advantage of Unreal!

Regarding snap: Recent change is that pedestrians will snap to sidewalks (in addition to drivable lanes - maybe it should be instead :)). See esmini/esmini#343. Maybe that would work for your use case as well?

Just a loose question: Would it be possible to pull in your modifications? Or maybe you did a lot of customizations?

[brifsttar]

Would it be possible to pull in your modifications? Or maybe you did a lot of customizations?

I didn't do much changes, and as much as possible I try to only add things and not change existing code. But I can make a quick human-readable summary, because it's quite short. I think this is the diff on GitHub? esmini/esmini@master...brifsttar:esmini:roadmanager

The breaking things are:

• RoadManager is built as dyn lib instead of static, so it implies __declspec(...) and changes in CMake files
• MoveAlongS/Delta doesn't use junctionSelectorAngle but a new int/enum value (I think I previously mentioned this in a email)
• The added hintRoad for XYZ2Track (see [roadmngr] Added hintRoad param to XYZH2TrackPos esmini/esmini#280)

Non-breaking things:

• const correctness (you already merged a PR of mine a while back, but I keep adding more)
• Few new methods, mostly in Position, like GetLane, GetRoad, GetNextJunction

So right out of the box the fork can't be pulled in, but with just a bit of work it could. For the DLL stuff, it's probably possible to generate both a static and dynamic using CMake (I'm lazy so I just replaced a STATIC with SHARED and moved on :D ). For the MoveAlongS, the function could probably be refactored to allow custom selection methods, so that junctionSelectorAngle could still be default, but user could provide their own if they want.

Now that I wrote all that, I'm half motivated to do it. But it's quite busy time here, so maybe later!

[Dragonking3x]

Thank you both for answering.

I deleted ATrafficLightController and then a different error appeared.
I guess the problem is, that it can't find the RoadManager files (because of Ubuntu!?!?), even if I add them manually.

I can look deeper into it to find a single-use fix tomorrow.

[brifsttar]

Come to think of it there are multiple steps involved to get the plugin to work on Linux, because so far everything has been targeted for Windows.

The first thing is to build RoadManager for Linux, which should be doable in theory (as mentioned by Emil, the upstream project builds on Linux), but requires some work as I changed CMake files + hpp to link dynamically.

The next step is to update the Build.cs file (here) to add support for Linux.

After that, the Loader Module (here) also needs to be updated to load the so instead of the DLL.

And that should be it? I'm really unfamiliar with Linux, so I can't really help or estimate the workload to get that to run.