Morphing Init is Memory-Unfriendly

[jnsnow]

Zach, do you think it's possible if I could ask you to reference-ify all of your arguments? We started a little bit last week, but do you think that's something you could look at?

It makes this code really, really slow and it makes debugging problems that occur after initialization hard to look at.

[zmaybury]

I'll look into this. I definitely can accomplish making it more memory friendly, the only inhibiting factor is how much of a rewrite the rest of the code will need to accomplish this. I'll work to have in done in time though. On a related note, we now are using two models that perfectly match each other, so by default I think I should change the morphing so that it holds on to all the final matching buffers, and then we can add a UI toggle for showing "automated morphing" which will then swap in the new verts/norms/colors that show the morphing algorithm output. We would have to keep all those points in memory however, like we're doing now. What do you think?

[zmaybury]

Moved rectangular mapping into its own struct with the ability to move back and forth between original mapping (which now morphs perfectly) to the calculated auto mapping (427935e). I will work on the UI elements of these tomorrow when I see Franck. I will try my best to address memory issues as well.

[zmaybury]

Ok so looking at it more, most of the "slowness" comes from having to loop through all the morph target vertices in a given section for each vertex in the original model. There may be a way for me to optimize this, maybe a smarter way to eliminate father away points before calculating the distance, but this is where the init slowness is coming from.

As to the memory usage issues, I will look into it, but a quick glance at the code, and the only memory that I use beyond the objects, which I use pointers to, is I store the morph match final buffers (verts, norms, colors) before the call is made to copy these back to the objects. Consequentially, the lasting memory footprint should only be a little more than 2x the original buffer size (When I swap in the morph match buffers, I store the original buffers in case we want to switch back to the original model matchings.) Does this make sense or am I missing something memory wise?

Thanks

[jnsnow]

OK, no worries. I can always comment out the morphing if I need valgrind again. :P

On Sun, May 5, 2013 at 11:42 AM, zmaybury notifications@github.com wrote:

Ok so looking at it more, most of the "slowness" comes from having to loop through all the morph target vertices in a given section for each vertex in the original model. There may be a way for me to optimize this, maybe a smarter way to eliminate father away points before calculating the distance, but this is where the init slowness is coming from.

As to the memory usage issues, I will look into it, but a quick glance at the code, and the only memory that I use beyond the objects, which I use pointers to, is I store the morph match final buffers (verts, norms, colors) before the call is made to copy these back to the objects. Consequentially, the lasting memory footprint should only be a little more than 2x the original buffer size (When I swap in the morph match buffers, I store the original buffers in case we want to switch back to the original model matchings.) Does this make sense or am I missing something memory wise?

Thanks

— Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/75#issuecomment-17453571 .

[zmaybury]

Is the comment out of morph init a temporary thing that I can re-enable?

[zmaybury]

Never mind my last comment. I made a commit that keeps the morphing init out of init, and instead calculates on demand if the QT checkbox is selected.

[zmaybury]

Morphing Init step is still unfriendly, but it has been moved out of MONOLITH_init and done when needed instead.