search

gradientspace / geometry3Sharp

C# library for 2D/3D geometric computation, mesh algorithms, and so on. Boost license.
http://www.gradientspace.com
Boost Software License 1.0
1.7k stars 383 forks source link

Mesh deformed after Import #87

Closed Jan1902 closed 5 years ago

Jan1902 commented 5 years ago

I have tried importing a mesh using the instructions in the article "Mesh Creation and Spatial Queries with g3Sharp". Importing doesn't throw any errors, and DMesh3.CheckValidity() finds it to be valid as well. But when i try to do a RayCast, also like explained in the article, it doesn't hit anything. So i tried exporting the mesh to check how it looks, like suggested. Originally the mesh looked like this: 941bc10e8d56103686b793387a3549e0 After importing and exporting the mesh like explained, it looked like this: 6e761138426dd83527b0e7784f9020a5 This explained why the RayCast wasn't gonna hit anything but i couldn't find an answer to why it is getting deformed like this on import.

Is there anything I might have missed in the article ?

rms80 commented 5 years ago

can you post the file you are trying to load?

Jan1902 commented 5 years ago

https://www.file-upload.net/download-13415556/MainSceneExportedNavMesh.obj.html

Sure, here it is. Might be broken, but at least in the editor it looks fine to me.

Just tried a different model, and it worked just fine so it is most likely some problem with the model I was using previously. Probably because it is a NavMesh exported from Unity using a simple script. It might contain something that throws g3sharp off.

rms80 commented 5 years ago

Whatever software you exported from, exported with commas instead of periods as the decimal separator:

g ExportedNavMesh v -49,33333 0,08333334 -42,66667 v -42,66667 0,08333334 -42,66667 v -42,66667 0,08333334 -49,33333 v -49,33333 0,08333334 -49,33333

You can try setting StandardMeshReader.ReadInvariantCulture = false, it may read correctly. But then if you try to load a normal OBJ (with period as decimal separator), it won't work properly.

Jan1902 commented 5 years ago

Oh, thanks a lot :) I didn't think that was gonna cause a problem, because other editors handled it just fine. Changed the script to export with dots now and it works. Happy to mark this as closed then :)

rms80 commented 5 years ago

many editors don't handle this at all...which means as long as you export and import in the same locale, it works fine =) It's if you exchange files with someone in period-separator locale, then it's a problem. (So you might find that these other editors won't import your period-separator files properly.)

It is a tricky problem because nothing in an OBJ file explicitly specifies the number formatting. The only way to tell is to scan through the file and make a guess based on text analysis, etc like statistics of commas vs periods, etc.

Most files "in the wild" use a period separator, so that's what we assume as the default