Segfault when using raycasts with latest commit

[frutas-fruit]

crash when using latest commit

I've cloned the latest edyn commit and tried building my raycasted vehicle demo. But I get a crash as soon as the ray's intersect the terrain. When I run GNU debugger on the binary, I get this error log when it crashes:

0x00005555557e7f78 in edyn::intersect_aabb(edyn::vector3 const&, edyn::vector3 const&, edyn::vector3 const&, edyn::vector3 const&) ()

I've also run valgrind, and get this error log
valg.txt.zip
Not sure when the last stable commit was, but I've found some older edyn files dating to around early march which work without that crash

[xissburg]

Are you loading the triangle mesh from a cached binary file or from obj? If loading from binary, delete the cache so it can be regenerated from the obj. From the stack trace, the crash is not happening during raycasting, it's happening on collision detection at edyn::collide(edyn::polyhedron_shape const&, edyn::triangle_mesh const&, ...).

[frutas-fruit]

If loading from binary, delete the cache so it can be regenerated from the obj

Ah I didn't think of that! That's now solved my issue. Thanks !

[xissburg]

Perhaps a solution to this would be to write a version number to the cached files and regenerate them when the version doesn't match the library version. I'll add that task to my to-do list.

[frutas-fruit]

Perhaps a solution to this would be to write a version number to the cached files and regenerate them when the version doesn't match the library version

Yeah, I had ideas of something along those lines, but related to checking if an obj file (with the same name) has been overwritten. I.e. sometimes I make changes to the original obj file and overwrite it with the same name, but the actual binary cache file doesn't get updated, as it only creates new binary files based on new obj file names (given that the binary file doesn't exist). An easy solution would be to simply check the 'last modified' date of an obj file, and store those dates in a separate txtfile. Then when the app is executed, it checks the last modified dates for any differences -- if that condition is met, then the old binary cache file is deleted and a new one is generated.