 it should be okay it's me in Russia and that just work and blend the foundation but I'm not sure if it's blend the foundation Blunder Institute I'm confused so shall we start yeah so just get started so yeah let's wait for someone to come in still and yeah okay so let's just get into it so let's talk about what was happening last year and we count years from the Blunder Conference apparently so since previous Blunder Conference we've been working like on infrastructure stuff which is not so visible for everyone but which took like quite a reasonable amount of effort from like me Campbell and Brecht and we switched basically from SVN to Git we're still not sure if it's like everyone is happy with this but for us it's works pretty good you know it was also like some awesome tracking improvements like smaller one and some improvements in other areas like animation and yeah I also work on well one of the biggest projects was OpenSubdiv it should be covered later and I've tried to pick up cycles and it still gets like it's not the easiest thing in the world you know so yeah still trying to to influence I think significantly there but yeah there was lots and lots of more smaller issues smaller stuff done so in today's presentation we will talk about dependency graph a little bit the no technical specification because last year it was like I was throwing all the technical stuff into the presentation so hey it's good but at the end of presentation everyone was like yeah feel sleepy so we'll also like cover like motion taken development and OpenSubdiv things so dependency graph I mean it's actual dependency graph from tears of steel it's actually a small part of the dependency graph from the tears of steel file and okay it's actually ongoing project which I picked up like a couple of weeks ago and my goal is to make rigors and animators happy and yeah it's let's keep technical detail and okay so what's the issues current dependency graph it's currently only capable of representing like huge data blocks like objects and object data without hacks you can hack something in pretty easily but it doesn't work and it's not scalable enough for us and it basically makes it so seen update function has no idea in which order to evaluate like bones and which makes artists really unhappy because the rigs doesn't work for the reason they don't know and those are unaware of material of such a better blocks as materials and textures which makes some stuff complicated for texture painting and for physics as well so how are we going to solve this well going granular so basic idea is to generate part so we generalize dependency graph make it sure like understand like different types of nodes and node would be would be representing like smaller part portion of the data in blender we could stress like current dependency graph is this feature but I don't think it's the way to go and we'll probably just learn the new dependency graph in because at some point we would need to do this anyway and trying to stress current code would just mean like duplicated work so some details so basically node could be correspond to different ID blocks such as objects materials whatever else it could also be portions of objects such as bones and it should be like make natural way to to represent this in dependency graph and nodes would have like callback which would make sure that that data which this node corresponds to is up to date when the scene has been updated and for this nodes would also need to encapsulate some context or some data needed for evaluation that also would probably require a requirement for better proxifying in blender and yes in a bit would switch from one genetic function to call of like individual nodes callbacks that's the idea anyway so how are we going to handle this basically poor current dependency graph into like new system as this which would make which would help us making sure that the new system works good and it's like way to go and we probably will use a previous work from just along and Thomas look at stone who work on the dependency graph refactor branch basically I still need to clean it up on but that's not interesting and once we're sure that the new dependency graph works with all the ID blocks and stuff like this we'll go to granular and mind focus would be to make sure that the rigging tools work as they expected to be and then we'll just continue is making the nodes more granular and solve the remaining issues it kind of a bit different from the approach in the current branch because it tries to solve all the issues at the same time and it's kind of scarred me like hey what is something goes horribly wrong then it wouldn't have like working blender so just the smaller steps but anyway that's I think all four for the dependency graph and next thing would be like wasn't tracking which is much more fun I think so there was quite reasonable amount of smaller stuff implementing such as weighted tracks and Sebastian is Sebastian here by the way oh here you are so he showed this already so he's tall and like half of the presentation probably and yeah we also like made some improvements and speed up to camera solving can bundle adjustment well bundle that is just like refining the position of cameras and the thing which makes the projection error really small the ultimate couple of improvements in planner tracker and they also worked in some more rubber making some parts more robust such as feature detection it's this made actually that the new feature detected made the feature detecting slower but it detects more robust features you might wonder why but there is dance floor because we move to all fully automatic tracking pipeline so basically the gigantic green button which you press once and it gives you like perfect solution and yeah basically that the current issue of the tracking integration into blunders that motion tracking algorithm has no idea what's happening in the scene already so we just tracked one track from frame one to frame two and did forget all the information and the way to to support a full automatic counter tracking thing not be to make it so tracking algorithms have all this data needed for the things so mean here we're working on Amsterdam in May making landing a new pipeline into LibMV and agreeing on all the IPA and stuff like this and they made it pretty much working like it's basically at this stage it doesn't have any improvements currently but like visible for user for for developers of LibMV would mean that hey I've got all the data needed for all the fancy algorithms and one of the results is the predict predictive tracking which Sebastian actually demonstrated yesterday and he didn't explain why it's so fast but basically LibMV currently predicts the position of track on the next frame but some of the history of tracking and it does pretty good job because prediction is works like to error value of like one pixel or so like one to three pixels is expected like prediction error of the LibMV and this basically allows to avoid like doing quite brutal initialization which is a really slow thing and internally it currently uses really stupid Kalman filter for this and quite impressed that it works so good and yeah it speeds up things in most of the cases and also should make tracking more accurate and currently it's a branch which I think is ready to be merged into master and it'll be in 2.73 so the plans for motion tracking would be to finish new auto pipeline finally green button into Blondard. I would definitely need that Canadian guy here Mieril for this and the new pipeline also allows to solve multiple clips like the same action from shoot it with multiple cameras like witness camera or motion capture cameras it also supports survey data like naturally so LibMV can access all the data it needs to use the survey shot and all this data will also make sure we would help making solver more robust because currently for object solver you've got like some accidental flipster because of the lack of depth information feels like getting being able to access tracking history from solver would help preventing this but it's just like pretty tiny bit of little things which would be possible with new pipeline things so we'll get gradually to the project and yeah next thing is well open sub diff it's I don't know it's a simple dragon probably should have copyrighted this with Blondard Institute Creative Commons things anyway so what open sub diff is about well basically just integrate open sub different Blondard what could possibly go wrong but hey internally it's a little bit more complicated benefits would be real-time viewport subdivisions if some circumstances I met because open sub diff is expected to be like in particular pipeline and it does more accurate cut no clerks subdivisions which probably is not so visible for for artists it's but it definitely has much better crease support and two more features which can be questionable at this moment because we are not ready for them yet it's feature adaptive subdivisions and camera space adaptive subdivisions so open sub diff is expected to be used just to make like FPS as high as possible basically it's I'm to be used by animators not modelers because it's only fast if you've got a deformation applied on the mesh if you change topology of the mesh then open some Disney to pre-calculate some more some extra data and store it again and it's just like extra overhead it doesn't give any speed up well it's the same speed as current modifier but if you only apply like information to pause the character or so it's really fast the policy changes are possible just wouldn't give any improvement apart from better craziness and it relies on GPU satirizations so it means that only viewport can benefit currently it's not it's not something which would be like possible to access directly from CUDA or so it's just different aspect of the issue so what are the challenges currently Blender is like really old open jet open GL and open sub diff relies on new open GL features it wouldn't be an issue for six wooden forces to not combine all the new open GL so we first we would need to solve to finish the viewport upgrade branch to make sure that to be able to use all the features from open sub diff and another issue that Blender currently in some areas it's realized that all the data from derived mesh like final representation of the object is all available on CPU which is not anymore true for open assembly because it's all GPU there's some limitation of open sub diff currently such as like non-money folds for example doesn't support like loose edges it's just not possible to pass loose edge to open sub diff adaptive divisions is something which how open sub diff is expected to be used but it would open kind of force for animations because it would mean that at some point like UV could like flicker a little bit and with open sub diff it's not possible with open sub diff it's solved using Ptex so Ptex is good to have in Blender anyway so eventually I think we could go feature adaptive no I mean it's all doable just needs some more time so current state of the branch is that so far we used open sub diff 2 and the recently open sub diff 3 was announced which brings like major updates which Blender would benefit a lot because currently it does have quite reasonable amount of overhead just representing like data it creates like intermediate storage and passes it to the GPU and all it's just like non-memory efficient and with new IPI it would be possible they also reduces number of CUDA kernel calls or any kernel calls which presumably makes subdivision even more fast which is good so I don't feel like finishing integration of open sub diff 2 and I will just wait for open sub diff 3 to be like finalish IPI and then continue with integration and currently it kind of works and it's supported on CPU side still some small issues to be solved on CPU side yeah what we're going to do is to like switch to branch 3 of the open sub diff which as was mentioned before and the proper integration of GPU pipeline thing which should also like rely on the viewport project because currently it's a little bit hackish and I'm not entirely happy with that and it's also acts a little bit of a dependency graph because sometimes you need to interact with OpenGL context from object update things and currently it's not so trivial to do and there's a little bit of hacks and it's also probably was wrong idea to support two subdivision surface algorithms because it acts like a bit more overhead and makes code more hairy so probably just like get rid of world one real challenge and stuff would be to support like open sub different cycles like natively so because most of the engines currently I just distillates on CPU and passes like higher as much to to bvh but I think it was there are techniques to to intersect the rate with the subsurf like directly so you don't have a triangles in bvh you've got like limit surface in bvh and we intersect right with the limit surface it should be possible it's a little bit tricky but ideally that's what you want but wait there is more because they've been working some project with martin burger if I pronounce you correct what it this is it for the part but it should work and basically yeah it sits for tone apparently and what is this is a bug a matter thing which uses nixie tubes to display current number of open bugs in the bug trap it's a little bit damaged because it's all the part while I was bringing it we will glue it together we will glue it together again but just hold it like this and if it has like internal connection it works it has a wife line yeah it has a wife line well I'm not sure if it's gonna to find a wife line here because we didn't set up we just put it in but yeah that kind of goes yeah that's the goal it's well yeah but it should be a little bit set up again because of the barrel is dongle thing but once it boots up and finds the Wi-Fi it will display actual numbers it's well yeah so just call it so this is basically an open hardware project so all the files and schematics and PCBs would be published somewhere yeah can we have a blender cloud thing for this yeah cool yeah I think yeah I think that's it do have some questions no questions well what I mean circles talk Thomas covered cycles like yesterday why would I talk about it again I wanted to didn't want it to be like long and boring presentation you know I wanted to be short and yeah so I don't know it's just like would happen eventually somewhere in the future so we will keep like gradually to the outer track pipeline does it work yeah so then because I already asked that you already answered I was just thanks for and for for being awesome and doing okay then we stop the day session we have a little break yeah thank you thank you five minutes or 10 we will start the open podium open stage the lighting talks I've heard we've got like 24 night show buddy on the list might not have everyone but you never know what we will try with that I get the microphone to all the film so yeah I was actually saying five minutes break yeah