Large performance difference from Blender
Closed this issue · 13 comments
I'm finding that for many scenes, there's a big difference in performance between this package and creating the navmesh in Blender (which also uses Recast). For example, here's a moderately complex model:
Running Node.js locally, it's taking ~30 seconds to build the navmesh. But in Blender, the navmesh is built almost instantly, well under 1 second. Any idea what that would be? I've tried making sure all of the build options match in that comparison, thinking maybe a setting like maxEdgeError
was the problem, but I think it's all the same.
Thanks! I'll try that soon.
Can you provide those build options to help reproduce the issue?
Haven't had the chance to build with the macro yet sorry, but I'm using the settings here:
https://github.com/donmccurdy/aframe-inspector-plugin-recast/blob/master/src/recast-config.js#L2-L7
Oops, my mistake — it is the .load()
step and not the .build()
step that is taking a lot of time. When running this as in your code above, using the OBJ file path, I get a segfault. When passing the OBJ content directly into the method, it finishes but takes about 70 seconds:
recast::load: 73371.859ms
recast::build: 221.387ms
recast::send: 1.096ms
Maybe Blender is faster because it doesn't need to parse an OBJ file, and has direct access to vertex data?
Looks like all of that time is spent on rcMeshLoaderObj::readBuffer
, so yeah, parsing OBJ is slow. 😞
Maybe what I need is a load()
function that accepts a typed array of vertices and faces, since I already have that information in my application. Thanks for your help debugging, I will understand if you don't have time to optimize loading for this case!
Yeah, currently there are two methods to load the OBJ data:
- Read the OBJ file directly
- Passing the OBJ data as a string
How about load file like this? I will switch this one in next commit.
Hm, I don't think I know why reading the OBJ file from disk would be faster than passing the OBJ data as a string? I tried that just now and it did parse quickly, but also returned an empty navmesh... not sure why that is yet, will try to look into it more tomorrow!
Seems like there are something wrong with the format of the string you send ,
probably is face
part. 🤔
It doesn't matter, the load()
function will support array after next commit!
It's dramatically faster (comparable with Blender) using 4ef3b3f, thank you for your help! This is working great. A couple ideas if you'd like to make this easier to use for other developers, although for my specific needs it's perfect now. 🙂
- Consider separate methods for load options:
recast.loadContent( 'v0.5 0.5 0.5 ...' );
recast.loadFile( 'myfile.obj' );
recast.loadArray( position, index );
-
Consider making the triangles 0-indexed, or documenting that they're 1-indexed. That part surprised me.
-
Consider publishing to npm. I published @donmccurdy/recast for my personal use, so it's easier to deploy to servers, but an official version would be even better (and I'd be glad to replace mine with yours if you'd like).
Thanks again!
In any case this issue is fixed. 🎊
Thanks for your advice, it will be better in next version!