Blender 2.8 development thread

Could you explain how will development process of engines go? We have:
Mike Erwin’s PBR viewport with Vulcan, BGE, Armory engine and Clement Foucault’s PBR branch, Cycles, (Internal questionable).

I also don’t understand Clement Foucault’s PBR branch. Is Clement Foucault working with Mike Erwin?
I guess there won’t be 2 PBR viewport renderers.

What about @lubos’s Armory engine and BGE?

Again, the discussion of ‘artistic’ interaction vs ‘analytic’ manipulation. When the term ‘Artistic’ is used in this context, it should be understood to imply a more direct, visible relationship between what a User is doing, (Nodes, Materials, Textures, Lines, etc.) and what is seen on the screen. If it is all ‘blackbox’ tweak stuff, then render and be confused, and uncertain what worked or didn’t, then it doesn’t meet the usability threshold that is needed. It does not mean any grand simplification or ‘dumbing down’ as another thread understood this question. All of the complexity and noodling is still there to be tweaked, but for ease of usage, learning curve, and ‘artistic’ sensibility a more direct haptic/visual experience is required. I hope the Blender PBR branch or Viewport re-factoring is intended to address some of these considerations. I hope so, as the complexity increases, the access diminishes, proportionally for many user, particularly new users or newly introduced features. Hope this helps clarify??

Since when was there Vulkan development? Do you have any news articles / commit logs for this?

IIRC they were upping the minimum to OpenGL 3

https://wiki.blender.org/index.php/Dev:2.8/Viewport/Reports
There is Vulkan mentioned.

Fair enough… to me i dont think they will pursue it anytime soon, due to Mac OS X not having vulkan support at all.

There are no concrete plans to switch to Vulkan anytime soon. We’re definitely looking at it and considering it during work on code design though. Generally, the work that’s being done now adds some abstractions that will make it much easier to switch or add support later on.

Hi all,
In the 2nd half of September Blender Institute will organize a couple of 2.8 viewport sprints with invited Blender developers. We will discuss a lot of ideas and designs, but especially find out how to cooperate on the viewport project more closely - which is also possible as a BI job or with a Development Fund grant.
I expect we will come up with a high quality viewport design proposal which can be further discussed here, on the code.blender.org blog and of course the Blender Conference.
Participants will be:

  • Sergey Sharybin
  • Bastien Montagne
  • Mike Erwin
  • Dalai Felinto
  • Clement Foucault (PBR branch)
  • Lubos Lenco (armory3d.org)
  • And myself.
    Not everyone will be here at the same time though. We’ll share as much as is practical online, especially via our popular irc.freenode.net #blendercoders channel.
    Laters,

-Ton-

Be patient :slight_smile:

I’d just like to see a clear specific vision for Blender as a software package at this point. Like a 5 year plan. This whole development cycle is really just a mess. There are plenty of targets that have been missed in the past, plenty of bugs left to fix, and plenty of things that are just, wrong, right now.

Blender 2.8 - “STOP THE PRESSES” PROJECT

No seriously… stop.

At this point we’re basically SKIPPING a 2.79 release… And then there’s 3.0 looming on the horizon.

