Generating a Mesh
I'm attempting to implement Marching Cubes with Raylib-cs, but I ran into some serious problems trying to figure out how to properly create a Mesh struct. I started by trying to recreate Raylib's GenMeshCube() function in C#, and quickly ran into a lot of issues crossing between managed and unmanaged memory.
Is there a simpler way of doing this? Or would I be better off implementing this section in C?
Currently the bindings are not ideal in places like this. See [this issue] (https://github.com/ChrisDill/Raylib-cs/issues/9) for details.
You can Marshal the data or use Span<T> around it. I tried Span<T> before as a test for the mesh vertices and it seemed to work as expected although I am no expert so I can't help much on this.
I used SDL2-cs as a reference when learning how to make the bindings. I originally tried to avoid needing unsafe code although it might be worth trying a version with raw pointers to compare against and see if it is easier to use.
It may be easier to do in C with the current state of the bindings. Feel free to give it a try and see if it is better for your use case.
Hope this helps.
It's frustrating, but I appreciate your hard work. Raylib is fantastic but getting it building smoothly in Visual Studio is a pain, and I'm really partial to C# over C or C++ for anything that runs on an OS. Raylib-cs has absolutely spoiled me since I was able to pound out a simple 2D game that outperforms Monogame by a wide margin.
For now, I'll have to improvise. I'm hoping a more elegant managed solution will come about with the move to 2.6, but I'll take whatever I can get.
No worries. I'm glad you found the bindings useful!
I want to improve it at some point. I have seen some improvements in 2.6-dev that should help like changing the fixed arrays to pointers which means I shouldn't need to use the fixed keyword anymore.
@StevenGann Any updates on this issue?
In the end I decided to drop the idea of wrapping IntPtr variables internally because there are different ways to access/modify them. That said, since IntPtr is a common issue for new users I think adding some documentation about it is a good idea.(See #56).
@ChrisDill Sorry, I don't check GitHub notification often and am more accessible via discord.
No progress on this. I'm currently unable to even get the majority of the examples running, let alone innovate on new things. I've been sticking with 2D until someone figures out how to get 3D working.
Hey hey, i am also interested in this feature and did some experimenting... @ChrisDill I saw your Issue for 'GenMeshCustom(..)' on the raylib repo and then added the bindings to Raylib-cs. I have never worked with spans before but this did the trick:
MeshFlags flags = MeshFlags.GEN_MESH_VERTEX | MeshFlags.GEN_MESH_TEXCOORD;
Mesh mesh = GenMeshCustom(3, 1, flags); // mesh is not yet valid
Span<float> vertices;
Span<float> texcoords;
unsafe
{
vertices = new Span<float>(mesh.vertices.ToPointer(), mesh.vertexCount * 3);
texcoords = new Span<float>(mesh.texcoords.ToPointer(), mesh.vertexCount * 2);
}
vertices[0] = 0.0f; // v1 x
vertices[1] = 0.0f; // v1 y
vertices[2] = 0.0f; // v1 z
vertices[3] = 0.0f; // v2 x
vertices[4] = 0.0f; // v2 y
vertices[5] = 1.0f; // v2 z
vertices[6] = 0.0f; // v3 x
vertices[7] = 1.0f; // v3 y
vertices[8] = 0.0f; // v3 z
texcoords[0] = 0.0f; // v1 u
texcoords[1] = 0.0f; // v1 v
texcoords[2] = 0.0f; // v2 u
texcoords[3] = 1.0f; // v2 v
texcoords[4] = 1.0f; // v3 u
texcoords[5] = 0.0f; // v3 v
Rlgl.rlLoadMesh(ref mesh, false); // we can now use the mesh
Model model = LoadModelFromMesh(mesh);
Maybe it would make sense to add the "wrapping" to Raylib-cs, such that all unsafe code is hidden in the library? Or just add some lines to the documentation about this and let users implement their own wrapper classes... What is your stance on this?
@Crydsch The data for the mesh is public so you can make custom wrappers if needed. I might add some functions for creating Span types but I need to experiment with them more first. Either way adding some documentation about them is a good idea.
@StevenGann @Crydsch Sorry for leaving the issue for so long without updates. I think for now the suggested idea of Span is the way to go though utils are still needed and I have been undecided for too long on what that will look like.
Decided to close this issue and open a new one #179 to focus on ideas for this and get feedback starting with Span then maybe GenMeshCustom or something similar to it.