If others are willing to implement the plugin architecture I personally have no feelings towards, it misses the point that I was trying to push forward. I do not want blender to change or to start focusing on game developers, I know that's a fool's errand. What I want to do is very simple to explain.
Take all the core c files dealing with the blender DNA/RNA data structures and refactor them so that anything that needs access to those data structures can just include those header files and deal with the DNA/RNA data structures, that would include loading, saving and accessing anything within a blender scene. Pretty much exposing a specific subset of the python api that deals with the scene, model, materials, nodes, etc... only exposing it at a lower level from the c api. Once that's done anyone could use blender to design their levels, use the c api to write out some data in whatever format their engine want's to consume. It's not turning blender into a game engine, it's just allowing blender to export it's data in different way. If the core of blender is refactored in the way that I am suggesting, it could be like this: https://www.blender.org/api/blender_python_api_2_76_2/info_quickstart.html without the cons and using the c programming language. Although I am mostly interested in the aspects dealing with the scenes, materials, cameras, etc. Best, Owen On Wed, Jan 27, 2016 at 1:06 AM, Ton Roosendaal <t...@blender.org> wrote: > Hi Kai, > > The open movie datasets were never available for download, to save > precious blender.org bandwidth. These were sold as DVDs in our store. > Helped to make Blender! > > The costs you had to pay for 1 movie project DVD box ($34) is higher than > 3 months access to download every movie project in cloud now ($30). Cloud > uses a commercial CDN for this. > > You only pay for the service, it's all free data still. Share and use it > as you wish. > > Obviously the issue is not about the money you would have to pay for > plugins, it's about reducing the functional scope of the core software > project (free & public benefit) and forcing users to start shopping to get > stuff done (commercial or 'free' plugins). This infrastructure would invite > crippling and 'evaluation' plugins and deliver you to the mercy and moods > of vendors who will likely not consider public benefit as important as > Blender Foundation does. > > -Ton- > > -------------------------------------------------------- > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > > On 26 Jan, 2016, at 14:57, Kai Kostack <kaikost...@gmx.net> wrote: > > > > Hi, > > > >> Secondary: plugin architectures are popular for closed source > environments, or > >> semi-open environments where the goal is to build a commercial > infrastructure > >> for plugin vendors. That is not something I believe will serve our goals > >> better. Did you check the "open fx" plugins? It's a disaster, plugins > adding > >> watermarks over your art telling you to pay them first. > >> > >> But I can be wrong! Revive K3D or Moonlight3d - all plugin > architectures who > >> claimed Blender to be a disaster 12 years ago already. I would love to > see > >> competition and see other approaches to make 3d tools work well. > > > > Technical aspects aside, I think it's the strong leadership what made > the Blender > > project big rather than the lack of an efficient plugin system. The > argument that > > reduced flexibility of Blender should scare proprietary business models > away > > appears somehow weird to me. That's what I read between the lines here, > but I can > > be wrong though. What is the purpose of the Blender Market then? Also I > honestly > > dislike the idea of putting the open movie project datasets, as best > > educational source on how to use Blender out there, behind a paywall, but > > that's another story. While I understand all the difficulties associated > with > > financing a stable development of Blender, I would consider this > rationale for > > not having a plugin system debatable at best. > > > > -- Kai > > > > P.S.: I don't like watermarks on art either though. > > > > > >> Gesendet: Freitag, 22. Januar 2016 um 21:13 Uhr > >> Von: "Ton Roosendaal" <t...@blender.org> > >> An: "bf-blender developers" <bf-committers@blender.org> > >> Betreff: Re: [Bf-committers] blender as ui for game engine > >> Hi, > >> > >>> During Blender conference 2015, the question was raised why blender > did not > >> support these ideas or projects, Mr Roosendaals' reply was: "if you > want that, > >> you will just have to create your own community" (I am paraphrasing > here, but > >> it is essentially what he said) > >> > >> Well obviously there's a rationale for not going for a plugin > architecture. As > >> for any concept, there are pros and cons related to Plugin > architectures. > >> > >> Blender's architecture is not plug-in based at all, and that's > purposely so, by > >> design. > >> 3D Max - for example - was designed ground up with a plugin > architecture. > >> > >> To convert the current design into a plugin architecture is not a > recommended > >> project. It will conflict too often with (old) designs. You better > start from > >> scratch with a new design then. > >> > >> Secondary: plugin architectures are popular for closed source > environments, or > >> semi-open environments where the goal is to build a commercial > infrastructure > >> for plugin vendors. That is not something I believe will serve our goals > >> better. Did you check the "open fx" plugins? It's a disaster, plugins > adding > >> watermarks over your art telling you to pay them first. > >> > >> If we want to have a true free/open source creation environment, we > have to > >> make sure that the program works without needing a plugins externally. > For > >> everything, the whole pipeline. On top of that we can make sure that > this > >> environment is extensible and configurable. Addons and occasional > plugins then > >> can help with it, but can be limited to expert cases or special use > cases. > >> > >> But I can be wrong! Revive K3D or Moonlight3d - all plugin > architectures who > >> claimed Blender to be a disaster 12 years ago already. I would love to > see > >> competition and see other approaches to make 3d tools work well. > >> > >> -Ton- > >> > >> -------------------------------------------------------- > >> Ton Roosendaal - t...@blender.org - www.blender.org[ > http://www.blender.org] > >> Chairman Blender Foundation - Producer Blender Institute > >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > >> > >> > >> > >>> On 22 Jan, 2016, at 19:49, hewi jupama <h...@jupama.org> wrote: > >>> > >>> How I love this discussion, you (may) know me. > >>> > >>> Allow me to again write you too many lines for people not to have time > to > >> read ;) > >>> > >>>>> What part of Blender's C core is neglected exactly? > >>> > >>> How funny you are asking. have you ever looked at the creator.c file, > the > >> first and most basic file from blender, where it all starts: > >>> > >>> if (G.background) { > >>> /* actually incorrect, but works for now (ton) */ > >>> WM_exit(C); > >>> } > >>> > >>> auch, that is when I say +1 for me. And literally, this is just the > start! > >> The blender C core code is riddled with these comments and hacks and it > needs > >> lots and lots of refactoring. If you don't agree or see that, mmmh ... > ? (don't > >> know how to put that nicely so I wont put anything :) > >>> > >>>>> However the purpose of the "Blender" project is to: > >>>>> "build a free and open source complete 3D creation pipeline for > >>>>> artists and small teams." > >>> > >>> You are however absolutely right, the blender foundation wants to > provide "a > >> tool for ... " It is very important and a real privilege to see blender > is > >> sticking to these goals. Many projects fail because they divert from > their > >> initial goal! > >>> > >>> We are discussing the preparation of the blender source code for 2020, > to > >> make it extendable and easily maintainable. To make it stick to the > current > >> conventions and guidelines on coding and project management (e.g. the > >> ubiquitous right hand rule of XYZ Axis as a main source of sadness > every time I > >> open blender). This, apparently, has nothing to do with current blender > vision > >> nor it's goals. I see that now (I was involved very closely in the > Blender > >> Plugin System (BPS) discussion). > >>> > >>>>> we're not looking to prevent you from trying this. > >>> > >>> But you're not providing much of support either. I was actually > prohibited by > >> Mr Roosendaal himself to discuss the BPS system on the developer irc > channel > >> "as it is not a supported project from the blender foundation". Well, > that > >> makes me very sad. > >>> > >>>>> But *expecting* this will be accepted into master isn't reasonable > >>> > >>> Exactly wright and 100% correct yet again. During Blender conference > 2015, > >> the question was raised why blender did not support these ideas or > projects, Mr > >> Roosendaals' reply was: "if you want that, you will just have to create > your > >> own community" (I am paraphrasing here, but it is essentially what he > said) > >>> > >>> So basically, any discussion to refactor blender's source should be > taken > >> offline or elsewhere online, until the dev's and Ton see the benefit > and are > >> convinced of the relevance. > >>> > >>>> That's why I sent this email out to the group to see how many people > would > >>>> be willing to support me while I did this but the response seems less > than > >>>> luke warm, although I might be totally wrong. > >>> > >>> I had this idea already somewhere Dec 2013. My idea was to create a BUI > >> (blender user interface) and extend that using a plugin system. > >>> > >>> > >> > http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/BUI_BlenderUserInterface[ > >> > http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/BUI_BlenderUserInterface > ] > >>> > >>> > >> > http://blenderartists.org/forum/showthread.php?319727-BUI-BlenderUserInterface&p > >> =2528068&viewfull=1#post2528068[ > http://blenderartists.org/forum/showthread.php?3 > >> 19727-BUI-BlenderUserInterface&p=2528068&viewfull=1#post2528068] > >>> > >>> My intention to achieve this is still not just luke warm but boiling > hot. > >> Despite all the ice cubes that were thrown in my path. I have source > code ready > >> to be reviewed. I just need a place to drop it and we can start > developing. > >>> > >>> If you look through the spaghetti source code and all it's circular > >> dependencies, you will find the source is not that hard at all. It of > course > >> needs time and a good initial set-up. > >>> > >>> throw me a private line "h...@jupama.org" to discuss future evolution > of this > >> idea. Discussing it here will only cool you down. > >>> > >>> KR, hewi > >>> > >>> ps: Again i have though hard and long and over and over and doubted and > >> re-read and re-phrased before I pushed the send button. But, freedom of > speech > >> in mind, I finally did. > >>> _______________________________________________ > >>> Bf-committers mailing list > >>> Bf-committers@blender.org > >>> > >> > http://lists.blender.org/mailman/listinfo/bf-committers[http://lists.blender.org > >> /mailman/listinfo/bf-committers] > >> > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> > http://lists.blender.org/mailman/listinfo/bf-committers[http://lists.blender.org > >> /mailman/listinfo/bf-committers] > >> > >> > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers