OTOY Forums

mosssi wrote:So the second texture which you connect to the power of the first texture, multiplies into black area of first one. is it true? So why does it is not black?

it's true, but the outside of the textures is not black, the border mode is set to white ,
multiplying a texture with white (x1) let the texture as it is.

Great. You rock man.

Hey calus
I'm in trouble with UDIM again . I used your script and it's really great but now I want to assign an UDIM Normal Map to normal channel. When I run the script the other normal maps goes to power channel and I think power channel function for Normal is different from diffuse and it can't be rgb value. So there is no effect on render although the normal maps can be assigned as diffuse and they are correct in order.
So what we can do to make this work?

Thank you

mosssi wrote:Hey calus
I'm in trouble with UDIM again . I used your script and it's really great but now I want to assign an UDIM Normal Map to normal channel. When I run the script the other normal maps goes to power channel and I think power channel function for Normal is different from diffuse and it can't be rgb value. So there is no effect on render although the normal maps can be assigned as diffuse and they are correct in order.
So what we can do to make this work?

Thank you

Arf, you're right, doesn't work for normal map...
as you said power attribute seems to work only with grayscale input for normal map.
I tried quickly other ways to layer the textures but none of them work for normal map, it seems the material "normal" input only work whith a RGB image node directly plugged in.

Please let me know If you find any way to layer 2 normal map with octane, I'll modify the script accordingly.

The only way I can see to deal with this is to layer materials, not textures,
so we have to duplicate the material as much times as there are tiles, and layer them with chained mix material, masked with alpha texture nodes...
Knowing it's impractical to edit duplicated materials afterward, and that Octane may be less efficient with chained mix materials,
is it worth that I try to make another script which handle UDIM this way ??

calus wrote:I'll ask in standalone section about this bug/limitation,
but in the meantime, If you find any way to layer 2 normal map with octane, please let me know I'll modify the script accordingly.

Thanks man, I don't know if they update v.2 anymore but I think it's a necessity because they failed to deliver v.3 yet.
Anyway I did some test with multiply and mix but all didn't work. So I was thinking to build a custom node for mixing or a add a power attribute to multiply node. Do you think if it's possible?

mosssi wrote:Anyway I did some test with multiply and mix but all didn't work. So I was thinking to build a custom node for mixing or a add a power attribute to multiply node. Do you think if it's possible?

custom node using LUA script node is possible but only works in standalone...
Anyway the material "normal map" plug only support RGB image node as input, no other node seems to be supported (let me know if you find any other node that change something when plugged in "normal map")

I modified my previous post at the exact same time you were posting,
so I quote myself :

calus wrote:... it seems the material "normal" input only work whith a RGB image node directly plugged in.
...
The only way I can see to deal with this is to layer materials, not textures,
so we have to duplicate the material as much times as there are tiles, and layer them with chained mix material, masked with alpha texture nodes...
Knowing it's impractical to edit duplicated materials afterward, and that Octane may be less efficient with chained mix materials,
is it worth that I try to make another script which handle UDIM this way ??

calus wrote:is it worth that I try to make another script which handle UDIM this way ??

[/quote]

Oh, Thank you calus. It's not really necessary, I wanted to use udim so I can modify less materials but with material mixing its even more material to edit. So I think I should handle this like old times. My colleague wrote a script to reduce this pain a little more procedurally.
But I still think its Otoy responsibility to add a fake udim like this one to v2 and v3.

Anyway the material "normal map" plug only support RGB image node as input, no other node seems to be supported (let me know if you find any other node that change something when plugged in "normal map")

That is correct, we don't currently support mixing any textures for normal maps.

We have been looking at UDIM textures as well, and I would emulate it with a similar trick but instead of daisy-chaining the image nodes I would use multiply textures to multiply the tiles together. This decreases the "nesting level" of the textures and allows for much more "tiles" before hitting technical limits in the render engine.

Here's a script which generates an example in the standalone edition:

Code: Select all

local P = [[path/to/textures]]
local textures = {}
local D = 10

-- all images
for i = 1,D do
    for j = 1,D do
        local t = octane.node.create{type=octane.NT_TEX_IMAGE, name="img"..i.."-"..j}
        local m1 = octane.matrix.makeTranslation{j-1, i-1, 0}
        local m2 = octane.matrix.scale(m1, {.1, .1, 1})
        t:setPinValue("transform", m2)
        t:setPinValue("borderMode", octane.borderMode.WHITE)
        t:setAttribute("filename", octane.file.join(P, ("rgb-%04d.png"):format(j + D*(i-1))))
        table.insert(textures, t)
    end
end

-- connect together with multiply nodes
while #textures > 1 do
    local previousLevel = textures
    textures = {}
    for i = 2, #previousLevel, 2 do
       
        local t = octane.node.create{type=octane.NT_TEX_MULTIPLY, name="×"}
        t:connectTo("texture1", previousLevel[i-1])
        t:connectTo("texture2", previousLevel[i])
        table.insert(textures, t)
    end
    if #previousLevel % 2 ~= 0 then
        table.insert(textures, previousLevel[#previousLevel])
    end
end

 -- move the final node a bit so we can find it...
textures[1].position = {textures[1].position[1] + 30, textures[1].position[2] + 30}


roeland wrote:That is correct, we don't currently support mixing any textures for normal maps.

Hi man. So you say there is no way to use this fake UDIM method with normal map support, right? or any plan for update v.2?

roeland wrote:I would emulate it with a similar trick but instead of daisy-chaining the image nodes I would use multiply textures to multiply the tiles together. This decreases the "nesting level" of the textures and allows for much more "tiles" before hitting technical limits in the render engine.

good to know, thanks !