search

mariuszhermansdorfer / SandWorm

Augmented Reality Sandbox for Grasshopper & Rhino
MIT License
20 stars 11 forks source link

Test making slower functions asynchronous #53

Closed philipbelesky closed 3 years ago

philipbelesky commented 4 years ago

Some of the operations in SolveInstance() need to happen in a serialised order, while others are somewhat non-linear. The most important of these is probably the call to CreateQuadMesh which can proceed as soon as the pointCloud is processes as the mesh is not referenced further until the end of the definition, or if a relevant analysis requires the entire mesh as a parameter. Shifting that call to be asynchronous might help performance (particularly when using a relatively slow piece of analysis) as each code path can run in parallel.

This is just an idea for now, although I know c# has good async/await support. There may be further scope for using asynchronous paths with the renderBuffer or perhaps even scope to split out the mesh construction and mesh coloring steps so that each can proceed asynchronously (assuming that would be faster than having a single step).

mariuszhermansdorfer commented 4 years ago

Like the general idea, let's see how much can be gained through this approach. I've been toying with another low-level optimization recently. Essentially what we are doing, is updating the Z coordinate of a mesh on every tick. Rather than clearing the whole list of vertices and replacing it with a new one, I wanted to access it directly in memory and replace the Z coordinate. I think I'm onto something here, but unfortunately I keep breaking the mesh in the process. The issue seems to be related with SandWorm having to operate with a mesh.Vertices.UseDoublePrecisionVertices = true; flag, even when supplied with a Point3f array of points. With this set to false, even our current approach fails.

Here is the branch and the relevant discussion thread.

Any ideas on how to fix this @philipbelesky? The results are very promising, full array of vertices takes approx. 1ms to mesh

image

mariuszhermansdorfer commented 4 years ago

Fixed the issue. Giulio from McNeel pointed me in right direction. I always worked with a "Large objects - Meters" template, which has a precision of only 2 decimal points. Apparently this was too little for Point3f to work. Check out the results, @philipbelesky. Sweet, right?

image

Next step - we tackle the contour lines (#15) - it is the biggest resource hog right now.