== This week ==<br>* I spent Monday tracking down and fixing some bugs in the tracker at last. There are still a few more important ones that need attention (namely tracking down a rather fiddly crash with GraphEdit handle transforms), which I might need to give priority to fixing given the current plans for wednesday 2.5-beta tagging...<br>
<br>* Manipulator API<br>On Tuesday, I put together design doc for this (link posted on blog). After discussion with Martin, I've rethought the system with updated doc (not yet uploaded to web). Coding currently in progress...<br>
<br>* Bullet/Simulation Stuff<br>- Hooked up a few more properties for the simulation and started first round of tweaks to the UI.<br>- Implemented Convex-Hull support for 'Mesh' collision shapes. The demo video I posted of this seems to have gathered quite a bit of interest.<br>
<br>* Constraints<br>I started setting up the constraints API on the Bullet side, but ran into some roadblocks considering what parameters/methods to expose. <br><br>Investigating the "Rigid Body Joint" constraint (which is in Blender already) for clues and hoping to reuse it left me a bit confused. There seems to be some fairly dodgy stuff going on here with the two object references, "Target" and "Child" but only one of them really seems properly supported. When comparing to 2.49, "Target" is really the "toChild" field, but yet in the code, there are checks for both of them. Hrmf! <br>
<br>Also, while scoping this out, I had a few second thoughts about the original workflow here as mentioned in the design doc, as <br>1) Flipping between Constraints and Physics panels (Constraints comes before Physics, though these constraints are more subsidary to the Physics settings) isn't actually that great. It breaks some of the organisation principles behind the Properties editor, and also is not that obvious.<br>
2) Making sure that everything will still be stable/valid under this approach is tricky, though we still wouldn't want to <br><br>As a result, I'm currently re-evaluating the approach here... Progress here will continue only when I have clearly mapped out and resolved all lingering issues surrounding this. <br>
<br>* Pointcache Support<br>I didn't get around to working on this yet this week. <br><br>From preliminary investigations, it looks like the most direct option is to extend the PTCacheData to include 4x4 matrix dumps (as I'm currently using to get data out of the physics engine without worrying about coordinate system stuff + less conversions to and fro). That will bloat the size of pointcache files though, so more investigations pending :)<br>
<br>Linking into this, I did a few experiments into handling duplis (which I'd previously postponed work on to get things working). However, I still wasn't really satisfied with aspects of the approach yet (confusing setup requirements being one of them :/), so I stopped work on that, saving out a half-finished patch to look into again with some fresh ideas later. <br>
<br><br>== Next Week ==<br>Lectures start again next week :(<br><br>Targets for this week will be mostly the same as the last week - i.e. working on the main fronts listed here. Having said this, I think I'll concentrate coding efforts on getting the Manipulator API up and running, and work on getting making sure we have solid approaches for the other issues pending.<br>
<div style="display: inline;"></div>
<div style="display: inline;"></div>
<div style="display: inline;"></div>
<div style="visibility: hidden; display: inline;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}</style>