利用者:Broken/BreakingRenderCompatibility

There are several problems in Blender's renderer that are relatively easy to solve, but haven't been done yet since it would upset backwards compatibility (i.e. rendering old files in new Blenders and getting similar results).

Some of these things are ancient things from 1995 that have stuck and aren't suited to the kind of complexity needed nowadays, some of them were just oversights in the initial implementation (by the time the feature has been used enough to find out the flaws, it was too late to change).

Render Engine

Texture Stack

The texture stack in the standard Blender material is a mess. The relationships between inputs, outputs and other textures are poorly defined and communicated, and there are many obscure 'features' that seem more like workarounds for specific problems. Now that we have a node system, it would be better to relegate this sort of complexity to nodes, and leave the standard materials for simple, quick-to-set up work.

Problems include:

• Strange behaviour of blend modes, particularly with intensity textures. Intensities apply additive to the base value, regardless of whether 'Mix' or 'Add' is chosen. This means you have to do weird tricks to get (for example) alpha maps to work, setting the main alpha to 0 or using weirdo dvar. It should be as simple as just applying a greyscale texture, mapping to alpha, and that's it. If you want additive you can manually choose 'Add'.

• The odd relationship between Var and DVar. These are obscure, strangely titled and most people don't understand what DVar is even for, let alone how it works - I didn't until only a year or so ago and I still don't have a firm mental grasp of it. Perhaps this was added in the past as a workaround to help tweak something, but nowadays this sort of thing can easily be handled by nodes, with a lot more control over how things are blended and influenced, using mix nodes, color ramps, etc. DVar should be gotten rid of, and left with just a simple influence slider to control how much that texture is adding/mixing/etc.

• Stencils are extremely limiting and confusing to use.

Materials

• Much of the standard Blender solid material is an accumulation of years of tweaks, hacks and workarounds, all piled into the one shader. Much of this complexity could benefit from being split out into nodes where you would have full control, and at the same time accelerate the standard shader's workflow for simple tasks that are fast and easy to use. Some examples include:

• 'LBias' and 'Shad A' -> could be turned into a 'lamp override' node, used to override multiple lamp properties when used on that shader

• Object Color/Texface/Vcol Light/Vcol Paint would be served much better as shader nodes, including or alongside the Geometry node. As it stands, I already have a habit of making 'dummy' materials that are shadeless but with ObColor or Texface on, just in order to get that into a node setup. In the standard material, they add information complexity, are inconsistent with each other, and don't give a required amount of control. VCol Light adds colour, VCol Paint and TexFace replace colour (except when VCol Paint is used with TexFace, in which it multiplies TexFace *then* replaces colour), and ObColor multiplies colour. None of this can be communicated in the small space of UI buttons, leading to a 'click and hope' workflow that few people truly understand, and that is much too rigid for complex scenarios anyway.

Render Passes

• The reflection and refraction passes are not useful. I can understand how they were implemented, and didn't seem to be any issues at the time, but after trying to use them practically, it's just no good. Yes, it's possible to add the pass back on to the original, but you can't actually do anything much useful with them in between.

Because they work subtractively, you end up with lots of negative and inverted colours, and even trying to do simple things like overlaying another colour to tint the reflection, or shifting it, or blurring it, causes all sorts of problems. There's also problems because it doesn't give you a clear mask of what is actually part of the pass, and what is not - so if you want to blur it, there's no way to mask the edges other than making other ID mask passes, which is awful.

I'd personally much prefer the reflection and refraction passes to just output the raw (eg.) reflected colours, with alpha masking the non-reflected areas. I could then just layer or add it on top however I like, and it'd be a lot more flexible to do practical things with the passes in between.

• The AO pass has several problems - they are mentioned in more detail here [1] but one main issue is that it returns black for areas where there is nothing rendered (sky). This is incorrect, since the definition of the ambient occlusion pass is 1.0 = no occlusion, 0.0 = fully occluded. Obviously the sky is not fully occluded, so it should be 1.0. This means you have to do tricks like adding the inverted alpha channel to it in every comp, which is annoying, and time and resource consuming.

Compositor

• An oversight from when the compositor was first implemented, was to not standardise on relative 'normalized device coordinates', and to allow pixel coordinates for transformations, blur, etc. This makes it much harder to use low-res previews and proxies, and has caused a lot of cruft to be added, such as the additional options in the scale note and blur node. Quoting IL'dar AKHmetgaleev on bf-funboard mailing list:

"I propose to use NDC (Normalized Device Coordinates) coordinate system. For example we have image with resolution 720x756 and frame aspect ration 16/9. Point in image centre will heave (0,0) coordinates. In upper right corner (1,1.777), in lower left corner (-1,-1.777).

Blur with size (0.1,0.1) in this case will stay same in all resolutions and aspect rations. Same with transformations. We even can setup compositing and then change resolution, pixel aspect ratio and image aspect ration without adjusting node values and will have mostly same result."

It would be much better to move the compositor to a system-wide relative coordinate system, like many other compositing packages, however this may break compatibility with existing comp setups.