Cycles Development Updates


(Steffen Dünner) #948

W is just the third dimension (like X, Y and Z). Mainly used for procedural 3D textures.
AFAIK “W” doesn’t mean anything, just like U and V or X, Y and Z are just subsequent letters of the alphabet.


(SynaGl0w) #949

Don’t get me wrong if the vertex colors are just being used for general color purposes, I have no problem keeping them one byte per channel, but having a check box option on the vcol layer to make them float per channel would be nice. What’s worse is that from the python side of things, the vertex colors are presented as floats (I know, I know, ease of use).

W hatever you want… it’s just a third channel. Would be nice to have the option to turn it on, if not just for a UV layer, then per mesh.

Vertex colors I have always used as my go-to auxiliary data especially for realtime renderers where I can specify whatever I want for vertex attributes.

But again, none of that really fixes my current problem, I want multiple custom normal layers, just like we can have multiple UV layers (where one is active/default and the others can be referenced by attribute name).


(Secrop) #950

Perhaps would be better to make cycles store vertex layers without color transformation… right now color transformation is applied before sending it to cycles… this speed up renderings when we’re using vertex colors… but it removes the possibility to store any other kind of geometry data in it. :confused:


(SynaGl0w) #951

That is why I abuse UV channels for anything custom when dealing with blender. Images can be set to “non-color data” so vertex colors should be no different. These kinds of things are also why I have some handy “linear to RGB” and “RGB to linear” node groups.

It would also be nice if cycles could load a RGBA texture image without mandatory premultiplying everything and instead listen to the “Alpha Mode” present on the image texture’s properties. Eevee listens to this option, cycles ignores it… WTF!? This also makes things a pain for previewing game assets, it’s common for game assets to use the alpha channel for things that are not literal “alpha” just like it’s common for game assets to use vertex colors for things that are not “colors”. Why am I still using cycles to preview game assets?.. because eevee, in it’s current state, still can’t do displacement or tessellation. Cycles can, UE4 can, etc.


(Ace Dragon) #952

Any float-based data can be abused to create custom normal effects considering the normal input in the shader nodes, not just UVmaps.

For instance, I have used it to create imperfections in metal surfaces (ie. no bump effect). I didn’t use UVmaps as opposed to processing textures and mixing it with normal data.


(Hadriscus) #953

We need a generic solution for that… basically custom attribute maps of custom length and type… vertex groups on steroids.


(Ace Dragon) #954

That would be great to have as we already have the attribute node.

If we had that and finally had the ability to make a near-unlimited number of vertex color channels, Cycles will start to feel pretty complete as far as masking goes.


(SynaGl0w) #955

I think you missed the point. I am talking about arbitrary vertex attributes, their channels and data type/accuracy.

  • Each UV layer gives you two channels that are stored as actual floats (cycles loads these as-is).
  • Each vertex color layer gives you three channels that are stored as bytes (cycles likes to give you these as color data also).

Given that choice of attributes we have right now, a second complete set of normals currently has to be stored in two UV layers, not vertex colors.

Honestly a complex solution is not needed, vertex colors stored as actual floats would be enough. With the raw values accessed from the vector socket and not the color socket of the attribute node (this would be a good way to diff. color and non-color data).

Also most exporters, and intermediate formats handle and understand UVs and vertex colors, as does most software that imports them.

In the mean time I will keep abusing UV layers for this purpose.


On the other topic of RGBA textures, PLEASE make cycles follow the “Alpha Mode” image setting!!!

No pre-multiply! No pre-multiply! No pre-multiply! …


(lukasstockner97) #956

I just tried to reproduce this issue and can’t figure it out…
I used a .dds texture that contains four different masks in the four channels as a test and it seems to work exactly how I’d expect it in Cycles: When I connect the Color output of the Image Texture Node to the BSDF, I end up getting the first three channels in the render. Eevee behaves in the same way, only the texture view in the workbench engine doesn’t seem to work.

Can you send me an example file showing the issue?


(doublebishop) #957

http://pasteall.org/blend/index.php?id=51356

Have a look at the viewer node in the compositor and have a look at the material output, they are they same image, but two different results.

