BAKED DELTA MESH REALTIME IN THE GAME ENGINE!
if all the range of motion is baked, then the animation system would be lightning fast right?
This seems like it would be a huge leap…
Depends what you mean by baking. If its just baking to weights like example based skinning, then this would be a fairly fast way to get decent weight painting done on a character. I think Btolputt mentioned in the dev thread that he was considering implementing a plugin for this, which would be great.
Hey Sazerac, I just had an idea: You know how Subsurf modifier has a setting for viewport subdivision and another for Render subdivision? Could we get the same with Delta mush? It seems like if your animating your not going to want the iterations set to 100. even though that might give you the look you after.
Another thing i was thinking was that if you did that, maybe there might be some way to use a lower quality/less accurate/faster* smoothing algorithm in the viewport but at render time switch to the original-higher quality one.
Anyway, let me know if you think this is something that could be done.
*I don’t even know if something like this even exists. I’m just hoping it does. 
A render iterations isn’t a bad idea, and shouldn’t be too hard to add.
As far as the modifier panel is concerned I can see two options for this:
- just a separate field for render, would have to be manually updated
- a checkbox with the separate field, checkbox enables the separate render mode, so you don’t have to worry about keeping the two properties the same.
The smoothing algorithm is pretty simple, I don’t think much can be changed except perhaps having an option for a simpler weighting on the effects of neighboring vertices (i.e. just use average of surrounding verts rather than weighted average by edge). The thing about this though is the results will be a bit different, not exactly just a lower quality version, although may be close enough for most cases.
Okay yeah, I see. I wasn’t sure about the simpler smoothing algorithm. I thought you were using laplacian smoothing like the original but then I read your full dev thread on Blender.org. I was also thinking that there was some accuracy that could be sacrificed but now that I think about it, recursive processes like these can’t really be faked like that. The main reason I suggested this is just to increase the interactivity in the viewport. That’s all. If a simpler algorithm only gives a marginal improvement in speed, I’m not so sure it’d be worth the effort. Plus, if users hit a button thinking that it will help them get faster viewport performance but it only gives a slight increase, it’s going to feel like it’s maybe not working of something. 
Anyway, cool to see this in Blender finally! I’ll hopefully do a build this weekend if I get a chance. Thanks!
You guys are amazing ! I was waiting this modifier so much 
I will follow this thread with interest !
Nice that you took the time Jack to dig through the C source code, I can’t imagine a Delta Mush done in python that’s fast enough. I could be wrong though.
This turned up on my vimeo feed yesterday
(the video can help explain delta mush, c++ plugin for softimage)
Can’t wait until this is revised and in the master branch eventually! And it would be really really cool to start a joint effort cross suites with models and check that delta mush gives same results. Especially when alembic i/o hits blender and there might be integrated into a pipeline with softimage and other 3dcc with delta mush modifiers.
This is pretty exciting for Blender users as weighting can be a job all by itself at times… I’m commenting so that I can keep up with the info as well 
I’m pretty sure you’re in the wrong thread (either that or wrong error message 
).
Well the fact you can’t do modifiers at all in python is a bit of a problem as well. A system for modifiers as addons would be great, but given how frequently they get evaluated, some degree of compiled code support would probably be required for anything particularly complicated.
I suspect that the results will not be exactly the same due to small variations in smoothing algorithm and vertex local space calculation.
Here’s a build for OSX (10.8.5) I haven’t had a chance to test it much myself so please let me know if it work for you. As always, use at your own risk. Thanks
This is one of the most exciting things I have seen in a long time. I can’t wait to get my hands on this. I’m sure I’m not alone with my hate of weight painting and adding corrective shapekeys.
Thanks for all the hard work!
Campbell has just created a temporary branch for it to get the code ready for merging into Master
http://lists.blender.org/pipermail/bf-blender-cvs/2015-March/075237.html
http://lists.blender.org/pipermail/bf-blender-cvs/2015-March/075238.html
Considering that he’s on board, there should be a good chance this will be part of the feature set for 2.75.
Well, there was his coloured wireframes patch…
Two things here.
- There’s been a history of a patch making it into Master if there’s a temporary branch made for it, this suggests that the idea has been largely approved by the core team.
- This also happens to be something which will have an immediate benefit for the Gooseberry Project (making rigging easier, faster, and as a result, less costly in terms of hours needed).
I know that AD. It was a joke, hence the smiley
Yep, things are looking good, Campbell put in a nice effort in cleaning up my code and doing some performance optimisations.
Can’t wait to play with this optimizations. The last few commits combined seem to be a hefty percentage.
The last Sunday Meeting also indicated that Ton was very interested in this functionality (in part because things like bone envelopes will now be a bit more useful).
Campbell is pretty much the one developing this now (possibly so that it gets in master and becomes available to the Gooseberry team as fast as possible).