 So I'm also not going to say anything new, really. What I will try to do is to map out what I think we should do. Map out what I think what we have been doing and why I think we should be working on a 2.8 project. I wrote about that online. It is on the code.blender.org bloke. You can read about it. I will try to summarize things we've been doing. So my first topic is to talk about three myths. So people usually say a lot of things about blender. I would like to point out that, for example, easy to use. I think that's a myth. Intuitive goes it. Blender is a awful piece of crap, but maybe that's true. But that's also a myth. But people say it all the time. So what's going on? So if people say easy to use, I say, here, this is totally easy to use. You lie down, and you relax, and you have a great time. And everybody can use it, and it is awesome to use it. So easy too many times is the synonym of lazy. And if you want to be a 3D artist, or if you want to be in any creative profession, you have to be prepared to work and work hard, make long days, train yourself, and become really good. Because making 3D, and especially if you want to be on the edge of what's possible, because we are competing with the best of the world, the best software of the world. That means the things are not always easy. But things can be simple. And I think that's what people usually mean. So when they say easy, they usually mean simple. And simple is really a different concept. When something is simple, it is usually really hard to make something simple. People who make film and say, well, I want to have a story, I want to have a plot. How do you make a simple plot? Or how do you make an interface simple to use? Simple then means that it becomes more predictable, or it's consistent, or it has the right, small, flexible building blocks, which you can immediately grasp, and you think, aha, I only have to learn this, this, this, and then I can create a complete universe out of it. That's the simplicity. I always try to get that and keep that in mind. So easy, not important. I don't mind working hard, but it should be simple. That's important. So intuitive. So this is for people who don't know, this is 3D Max, which is totally intuitive, according to most people, because it is industry standard, right? Everybody uses it. The people who say, well, intuitive, I want intuitive software, they mean I want Blender to look like Cinema 4D or Maya or Max or whatever. Or they talk about this. So are you driving on the right side of the road, or are you driving on the left side of the road? I mean, many things are coming down not to things that's intuitive, but it's basically conventions. So what are you used to? What is it, what you have learned before? And that is what makes you like or use software. So conventions are not bad, but it's good to understand why a convention is important to understand. So it's not about the intuition, which is some kind of a magic thing people get born with. It's about something you learn. Sometimes it is good to demand people to learn things because learn once, use everywhere. So once you know one thing in Blender, you should be able to apply the same knowledge in other areas. It's an important thing that makes it intuitive. On the other hand, what you see is people who use different types of software a lot, they might have problems to adjust from one program to another. And it is very justified for them to say, I want software to adapt to me. I don't have time to adapt to other programs all the time. So the crap thing. So I couldn't find worse screenshots. I tried Googling for Blender screenshots and you get those kind of things. For people who don't know Blender, they might think, oh, too many buttons and weird things, I have no idea what this program is doing. I know whatever this screenshot is doing, but maybe for you it's new. But what people usually see is that the interface of Blender, especially if you load it or you try tutorials, it's very difficult to find out when it works or when it works half, or when it works really good, or whether it was meant to work this way or whether you are working with a bug. Because in Blender, that can be dynamic, right? We release every two months and then there's a bug and then there's something working and something else breaks. As a user, especially the new users, have no idea. Even when I start a Blender, I sometimes have no idea what's going on. Like, what's happening here? Is this a bug or did a code purposely do this? And that's what some users make that what people think Blender is a piece of crap because we do have a lot of those issues. On the other hand, we also have really well-defined design rules and good paradigms. And I think the score is good once in a while to go back to those design rules or paradigms, really look at it, remove the dust, maybe tweak it a bit or add a couple of new ones and then build further on it and communicate it really well because if you understand what is meant to work, you can learn Blender much more efficient. So go back to Blender 2.5. In 2008 or so, 2007, the 2.5 concept popped up. And I think it was almost in a similar situation as what we are in now because we did have the project working, we were making 2.4, 2.4 something and everything was like, yeah. So we are moving lots and lots of problems to the future because we can't solve them now. And that's not good, it doesn't make it a pleasant project. You see the bugs and the problems piling up and we can't help people anymore. So we really have to stop doing this and try to go back to the drawing board and define what we want to fix, what we want to keep. If you go to the weekly section, the development documentation, you can still read a lot of docs about what we did for 2.5. Don't know if people can see it, but there's stuff about how the design was or what the core principles are or how the event system is working, how the windowing system is working. So those things were actually good docs, but I think one of the reasons why we did survive this enormous project because it took us two years to get 2.5 to a working level was also because we really well knew where to go and how to go there. So it had a clear goal and a clear mission and everybody could collaborate on it. So let's go looking at a couple of those original 2.5 pallet digms. Some of them were already originally going back to the 90s when I was a designer in Blender. The first three, non-overlapping, non-blocking, and non-modal. People understand this mostly, but I still want to talk a little bit about it, but non-overlapping is clear. I mean, interfaces, when they start having 20 windows everywhere, it's not really helping you. It's only stopping you from working. On the other hand, the Blender interface based on subdivisions sometimes makes it not easy either because if you very rigidly only allow subdivision, it also doesn't always work. But it's a good starting point, and then you can make users, so you give the users the freedom to pop up a window if they want to, like for a render or a file render or whatever. But for the rest, your interface would be a quiet screen of options which you should use. The non-blocking is more difficult to understand, but you can see this also as a non-overlapping being adopted in, like, every interface now. That means if you do one thing, you shouldn't be stopped from doing something else. If you move a vertex in a model and you think, oh shit, I have to fix that bone over there, and then you paint something and you make a note or you work on a shader or you set a color. And Blender, whenever you want to do something, you can. The interface shouldn't stop you from doing something. Other software, especially in the 90s, decided that they have to split up in modules. So you force the developer or the artist to think in, okay, I want the model, then I'm going to texture, then I'm going to animate, and when I want to go back, I have to close the software, I import things in a module, and then I can go back to my modeling part. So that's not what you want. The other thing what 2.5 did really well was the fact that if you use a button, you slide values, that the interface keeps working. Even when you start rendering, the interface is responsive. So whatever you do, the interface should stay responsive. I'm the biggest hater of progress bars. I hate progress bars. And that's not because I don't like progress bars, but I don't like the idea of people having to wait for software. They shouldn't. Never. If you start a Blender, it should be there. You have to load a file, it should be there. If you want to do something, it should be there. If you want to render, then you have to wait for it. You should show that in a way that you might continue working while rendering is happening in the background. That's non-blocking. Non-modal doesn't only mean that if you pop up a request there and the interface stops working, that is traditionally non-modal. Non-modal also means that you don't make a user switch. There are usability between modes. So when you are used to click and drag and use your mouse gestures and other things in one place, it should also work in other modes. Whether you are modeling, painting, editing, whatever you do, you shouldn't be forced to rethink your way of working all the time. Sounds very logical, but a lot of software designers make that mistake. And they make even things like escape keys or clicks or middle mouse or right mouse, doesn't matter. But if you make something consistent, the way of your working, the human way of working becomes possible because things become second nature. You don't have to think, oh shit, I pressed a key, but I'm now in this mode and that came in something else as in another mode in Blender where you can use the same keys. You should try to limit that because it's really frustrating that you cannot train yourself and get habits in software. But those concepts led to a couple of other things, like the select and then operate order in Blender is coming from this normal mode principle. Because if you know Maya, if you want to move something in Maya, you first say, I want to move, and then you go to the interface and you move stuff. And if you want to do something else, you say, I want to do something else, and then you go to the interface and you do something else. Which is very easy for people to learn, easy again, but it's not very efficient. It tops you from walking, plus it packs things model because for every tool option, what you do on the interface gives you a different result. So you always have to think, oh shit, I'm in that mode, so what I'm doing now, we're giving this result. Now I have to go to another mode and I do the same thing and I get the result I want. So that makes it confusing. In Blender, we decided to flip it. So you first select the data you want to work on, face it, vertices, objects, or some other, and then you operate the tool. The second thing was an experiment, 2.5 data doing that, because we wanted to have a fast workflow, so you should be able to operate immediate, and if you are not happy with the operation, you can redo it. You have to redo operating panel on Blender. That's something we could review because it does work, but it also sometimes is very clumsy. Some people want to apply a tool with a preset. I say, okay, I want to extrude in this type and not first do something and then go back and tweak it, right? So this is something we could look at. I don't like it. It does help you to create a fast workflow. The other thing, the separating tools from properties, I think we did that quite well, to hold tool bar is not finished in Blender. We should work on a real tool bar. It's still useful to have it, but I don't know if people remember in 2.4, tools and properties were mixed in the interface. So you had all the properties, the tools and properties, and they had to find your way around where everything is. So we solved that in 2.5. Two things I added myself, it's on the wiki, but Blender is installation free. It's not an interface choice, but I hate installations. I hate a lot of things, bad things, like progress bars, but installation is even worse. The most stupid thing ever is installation, right? Why do you install software? I don't know. I'm not a programmer, I write software, but I don't know what I'm doing, but I don't want installations. That's stupid. So everybody who is developing here, and people who is listening to this video, do not install, right? Let's agree on that, because users don't like that. I don't like it. I don't think anyone wants software to mesh with your system. So you should be able, and it's possible even, to plug in your USB drive with Blender in a computer and run it. That's it, that's how software should work. And the last thing, yeah, Blender is for artists. Very obvious. But there are developers who think maybe different, you know? They think, well, yeah, but Blender is also for me, you know? So, now Blender is for artists, really. So if you develop something, if you want to make a new viewport, for example, developers too easily go into the technical, APIs for points, something with that kind of buffering and things, it's going to be awesome. But then where is the user? Where is the artist? So it's always good to have a goal in mind to say, okay, there's a user, he has a viewport. And what does the user want with the viewport? How are we going to help game designers, for example, or animators? What do they need? And then go back to the technology. But the same is for scripting. So scripting is awesome. Add-ons, great. But it is there to help artists. And we don't make a scripting language for developers like Python. So, that was the paradigms. Is it clear so far a little bit, what? So what can we do in this conference in the next month? Yeah, look at the concepts. I wouldn't mind hearing from people what they think or how they perceive 2.5, what they think was a good move forward and how we can keep moving forward. What is it, what we really have to do to make it and keep it working? But be realistic. I mean, coding takes time. And unfortunately, every time you want to make another step, it becomes like 10 times more complicated. So this is the typical thing a development manager will say. If a developer says it takes two days, plan four weeks, right? And when a developer says this takes me two weeks, you can better plan four months. So you double things in an exponential way. So when somebody says four months, it's probably eight years or something. And then don't do it, right? So that's too long. And that's not so much of a making fun of developers thing. It is because sometimes you really have to realize that making something, for example, the particle system, I was talking about it today, I think the first particle system I coded in a week, that's to blend the particle system before YANA coded a decent system for Big Mac Bunny. And that was several months of work in full time. It took them a year, but two months of full time work. And then for the last gooseberry project, we tried to make a new particle system which would have everything we want. And then we decided, yeah, but that will take us too much work. We cannot do it even in two years, right? Or maybe with two people full time, two years, we'll be able to handle this complexity. So this is typical in every company. If you talk to software development companies, they know that once you want to move up, you sometimes have to triple your team and double the amount of time to do it. Same as for us, if you want to get amazing awesome software with lots of features, yeah, but do we have the people on the time and the money to do it? So let's try to keep things feasible. For example, a complete new data design, which is possible for Blender, which would completely change everything, maybe wait with that. There's a couple of other things. If you say, well, if you want to really redo all of those things, then the time to survive it will be so long that we won't do this, won't help us. Yeah, and then we have a couple of unfinished 2.5 tasks which we have to do. We can talk about that like configurability, like come back to that. So this is why I thought, okay, let's start a 2.8 project. I mentioned it this morning because I saw that the main and the key developers of Blender were a little bit complaining and bugs and just review and another bug, another release. It was getting boring a bit, but also they didn't have time to do anything they really wanted. It was only maintenance and the little cycles of making Blender a little bit better, a little bit better. It is really good, it's very stable, very proud of what we do, but it didn't feel exciting anymore. There was not so much interest or vision anymore, but so a lot of lack of direction and also I think a lack of empowerment because nobody knows who decides things. That's really true. A lot of people are empowered, but it is difficult to make decisions, especially if you have to be compatible all the time. You have to drag like 15 years of history with you in Blender and every step you do has to be compatible with like a thousand other things, which is not very efficient. So that's what I thought, coding holidays. So the developers now can sear and say, where are you Ray and stuff? Where are the developers? So yeah, they don't believe it yet probably. They think, oh my God, do we have to do all of that to get coding holidays? I mean, I thought holidays was meant to be fun and relaxing, right? What it is? I mean, that's how I will try to make sure that the developers will have a fun and relaxing time. So the coding holidays, I mean, that's what I did when I wanted to do something big. I shipped myself to a little island somewhere without internet and then after a week I get bored, really bored and then I start coding. That's how you do it. If you get distracted all the time, it's impossible to do big things. So I hope that to like, you don't shut down the book tracker, but mentally you could shut down the book tracker and don't look at all those discussions anymore but give the developers, the people in our team, months. I don't mind how long, but they give them time to think and think and rethink and get bored a bit again that they feel like, okay, now I can do something bigger. So that's the workflow thing. So why workflow? I mean, one is of course marketing because who is against workflow? Anyone? What? Dare to be against workflow? No, that's not possible. Workflow is a great marketing and a great term to get people excited because everybody wants workflow. Right? Yes, I thought so. So workflow is hip and cool in the marketing of other 3D software. If you look at Maximira and all the guys, they don't talk about features anymore because everybody has cycle style renderings and open sub-divs and all the new viewports and all the things, software is almost finished. People, it seems like as if the software is done, they can do millions and billions of polygons and nobody expects you to do even more polygons. So what people focus on is workflow because workflow counts and workflow is not a bad thing because workflow is about what starts in the morning and what you have at the end of the day or what starts at the beginning of a project and then you end up with something and you want to go from A to B in the most efficient and fun way. You have pleasure, it's efficient, it's inspiring and the tools have to work with you. That is good workflow. I think the workflow theme will help us to tackle a number of targets in London. And I think we can limit it to six key topics which will help with people's workflow. So that's the viewport, people understand viewport, talk about that. The interface tools and configurability topic, that is object modifier physics, the everything notes thing, you can probably not do everything but we should have more notes. The asset management and pipelines, the logic editor, because I still people making games with Blender and don't forget about it, and the interoperability. I go into one of every topic a little bit more. What does viewport mean? The viewport project means that we upgrade to a modern version of OpenCL which allows physically based real-time sliders, which allows you to get shader editing, good note-based shader editing which gives you Blender internal rendering quality or better but down in real-time. This is useful for a lot of cases, but it's also useful for game artists for example, because they can mimic the way how a model or an environment or a character will look like in a game inside of the Blender interface. We have to stop having view modes. They're stupid, you have to look at workflow modes, like people who sculpt or animate or who do 3D printing, they all have different ways how they would like to configure. And so we can also look at compositing in the interface, we have to make it balanced. Compositing means even I have a real-time shadow or I own the interface, it's a compositing effect. But you can also make selection as a compositing effect. We have to make sure that those things are well-designed so that things are always working. And of course, no more wireframes. Shocked. Why not? Wireframes, of course, you should have line drawing, but wireframes are the other stupidest thing from the 90s, 80s, right? Where these people think, oh, computer interface with 3D, it has wireframes, wow, you know? Wireframes are stupid, they were there only because we didn't have anything better than wireframe in those days. Nowadays, you can have this in real time. So look, this is a CAD program bought by Autodesk last year. I still don't know what they do exactly and whether it's marketing or so, but they pretend as if they have an interface that does this in real time. And look at it, here, this. So do you need wireframes for this? If you would have wireframes for that kind of stuff, you wouldn't see anything. And this way is how you make modern interfaces. Good looking renders, but you can also combine with outline rendering and get your solid color in a way that you know what you're doing. So the people who design the new viewport should think about that, they should think about, okay, so we are in 10 years time and people are using a viewport that looks like a photo realistic environment. How do you work within a realistic environment? You should be able to. You shouldn't go back to wireframe, right? No, you can do things that make high quality viewports work for tools. So we're going back to the second topic, tools and co-figurability. What does that mean, interface topic? One, stop adding buttons. I'd say it every time to developers. If you add one button, you should remove two, right? That's the deal, otherwise you get too many. You should be able to remove buttons. But buttons are not very helpful. And if you will see the evolution of the blender interface, it's like button creep. They get everywhere. And some people refuse to learn certain parts of blender because of the buttons. And it's not because we are stupid, but if you work the current particle system or fluid and simulation, those buttons are like big airplane cockpits to control something complicated, which is very nice as a first generation interface, but we have to be able to make a step further. You should be able to use a particle system or to set up a hair system without having to learn the physics equations that are behind all those things. It's not needed, right? So those things we have to rethink. Another thing is also that we have to bring back work to viewport. So why would you go to a toolbar, do something and a fill in values, then you go to the viewport and do things? There's a lot of new tools coming up that really focus things on working in the viewport. And in reality, things work without buttons, you see? You can do all this, you can do it and move things around. I don't need anything, right? I can work on it, you can work without buttons. I think we should try to think, how can you work in the interface and create things in the viewport, I mean. Yeah, we have to end the fight over shortcuts. There is no empty key anymore. I'm sorry, we're out of it. So we have to stop. Jonathan said yesterday 95%, what was it? 98%, 95. It's quite modest, yeah. Make it 98, so. But at some moment, the idea is, let's not fight over every shortcut, it doesn't work. Let's try to, everything we fight over, we should not put it in any default, so deliver it and make it a user choice. Let's do what we agree on. And let's also do something which other software do successfully, like for example, my app will download it for the first time. It has extreme minimal default configuration which hardly does anything. So it forces you to go to madness and do all kinds of clumsy things to use the software which is not bad because that allows people to have a release update and then combine it with our own preset and still have everything work. There's no conflict. Say, good topic to talk about. Well, we have to finish the Python API. The people want to have custom editors in Lambda. If you can imagine it, I'm going to explain what it would mean. It would mean really weird things. Second, promise you that. But it's important to have it. We should allow swapping interface configurations. The most of the Blender UI is defined by Python and some other files. You should be able to say very good, high-quality ways of switching interface configurations. For example, I still would like to have a project working which I call Blender 101 which is, for example, for high school kids of 12, 14 years old, a simple tool to introduce them to 3D. Maybe only 3D printing. So teachers or educators should be able to say, okay, this is Blender. I'll kick out 99% of everything. I disable it even. So if they press P, you shouldn't want to have the game engine to run for those kids. You should be able to very efficiently remove all the options except for some of the options for testing, volume, measuring thickness and wall thickness, and the stuff you want to have for 3D printing. And a couple of preset images for the big monkey and some other animals. And people can drag and drop them and the big print button and it goes to the printer. So how would you configure that? I think this is relevant. I think it's important for us as Blender makers, as community, and as open source community to have open source tools in education. But we can only do that if you make educators happy. And as you know, we cannot make anti-educators happy and the people who make feature films. So somehow this has to become a design to swap configurations. Great example of modern tool design is what you see in Pixar Presto. And this is DreamWorks animation tool. You can Google it. There's a great video and demonstrations about how DreamWorks works with selections here. So it's a little solid highlight which allows, this is an input area for posing. You go over the face, you see a little highlight, you move it and the guy starts smiling. So this is how we work in the interface and the viewport, posing and animating. Plus having nice expressions, presets, and it works. So this is a visual interface which we can do too. This is not too far away from what we could have in Blender. And know my frames, right? Good. Okay, the notes. Everybody loves notes. A note do have problems. They're not always easy and if you have a thousand of them, you get lost. It's like programming, you know. The smart thing of notes, I usually say, is coders like it because this is how they make the users responsible for developer. But they only have to make the little black boxes and the users then create crap. And then if they say, yeah, but it doesn't work, then you say, yeah, but it's your notes system. You made it, right? The notes are working perfect. But you made a non-working note system with it. So there is a limit to it. On the other hand, notes are also very powerful, especially for things like physics, particles, lots of relationships in 3D. Notes will be doing great. Modifiers, for example, because this is how people want to use it anyway. If you see what people do with modifier stacks in Blender, it's amazing, but it's so complicated. You can do things a little bit more efficient, I think, with notes. Especially if you then allow also a nice flow that you can have data coming in, a note system. I got the modifiers and hair growing stuff. And then you send it out again. This is a little bit what Houdini does. Houdini is completely designed from scratch for this. We can't do that, but we can do, at least for the modifiers and for physics, particles. We can try to find a nice unified note system that allows this whole list of things. This is already a lot. So we do have a little bit of this already, that two pattern scripts are illustrated here. This is for generative modeling. One is for the animation notes, and two add-ons for Blender, which I think is amazing that we have a Python API where you can already make your own note system to do this. But these are great experiments. You did one? Which one? Ah, here, let me second. So we should have it as a core feature built into Blender, right? You can do C coding. Not yet, good, next year. Good. Okay, the other topic, asset management and the whole pipeline thing. We find it to be an increasingly big problem if we want to make stuff in Blender in our studio. But I think many people will find it increasingly difficult if you want to work with a little team or a group, do something bigger, get all kinds of little issues, and they get complicated and more complicated and you don't have it in control. So the dependency is on external files, images, point caches. It's not visible, it's all hanging out somewhere, and then suddenly it disappears and then it's back and you don't know where they are. There's the matter of versioning or levels. With level, I mean, you want to have a character in a low-poly version, mid-poly, and high-poly. How do you manage that? We don't have nice tools for this. There's a whole linking or referencing, and you want to share data between files and you only reference them, but that's not always simple. And then you don't know if secretly something gets copied or not, and then you lose a file and then you lose your work, and those kind of things have to be solved too. There's online repositories, there's now add-ons which you can use to get your data from a web server. We should have that while working by design inside of Blender. You should be able to connect online and get your assets from a server. Then, of course, inside of Blender, we need efficient browsing of and management of things. But we do have over something working in development. I mean, Bastien is working on it. Bastien, there's Bastien. We will talk about it. This is a view on a blunt file, what? With all the data inside, including visualization of objects. Okay, the logic system. So the current logic editor is like ancient. I remember I wrote it in the 90s, what? It was nice, and we had to redo it very quickly when we had investor money in 2000, and that's it. And when I look back, open Blender, and I look at the logic editor, it's still the same, but it didn't really change in 15 years. This is, of course, a compliment on one hand, but it was not meant to be losing that long. So we have to remove it and replace it. There's something which has all the modern logic components and ideas and concepts people know from other game engines or game creation tools. That is, which works with things like state, state engines and transitions, behavior, AI, all different concepts which you could make different editors for. And it's even more weird that there is already a paper from 2001 written by a guy who was working with me at that time to make the logic system. There's a whole design paper which you look at this here, waiting to hunting, the triggers. Look at this design, what? This is 15 years old, and he made this back then. And this looks like something you want, almost. And it almost looks like, ah, here we have something that might look like a workable logic system. So he thought about it. So we should try to work on it, and moreover we should make it work next to the animation system. But I don't think logic and animation has to differ that much. There's a lot of stuff which we want to have in the interface interactive anyway. Plus, once you have a logic system, we have a viewport, we have this amazing new physics and modifier system, we almost get a new game engine, what? And then you have a game engine which turns all of Blender into an interactive experience. What happens then? Okay, last topic, the interoperability. So Blender in non-open pipelines. It usually is not a very popular topic, or I usually say, yeah, I'm fine if Blender works in an open pipeline, because that's what we do. We make open source pipelines, right? The goal I showed this morning, full creation tool in open source, et cetera. But in daily practice, people are using Blender in non-open pipelines. And this is essential for workflow too. I don't think it will harm us to make sure that this, that is all IRO business, is part of the design of 2.8 from start. That in every part of a pipeline, in a production process, or in the studio, or in your own workflow, that you can say, okay, I love Blender, but I only want to do the texturing in Blender. Or you should be able to simply put Blender in your texturing pipeline, and then go back and use the tools you like. Or if you look at things, big people see the film with the garden gnome and the caterpillar, which is from Sassia, a good computer. It's a very nice movie, it looks beautiful. What did the guys do? They used Maya for everything, and then they export it to FBX, load it into Blender, and then it starts shading, and send it to Cycles. So the whole first half of the pipeline is in Maya, and the last part is in Blender, which is perfect, which is a really good example. And we should help those people to make those things work. I mean, I know there are people here who work in studios and who look at pipelines or replacing parts of it, or using Blender for animation or only modeling, and we should be in contact with them because I want to have a project working where people also from studios become stakeholders, because you cannot make me responsible for fitting Blender in your pipeline, because I don't know your pipeline. But you guys have to help us get in the design working and make sure we have the right format or the right way of working that you can easily replace your Autodesk crap and put in Blender here to the open. Okay, so the how. I hope I have enough time, but oh, shit. So I'm almost done. So how are we going to do this? A couple of things. So we have a 2.8 branch. We're going to have it, not there yet. That means we can still keep working on 277, 278, 279, 9A, 9B, 9C, whatever it takes. But those are smaller updates where the current projects can go to, but we shouldn't make too much problems of that. We also should say, well, everything we want to solve in 2.8, we call it not fixable anymore in 2.7. Otherwise, you have to keep fixing all the stuff while you wanted to work on something new. And we have to make radical decisions, especially on old code. Now, what are we going to kick out? As much as possible. The modifier system, the constraints, the whole game managing, Blender internal, what, you can know in my list. And people are like, ha! Well, it doesn't mean that we stop having that functionality, but we want to put something better back. And if you want to, what we try to do for Gooseberry to fix the hash system, and it brought us really far, it's Gooseberry or Cosmos Landrum, it looks amazing. But it's the end. It's really the last thing you can do with this hash system. It's not the beginning, it's the ultimate last thing, and it's a pain to use. So we should kick it out, whoo! I say, guys, we have a Blender now, 2.8, and it doesn't do anything. It doesn't have a viewport, it doesn't have game managing, it doesn't have anything. That's perfect. It's like how I started, 2.5. Do people remember the purple, green interface? Well, that was a new interface, and we took it without anything. Then we had one by one, we put things back, sometimes good, sometimes bad, but it was at least a good, fresh start. I think that's maybe a model which we should use. And in parallel, I mean, people still have 2.7, it's not like that we stop when they're still there, but if we want to make a big step, we have to prepare mentally to make a big step too. I'll also not be compatible. I'm sorry, I mean, I'm the biggest compatibility evangelist ever, I hate incompatibility, but yeah. So sometimes you have to stop being compatible if you want to move on. So why not start 2.8 with an incompatible system or physical system or modify system, but we try to convert things to make scripts that ease the pain, but it might not be fully compatible. And lastly, we spend time on organizing ourselves better. So we have to empower people, stop discussing and get to work. Okay, some core principles to agree on. I'll look at the 2.5 specs. I mentioned the data structures and stuff. I mean, we can make blender to survive like until 2020. That is when they have flying airplanes and stuff, or flying cars, I mean, flying airplanes we have already, but for the next five years, we can try to survive with this 2.8 project to make things work, keep it really work, but it's not the end. And there is a nice list of things you can add and call it a blender 3.0. I know those things already, but we don't talk about that now, right? Too much to do. And last, or not least, it has to be fun. Using a blender has to be fun, but also coding in a blender has to be fun. So have everybody on board. It's important as I work on. I want to have the whole core of the blender developers and folks, everybody who is on board. I mean, I really want their feedback. I say, yes, yes, is it a good idea? Let's do it. Or town, this is too ambitious. You can never make it. Well, then we cut half, we could make it simpler or smaller. We have to make it into something which people believe in, but they can't do it. Yeah, and then, yeah, we need more people. And probably we have to be realistic. It is a full-time job. You can't have volunteers in the weekend, two hours on a Saturday, expecting to do this whole thing. So we have to pay the bills. I can buy a lot of the tickets, my winning, or do a massive development fund campaign or move to Kickstarter. That's our topic we can discuss. And that is enough for now. We might ask, so let's have eight minutes for people who have really, really, really good questions, or stupid questions, lots of fun. Anyone has something to ask about? To clarify my stuff. Okay, thank you. My question is about compatibility from another side. When I got over from OSX Mountain Lionion to OSX, today's OSX Yosemite, all the Blender versions I had until 2.7.0 stopped working. No way. Yes, they did. I never got it working again. But that's not purposefully. Okay, no. We didn't do that, but Apple did it, right? Yes, of course, of course. But I switched to the latest OSX 10.2, and I didn't see the problems, but I didn't think try the very old versions. Oh, I didn't try with that. Okay, so what's the question? My anxiety is what L-Captain is going to do with the versions I have still on the computer. Well, I installed 10.11 on my system, and I didn't see problems. No problems at all. There was one person who said that the track path was not working in Blender. Yeah, but it got fixed, right? It got fixed in a couple of days. Yeah, that got fixed, so. I didn't do it. Okay. Don't worry about that. Okay, second question. I see a tendency in the market for more pen-enabled tablets like the Surface 4 from Microsoft and the upcoming iPad Pro. Are there intentions to do something in that direction to use more pen interface-like devices? I think the pen input in Blender is very good, right? But you could talk about that with people here, because people are using Blender with tablets all the time. Pressure sensitivity, I don't know if the Angular staff is working on it. Of course, it depends on Mac and Linux, and when those developers individually, because those things are not really compatible, sometimes it needs a bit of kicking, and then you have a Mac guy who likes to work really a little while on getting the tablets to work. So, but this is not... But I consider these topics typically part of the open source dynamics, right? So you said you needed, well, talk about it online, say, I needed, it's not working, and then somebody might say, oh, but I think I found the fix, and it is going to be there tomorrow. Or, but if people don't know, it doesn't work, right? It's a matter of making noise, and things happen, so. Okay, another. One of the paradigms you mentioned is the select operate settings paradigm. Are you really sure that we want to strive for that? Because some operations work better like knife. We already break this paradigm for knife, and... I think the knife tool is maybe not a good example, because I think you can make knife tool work like that, but I know other tools, especially for painting tools, you use a my-style interface, because you say type of brush, and then you start painting, and you switch to another type of brush and you start painting. That are good examples where you violate the principle a little bit. But this is so common and so typical, but for knife, you can talk about it later. I know how to make knife no modal, it's possible. And I think it's a good thinking, because I hate knives, they do something, and then it's stuck, right? I can't get it, it's a mode, and it doesn't let me go, right? It should not happen. And so your knife tool can be made to work in a way that it works, you cut, and that's it, right? Including having a way to make polygons without having it to stick on your mouse. If it doesn't work, of course, the design paradigms are not rules we shouldn't violate, but it's a guideline, we try to make things predictable that way. But if it fails, if you really don't know, like, yeah, but this rule is not helping us, yeah, sometimes you have to violate it. There could be a knife tool, there could be painting tools, some other tools, they get sticky, and then people say, ah, escape, okay. That's next, right? But is that what you mean? Oh, the way in the back. I'm closing. You first. I have a proposal to make an export import button for other programs, because many artists working with artists who work in after-desk programs and it's a very big problem now with animation to export import to, like, 3ds Max, good animations. It's possible to make sharing a button with other programs? That's what I try to achieve with working on the interoperability, what I mentioned, to make sure that you can mix Blender in a pipeline with 3ds Max or with Maya. For animation, that is very difficult, but we do have FBX support, and if FBX is not satisfying, you should report or feedback us on this. But it should work, but I don't know what to try to do. It's, maybe you familiar with ZBrush, if they get Go-Z, maybe some, like, this button, it will be great. I don't know about that. It's just brilliant. I really hope people will work on that, but that's what I said, I want people on board to do it for us, because I don't have shippers, I don't know why it has problems and where the problems are, but we should be able to work together on it, right? Thank you. Two or three more, and then we have to stop. Okay, pending, I don't know, those are the first. Okay, I would like to ask about the Blender asset management project, what was the state of it now? There is a presentation about it today or tomorrow, I don't know, Bastia has a present talk tomorrow. Tomorrow, okay. So you will learn more about it. Will the UI modification system be like a GUI-based for us to make our own custom UI's? What do you mean? One of the points was to make the UI more customizable for the user. Yeah, will that be a visually-based system where we can snap together our own things? I don't think you will quickly replace every button with a completely different styled button. If you mean that, that's more difficult. Well, that's not typical workflow, I think. Well, for example, in... But the positioning and the out and the size, yeah, probably. Well, being able to take elements that are already there and just reposition them in a custom way that would suit you for a particular workflow, yeah. Certainly, certainly, we should be able to look at that. That's what you need, otherwise you can't make your own editors, you can't make your own button panels and with layouts and that kind of thing. Yeah, that's very exciting. But we should be also working on the layout engine, we call it in blended, it makes layouts for buttons and it should be flexible enough for people to configure things so that you can have an interface work as you want it. And is there an approximate projected timeline for your 2.8 project? No. No, okay, thank you. Thank you. But not more than two years, I mean. But the open source doesn't work if you make things like last forever, so it's one or two years and that's it, otherwise we shouldn't do it. But maybe it's there already in May, I don't know. You really have a question, oh my God. I throw, okay? Yeah. Made it. Usually blenders pretty non-destructive, but I have a problem when I add, for example, primitives like the circles via whatever and modified via modify, just add a mirror modifier, whatever, Boolean, and can't change the primitive at the beginning anymore. If I make add a circle with 12 edges, vertices, whatever, it's as soon as I move it around, I can't edit the amount of vertices there. Is it possible to make it not destructive anymore? Then I have to delete this thing at a new one and... Okay. I thought that should be working what you said. That's not working, like 3ds Max can do this, you can just go back to the primitive, if it changes parameters. If you add a circle, you should be able to tweak the amount of vertices. Just move it around, it's not possible anymore. If you move around to what? It's a atmosphere, move it, can't change anymore. There was one student who had a great project that you could go back in history too. But currently only your last command is editable, but you should have a little stack as you can go back three or four steps. But we do order. And then go back to that step and then reapply the old steps again. That's what we should work on. But I really want to stop because you can talk to me for the ace today, tomorrow, on Sunday, Monday, and you have not talked to me, but you should talk to everybody here, right? Okay, thank you. Thank you.