In cycles, ALL image textures are premultiplied with alpha channels, even if the alpha mode is set to straight (on the right hand side of hte menu in the node editor)… Disabling the alpha channel entirely, will remove the premultiplication, but also make that channel useless.


(lukasstockner97) #958

Thanks, I can see it in that file - apparently it depends on the image format…

I’ll have a look.


(SynaGl0w) #959

Thanks for looking into it!


For those that want to see an example here is in the most recent 2.80.

Cycles:

Eevee:

Texture:

After testing the alpha mode, that eevee premultiplied looks “interesting”. It should also be noted that a change to the “Use Alpha” checkbox updates the render preview in eevee immediately, but not cycles.


(docent) #960

This post was flagged by the community and is temporarily hidden.


#961

https://docs.blender.org/manual/en/latest/render/workflows/command_line.html


(SynaGl0w) #962

So any ETA on when “Alpha Mode” is going to be fixed?

I need straight alpha on color and non-color textures because the alpha channels in both cases are used for metallic and roughness, or height and emission masks. These are texture assets being used in a game engine. Texture 1 is base color and roughness. Texture 2 is normal and metallic. This keeps common materials at only two textures. This works fine everywhere else and eevee, but is still impossible in cycles.

The other problem I found is that this prevents me from loading already premultiplied alpha textures, because cycles will premultiply it a second time, ruining the colors by making them way too dark.

I really don’t want to have to convert all these textures to separate maps or duplicate them in blender (one with “use alpha” enabled and one with it disabled).


(docent) #963

This post was flagged by the community and is temporarily hidden.


(lukasstockner97) #964

Probably two weeks, sorry - I’m way too busy right now to spend a lot of time on it, but I’ll have more time then.


(SynaGl0w) #965

Thanks!

So someone pointed out to me that the color was actually not premultiplied if the alpha socket was used in the shader… That appears to be the case on simple alpha masked textures, if you are using the alpha to drive a mix between a transparent shader and the color. In my case with material maps in the alpha channels, I had some that appears to be “less” premultiplied than others, and some just covered with black artifacts. The normal maps appeared to be covered in artifacts since lighting on a surface and glancing angles amplifies the imperfections in the normal map.

Holy crap!!! This. Is. Absurd…

  • Changing the output of a socket if a sibling socket is connected is completely unintuitive and a backwards design.
  • When the alpha socket is used in the shader, the output does not suddenly become straight… instead it becomes unpremultiplied.

Un - Pre - Multiplied

Yes, that is right! It is multiplied by the alpha then divided by the alpha then converted to linear color space for cycles, only if the alpha socket (of the same texture *file, not just the same node) is used in the shader. Even if the alpha socket is used to contribute nothing (0 minus alpha clamped added to anything).

This is giving you a fake straight color with artifacts that get worse the closer the alpha channel value is to zero.

Behold:

If the alpha is connected to the volume socket which is not visible, the color output is unpremultiplied.

This is basically what is happening under the hood to the RGB channels of the texture:

For the longest time, I could not figure out why the lower my alpha got the worse my color was, now I know. I basically stopped using RGBA textures in cycles many years ago because most never looked right. For all cycles projects I just had a separate RGB texture for color and a grayscale texture for the alpha.

I only brought this up recently because I had been messing with assets that are used in a game engine and noticed that eevee worked right, but cycles did not.

This behavior should be removed for sure. Changing one socket’s output on the use state of a sibling socket is ridiculous. Even more so when the actual image referenced by the node is different, but does so anyway if both image datablocks reference the same external image file.

The current “inside blender” solution is to duplicate the image block and use the alpha channel from the one with “use alpha” checked and the color from the one with “use alpha” unchecked. In the mean time, I am using a script that sets this up for me by duplicating the image changing “use alpha” then hiding both image nodes inside of a node group. It’s an okay workaround for now.


(English is not my native language) #966

Some speed improvements for CUDA by Stefan Werner:
https://developer.blender.org/rB47da8dcbcad4ccc5349bc303394e1d01d1c822c5


(drgci) #967

Nice CUDA improvements for Nvidia users