XbimGeometry
XbimGeometry copied to clipboard
xBimTeam
Unity CreateContext Crash
Versions of xBIM Packages:
- xBIM Essentials: 4.0.29
- xBIM Geometry: 4.0.11
- Unity: 2018.1.0f2
- .NET 4.x
Minimal code (or steps) to reproduce the issue:
using (IfcStore model = IfcStore.Open(file.ifc))
{
Xbim3DModelContext context = new Xbim3DModelContext(model);
context.CreateContext();
}
Minimal file to reproduce the issue:
Doesn't matter what IFC file should be used.
I'm currently creating a project in unity that should read an IFC file and create the GameObject for that file. But when I use the code above, unity crashes. The only debug error I get is something about abort.cpp. I also tried to add msvcr100.dll msvcp100.dll msvcr120.dll and msvcp120.dll to the plugins folder, as I read somewhere, but it still crashes. Does someone else have this problem and is there a fix to it?
I read through all the discussions regarding Unity and none of them is a satisfying solution to that exact problem I have as well. Most people here seem to be building xBIM applications against VS2013, which is no option for a productive build in 2018.
@sINFsehill can you confirm, that the call to CreateContext() is the problem? In my case, this is the problematic line.
https://github.com/xBimTeam/XbimWindowsUI/issues/62 In that issue someone wrote that there is currently no solution to get CreateContext working in unity. Does someone work on a fix?
It is not a bug in xBIM to be fixed. To my knowledge, Unity uses Mono runtime and its own assembly loaders. Our target platform is Microsoft .NET. If you find a bug in xBIM on our target platform we will fix it. Otherwise, you can try to request some help from Unity developers or community.
Ok thanks alot for the answer. I thought of the same that it is a problem of unity. I heared that unity wants to drop mono in 2018 so I'm looking forward to that.
@martin1cerny Your point is only partly valid. Mono support is being dropped in Unity and the latest stable build (2018.1) has full .NET 4.x support (otherwise NuGet support would be anything than functional nevertheless). Even with using the .NET runtime in unity leads to that error without any further debug notice.
The fact that you don't get any debug information is still down to Unity environment. We do invest serious effort in making all exceptions meaningful. xBIM Team is not able to help you with any aspect regarding Unity. If you provide us with test case using VisualStudio + .NET without Unity we will investigate the issue. We can keep this issue open if you want in case somebody from community can help you. But from my point of view it is not an xBIM issue.
as @martin1cerny says it's not something that could be resolved from xBim side. I think it's an issue due to unity environment etc... By the way I didn't try to use Unity in a 2018 version but from my memory the mono stuff isn't dropped in 2018.1 but will be dropped later this year.
So @Dschoni my simple solution was to have an external project independant from Unity that just create a wexBim file. Then I just read this wexBim into Unity (in this way I'm avoiding the CreateContext issue) and I can continue parsing the geometry based on the wexBim content. It's not the best that you could do but it's better than nothing.
But right now, I'm changing my way to do and I will only read the ifc file and recreate the geometry into Unity without generate any context from xBim.Geometry. In this way I will do a single pass to generate all element in Unity.
@liszto We have to differentiate between Mono developer (the IDE) and Mono the runtime. We are already using the .NET runtime and scripting API inside Unity, but that still leaves the CreateContext() non-working. ÌfcStore.Open() works and manual recreation of meshes from the primitives also seems to work, although it feels kind of an unnecessary workaround. We are going to try your wexBim approach next, as this seems to be the easiest way right now (as generating geometry from ifc directly seems to lead to strange rotations and pivot transformations due to unity's coordinate system). If you're interested to share your thoughts on that, you can contact me on my public e-mail.
I takes real effort to interpret IFC geometry for Unity. It's not impossible, though. I've got a good part supported directly, using only XBIM essentials. For FacetedBrep and some related classes this works. But beware you need to do your own triangulation to make polygons usable in Unity.
As to the transformations... I've had to do some effort with the rotations and still have to take Project Units into account. But it's doable as the LocalPlacement maps nicely to the Unity Scenegraph with hierarchical Transforms.
`using UnityEngine; using System.Collections.Generic; using System.IO;
// Beware > Xbim targets .NET 4.x ! using Xbim.Ifc; using Xbim.Ifc4.Interfaces; using Xbim.Ifc4.MeasureResource; `
It's a lot of work... as you need to parse transformations, styles, shapes... For meshes, I interpret each "face" as a separate mesh and merge them afterwards. I stay independent of the other libraries, because they seem to bring in too many dependencies for Unity. I'm trying to remain cross-platform.
Just to have an idea @stefkeB how many times it takes just to reach your current code state for the rendering with Xbim + Unity ? ** nervous laugh ** Cause you had to rewrite some OpenCascade method, from what I can read in the xBimGeometry logic cause Unity jsut ignore all those fundamentals related to for example Union / Intersect / and many others geometry things.
I try to estimate the time that it could take to have a complete rendering engine in unity based on xBimEssetials stuff and it's quite hard to see the entire scop, I think you have one, cause you progressed a lot on this question ?
Well, I'd argue that amount of geometry covered by XbimTessetation in xBIM Essentials is only very small subset of geometry types available in IFC. We use OpenCascade in xBIM Geometry to do the heavy lifting part. If you are going to implement from scratch what we did in XbimGeometry and what had been done in OpenCascade project I would guess months of work are a reasonable estimation. Assuming you are already good at analytical geometry.
I was planning to share my work - probably as part of my blog, but time is not on my side. The "easy" part are FacetedBrep and related geometry. A simple extrusion is also feasible. But as always, the wide variety of other types of geometry is a problem. And there I'm encountering problems with macOS incompatibility. The whole "Geometry" module is not cross-platform (it even includes VC2012 dependencies)
That's why I try to drop entierely this geometry module, if we talk of the same thing that is the entire xBimGeometry module. And only create stuff with pure Unity+C# logic. My ETA was september but when I see all the stuff I have, I think I will postpone it a bit..
The OpenCASCADE geometry kernel could indeed be used to resolve most of the geometry and feed tessellated geometry (meshes) to Unity. Creating a full geometry kernel in Unity is NOT what I'm doing.
In C++ I use IfcOpenShell which also applies OCC as kernel. This is cross-platform (at least on Desktop platforms Windows, macOS and Linux - iOS and Android seem to not be fully supported. I just wonder if the XBim.Geometry module is not too widely defined. I was hoping to use some of its features to just get tessellated geometry to be fed into Unity from it, but I cannot even use the module on macOS due to dependencies on VC libraries. But I don't know why these are needed... Maybe that is a precompiled OpenCASCADE library? I'm not sure. This may require re-engineering to make the module more modularised.
So, if I understand what you say just above, you succeed by importing the dll :
- Xbim.Geometry.Engine.Interop
- Xbim.ModelGeometry.Scene
- Xbim.Geometry.Engine32/64 and use them ""without any issue"".
I suppose you don't use the CreateContext method that creates NotImplementedException issue in Unity. But you use other method to use all the OCC stuff and manage in an easy way all the tessellated geometry stuff. I prefer ask this, just to have a global view of what it's possible to do without rewrite entierly the openCascade kernel (Even if I think it could be better than interoperate with C++ element). If I can use OpenCascade first it will be my first step. Then when I will have something functional, I will maybe think about that.
Concerning the VC2012 dependancies stuff, maybe in the last OpenCacscade version, this problem would be sovled if you use the one from the current project it's only a 6.9 whereas the last one that @CBenghi will use will be 7.3 (from what I saw). Maybe this issue would be fixed (There are grounds for hope [or not]).
So we're working on some x-platform (netcore) port of XBIM. "Watch this space" and xBimTeam/XbimEssentials#213. However this doesn't yet include XbimGeometry, because of the native code in OCC (p/invoking etc). This is going to need some thought. For now, what most people are doing is isolating geometry processing in a background process to generate wexbim (or other mesh structures)
As an FYI: we've built a PaaS service that does IFC -> Wexbim (& semantic) that we can make available on a commercial basis (thru XBIM Ltd). DM me if interested.
@andyward that's exactly what I currently do here (external background process). Glad to hear all that X-platform stuff by the way :D
Hi everyone. Maybe I'm late, but I managed to solve the problem of context crash in Unity I wrote a support console (.NET Framework) program which just do the convertion from .IFC to .weBIM. In Unity I choose the file to convert, it write a temp .txt file to pass the path and call the support program than read the .txt and convert the file. Then Unity opens the converted file and parse the geometry.
@Wolgraph i did this as a temp solution which is now my main solution :) cause I have no time to try something else. So yeah, your solution is the right one ;)
@liszto I started studying C#, xBim and Unity a month ago, and as I couse understand this is the only solution unless this tool is made compatible for .NETCORE I'm going to write a new Issue on here and I'd like you to give it a look, since I've read you are pretty into Xbim and Unity, too.
unity can't load /clr dll, can load /clr:safe . The Xbim.Geometry.Engine is /clr
unity can't load /clr dll, can load /clr:safe . The Xbim.Geometry.Engine is /clr
Hi there. For everyone coming up to this point in the future: That's it! A very good comparison on that topic from a Unity forum poster: https://answers.unity.com/questions/1216201/import-mixed-assembly-managed-ccli-dll-plugin.html
My suggestion so far, referencing this idea:
Maybe I'm late, but I managed to solve the problem of context crash in Unity I wrote a support console (.NET Framework) program which just do the convertion from .IFC to .weBIM. In Unity I choose the file to convert, it write a temp .txt file to pass the path and call the support program than read the .txt and convert the file. Then Unity opens the converted file and parse the geometry.
--> I did the same, but you don't need to write a wexBIM file. You can actually write the wexBIM to the standardOutput (SaveAsWexBim uses a BinaryWriter anyway) and redirect this output to the calling process = Unity engine. So you get the wexBIM file as a BinaryStream, which you can parse directly. No need for text file or even disk writing. I'm still in the process of parsing the wexBIM file - has anyone some code already in C#? Maybe I'll post mine afterwards.
However, I have some suggestions to the xBIM-Team:
- Document the wexBIM format, it's quite powerful and unique!
- Would you mind creating a C# parser/opener for the wexBIM files? (maybe even IFCStore.Open(wexBIM))
- Is there a way to create the Xbim.Geometry.Engine with the /clr:safe flag? I know, the issue is Unity and not xBIM-related, but supporting Mono would be awesome for your library!
Very late to the party but has anyone tried running it while allowing unsafe code in Unity? https://stackoverflow.com/questions/39132079/how-to-use-unsafe-code-unity (bit dated but principal stays the same)