I have quite literally broken Blender multiple times in the past 3 months for various projects. Alot of this is related to under-the-hood code issues.

  • We need point clouds instead of object based particles (see every "particles are broken thread ever)
  • Blender cannot dynamically write image file names during “animation” renders.
  • Fresnel/IOR essentially has no scientific or real world bearing at this point
  • It appears some object modifiers are missing multi-threaded behavior (eg. Decimate) or GPU acceleration
  • Custom properties that are used in conjunction with drivers (and vice versa) to affect a certain property do not update in real-time
  • All Physics options can be consolidated into panels with minimal (global options) and extended with nodes
  • There is large amounts of data floating around in Blender that is not getting used for anything (instantiable transformation data for example)
    - THERE IS NO BLENDER C API???

How can you have an open source application with no API or good information on how to actually DEVELOP the software at the BASE level? :spin:

Beyond under-the hood problems that I’ve noticed (the previous list probably doesn’t even scratch the surface), there are some structural changes Blender needs in order to stick around. Blender currently cannot integrate well with most industry standard pipelines. Why? The integrations with standard toolsets currently available are let’s say, “subpar”. Having your own render engine is great. Cycles should continue to be developed. But seriously, it’s time the Blender Foundation made a concerted effort and serious strides with top 3rd party developers to make tools and integrations that are actually useful. (Arnold anyone?)

We are sitting on Alembic, and it’s “working” but it’s not bug free. I think it’s completely ridiculous Alembic integration is basically being done by 1 guy. Particle rewrite is basically being done by 1 guy…

The argument that is made is always, “these devs aren’t paid typically or their projects are only funded halfway, etc…”. But that’s a curious thing, because if you were to consult with some studios in Hollywood, or Atlanta, or over in Europe you’d realize that quite a few of these studios are actually interested in using Blender in their pipeline. These places would be more than willing to pay devs for a quick 1-2 month sprint to work on a specific part of Blender’s code for them…

I think at this point the community should stop, take a deep breath and a pause, and stop screaming “I want this, I want that” and like some of the root issues that plague Blender development and the people that work so hard on it. I fear the consequence of ignoring this and sticking our heads in the sand will = a massive Blender Fork of some kind in the future…

1 Like

Is there any information on expanding the Bake types to include Albedo & Specularity?

Not sure what you mean. Particle data as point cloud? That’s the way they are stored internally, you can even access the position etc. of every particle via Python.

I’d also like that, but I don’t think that’s a big target.

That’s due to Cycles being based on the OSL paradigm - but a metal shader with real-world IORs is already quiet mature and there’s also work being done on the disney übershader.

-> 2.8

Did you try the new dependency graph? it should fix that issue.

-> 2.8

Would be nice to expose more data for sure. You should simply ask for it. I kinda asked for exposure of the hook origin and now we have it in the Python API.

All in all most of your points are either already being worked on, targets for 2.8 or smaller changes.

In addition, some of the issues with third party plugin quality is not necessarily due to the way Blender is being developed, but due to the GPL license.

Because of that, it is something that you will not be able to fix by way of forking Blender, the only way to really fix it is to pretty much rewrite the entire Blender program from the ground up (either all at once or in phases using a similar approach to the way Cycles is done).


In addition, one of the major purposes of Blender 2.8 is not to introduce another load of shiny new features as hinted before, but rather to fix a number of longstanding problems and other weaknesses of the Blender application (the viewport refactor, the new depsgraph, and the planned rewrite of the particles for instance).

This is quite a thing to write after presenting a list of things that you want in Blender. A person might be inclined to read your post as “the community should stop, take a deep breath, and focus on the things that I think are important.”

The context of my statement was to provide a list of “things that need fixing”. Some of those targets are just examples of legit breaks in Blender’s code that I’ve found. The larger point I was making is that you don’t find these kinds of errors in other programs all that often. And to take that a step further, this is why Blender is not part of standard production pipelines.

Boooooooooooooo!

[QUOTE=lvxejay;3097900
- THERE IS NO BLENDER C API???

How can you have an open source application with no API or good information on how to actually DEVELOP the software at the BASE level? :spin:
[/QUOTE]

They use to have one in blender iirc in the 2.4 series… but it was rarely used… as instead of using a c api, they would just use the blender source code.

Is exposing stuff via c actually nessessary when the full source code is available?

Opensource development is quite different then company software development.
You cannt claim people to do this or that, (although you could help (or learn) coding and address the bug lists).

Developers may or may not listen, or be not interested at all; because they kinda code what they want to code.
Well not exactly like that they code on how they think how blender could (code wisely) best be improved.
So we could have wishes we all have, but just wait for it, and see what they come with.
Because what matters most is that they are able to lay a coding framework for the future.
Such a framework is more important than any specific (wish) feature that might make use of it some day.

So unless there is some real news about the 2.8 just wait and see where it goes

( Blender is respected in commercial environments, in smaller and larger companies, by independent artists, 3d printing people, students. Hey even Disney seams to like it… just to name one.)

Again, the problems in Blender’s code is known to the devs. and resolving them/replacing them with proper systems is part of the 2.8x project.

Now it is true that Blender development allowed hacks and generally bad code practice more back in the 2.3x and 2.4x days, that has created systems and features that are broken by design and is part of what makes 2.8x necessary (and I mention again that it’s not just about shiny new features). Now I wouldn’t expect everything to fixed at once as Blender has the usual issue applicable to all of FOSS known as limited resources, it’s not like Autodesk where they can answer feature requests by buying up software houses that have the needed technology (ie. billions of dollars in cash available).

The 2.8 branch may soon see its second notable project, Severin’s custom manipulators project (aka. Wiggly Widgets). For starters, the developers seem to lean towards integrating the core of the project into 2.8 due to its design.
https://developer.blender.org/D2232

Meanwhile, Mike Erwin is busy hooking up all of the viewport code to the new system that takes advantage of modern OpenGL calls (probably not ready for testing yet).

I’d say that’s the rule rather than the exception. An API is very difficult to design well and can become a pain to maintain (without breaking compatibility). Then again, you also can have a poorly designed API that breaks all the time.

Also, there is good information on how to develop Blender: It’s the code itself. If you can’t learn how to develop Blender from reading/modifying the code of the tools that already exist, you don’t have what it takes to develop Blender.

For external developers, it is. You can’t expect users to juggle with dozens of different builds with various patches by various developers, some of which introduce file format incompatibilities. You also can’t expect external developers to follow all the necessary steps to get their patches accepted into “official” Blender. Some of that work may also be below the quality threshold, but still useful to some users. Other things may be out of scope (medical visualization, mechanical engineering…).

Another episode of long-winded platitudes and bullshit.