Rather than continue to hijack a previous thread where someone was asking a question, I thought I’d start my own.
Was able to try this out recently. May be the best solution yet. Had been using the old Bridge.NET solution for some games, and it worked but it was… difficult.
Was able to pull in Monogame.Extended, FontStashSharp, and Spine animation libraries just by changing monogame references to KNI Engine.
Very very easy to get my regular Monogame project working.
Curious…
What are the plans for this?
Are there other differences w/ Mongame?
Will this continue to be its own thing?
I think I ran into my first NotImplemented when I ported some bounding box code for models. It was VertexBuffer->GetData(). I don’t know if this is something that webGL has or not and so may eventually be added.
Im curious, Did you pretty much just have to rebuild MonoGame.Extended with the reference to KNI or did you also have to change headers to point to nkast.Xna for that to work?
Im slowly working toward a web build but I have a pretty large project. Im hoping to try and move most of my client code to my shared library.
One Extended feature I am worried will give me a hiccup is MonoGame.Extended.BitmapFont. i remember reading another user having an issue with that and I have it pretty heavily embedded now.
WebGL is based on GLES 2, which doesn’t support reading data from VertexBuffers.
You can create Bounding boxes from the Model.Meshes[i].BoundingSphere, or use the sphere directly. (Unless you care about MeshParts bounds which the api doesn’t provide).
You can use the RawModelProcessor, which places the Vertex and index arrays into the ModelMesh.Tag property.
I originally wrote this for a similar situation when porting a game to Android/GLES.
Ideally you can fork the importer and move your bounding box calculation code to the pipeline instead of performing it during loading.