…and then maybe something that can interpret Bi materials and automatically approximate them in cycles/Eevee
If Cycles development continues there will be no need to replace it in ten to fifteen years. Vray has been around for a while and is still up to date.
Fifteen years is a very long time though. Back in 2004 I had just purchased a copy of XSI Foundation 4.0 and a lot has happened since then.
BI may have served well, but it’s simply a piece of junk held together with duct tape and glue under the hood. A very valiant attempt was made to clean it up and bring it up to modernity during Durian, but it ended in spectacular failure - the resulting builds were so buggy that none of the contributions from that period made it into master. I doubt any programmer would want to touch it today even if you paid them in full out of your own pocket.
The fact that you shipped BI stuff so recently that you still need to support it is a bed you’ve made for yourself. BI had been in maintenance mode since 2.6 so it was obvious that it would go away at some point.
Besides, if you only need to do tweaks once in a while, using 2.79 for that is not so bad.
I did this in Cycles… looks Blender Internal to me.
If you don’t have the money to fund this, then you need to be charging them extra for software development costs. That’s how that works. If YOU are paying out of pocket for THEIR benefit, then something is wrong with your pricing structure.
The tech of CG moves at a brisk pace.
All that to one side, from what I’ve heard, one of the reasons that they moved to Cycles as a new render engine was that the code for BI was an almighty mess. They tried to improve it with Sintel and decided that a clean slate was preferable.
Having that mess in Blender, and more importantly, having to support it on all code going forward, is a burden that will do more harm to Blender than good for a few users.
It is counterproductive to expect BF to put energy into bringing back BI.
The BI code is open source, and anyone is free to revive it, but the Blender Foundation developers have an excellent trajectory of new technologies with 2.8, and they are rightly going to focus their energies there.
Therefore, it is more productive to talk about the workflows and visual results you miss from BI and 2.79 and ask (and suggest) how to achieve or re-introduce those with 2.8 and Cycles / EEVEE / LANPR / FreeStyle.
So let’s take that productive discussion to another thread, and let this thread die.
Adding BI to 2.8x equals:
if someone for fun got involved, bringing it back as an external addon, and reshaping it to be used mainly with the nodes, and optimizing it for modern maths, making it more modular and optimized for parallel computing … and adding that I know a pseudo denoiser-deep learning algorithm’s or even making use of gpu functions to speed up some processes … it wouldn’t be bad
and yes, reinvent the wheel, but with all the comforts
… after all it was all in all a scanline that did its dirty work
from all that spaghetti monster code something could be good … or not?
for some good coders it would be a good gym
You are asking someone (for free I imagine) to spend weeks, if not years, to de-spaghetti the code, then add nodes and create a plug-in architecture so that it can be added like Eevee and Cycles as a separate entity.
All this for a renderer that is in no way comparable in either speed or capability to either of the new kids on the block.
I’m not a programmer, but I imagine that if you were tasked with creating a general scanline renderer, you’d want to make something that was useable by a lot of people in different situations. Remember, that Cycles was designed to be used as a renderer by other applications, and is currently in use with C4D. Why would you spend all that time to create a scanline renderer that specifically aped all the problems, restrictions and conventions of BI? You’d want to create something that was streamlined, fast and modern.
You are probably going to have much more success by listing what it is in BI that you can’t do with either Eevee or Cycles and seeing if someone can write a module or plugin to cover those bases.
Modernizing something like BI is a choice between two paths. One ends in something like Cycles, one ends in something like Eevee. There is no place for a slow, ugly scanline renderer in 2019. PBR and NPR aren’t mutually exclusive, as Disney, SPI, DreamWorks, and others have demonstrated for over a decade. If you can’t pull off the results or speed of BI with a modern renderer, it’s not a failure of the renderer, it’s a failure of your skills as a technical artist.
I can tell you as a developer you are absolutely correct. Because I happen to work with Blender code every day its not the spaghetti that gets but the lack of documentation.
Blender code has some documentaiton, mostly outdated in some cases by more than a decade and some code comments but not enough.
This is by no means specific to Blender, even for me that I love to write documentation I have to admit its a lot of work at time but a necessarily evil if you want people to use your code.
Lack of documentation is so bad that almost defeats the purpose of a software being open source.
Lack of documentation and lack of funding is why 99.9% of open source software does not last more than a year before it dies.
On top of that in order to get Blender Internal in you will need not only good coding skills but also very good diplomatic skills because that poor guy that will take this marathon will have to also convince the Blender devs that BI should be included in with his enhancements. Problem is because when one contributes code to Blender it immediately leaves his hands and blender dev take sole responsibility of the code , maintaining it , upgrading etc. Thus usually they refuse to allow things to get in. The things that they do allow is with many compromises.
Now imagine how hard it would be to allow a thing that they thrown out to go back in. Make this thread 1000 posts long it will still be not even close to 0.001% of that possibility.
What the user wants can never come on top of what a developer wants. I dont see many developer wanting to revive Blender Internal any time this millennium.
Hasta la vista Blender Internal.
Even with good diplomatic skills, I don’t see why a cleaned up BI would go back in anyway.
A cleaned up and modernized BI would almost be a copy of Eevee but with some raytracing features. That might be useful for some people, but it would actually be easier to simply look at giving Eevee the ability to do GPU-powered raytracing for the materials that the latest in shader-based scanline tech. can’t easily do (which isn’t actually a whole lot besides glass and complex volume shapes).
you are assuming that here there is only fatigue and wasted work … what do you know, maybe there are people who might find it fun to order and renew an existing code, I don’t say that it has to go all the way if it starts a job, but at least try to look at the code …
you find everything in a folder, it is capable of launching renderings without an interface, and probably the most spaghetti monster part is the part of the GUI … which in that case would cut the bull’s head, transforming everything into nodes, if I had the skills I would try to fix it, it would be a unique opportunity to understand how certain mechanisms work, blender internal rendering, it will also be old, but we cannot say that it is not already solid. Probably the blender devs have made the choice to deprecate it, because of the gui, and the fact that they have preferred to economize, since EEVEE is able to do the same things for the most part …
personally I like to solve puzzles for fun and also like challenges and I would dare if I had the skills …
the first thing I would do would split all the rendering code from the GUI, and create a sort of interface based nodes … and then for fun, where I could, I would start replacing the single functions with equivalents of the GPU … I would initially have a hybrid working and I would like to do the total conversion, if it is possible to do it, calmly … and be sure, that to a novelty of this kind, probably many others would soon start to participate. where there is fun and the ability to learn there is no waste of time.
You are not only talking about refactoring the code base, but also about modernizing it. What would the purpose of that be? You would end up with something like Eevee or Cycles, maybe somewhere in between.
It would clearly be doable, but at the same time, it would feel like wasted time, because pretty much no one would use it. It would likely be more efficient to just start from scratch once again, especially if you are also talking about modernization.
I fail to see what the benefit would be. Solving puzzles is cool. Doing that on a project which is actually being used or has the potential for it is amazing. The gap which was produced by the removal of Blender Internal is almost closed. There are certainly difficulties with old files, but spending time on a migration script would be better spent in my opinion.
I think you have a strange idea about what constitutes ‘fun’. If you think you can find someone to go ahead with this, then maybe start a go-fund-me or start something over on rentacoder.
If you come up with something, then don’t expect it to be folded back into Blender. None of the devs are going to want to make this officially part of Blender again. I’m not a dev myself, but I can tell you that pretty unequivocally. This would be a stand-alone render engine that would exist as an alternative for people who like this sort of thing. It would be something you download from github and install as an addon.
I agree. I think two renderers is enough for any application adding a third that has no real benefit would just muddy the waters.
Look the BI wasn’t even that good of a scanline renderer let alone a raytracer. If anyone were to write a renderer for Blender “for fun” it would look and work nothing like the BI, because the BI wasn’t (imo) very well implemented in the first place.
The issue is when people say they want the BI, they don’t want the BI, they want the BI workflow and features back. There is a difference. I think the best approach is just to add some of those features into the new rendering workflows.
imagine it being headless and using equivalent GLSL nodes to all cycles nodes?
that would make it 100% a external render without effecting the codebase.
BPR, this thread has nothing to do with realtime rendering or bge. Please stop injecting bge into this conversation.
rendering in blender internal headless based on a shadergraph of cycles,
would be a way to include internal without adding a gui.
your not understanding, I am talking about a addon basically with a binary.