Alpha throws error

Hello everyone. I redid the nodes. Added an Occlusion change. But alpha works with an error. If you put Alpha Test 0/0 . Then the material becomes transparent abruptly, without gradualness. Can someone come in handy or solve the problem with transparency.


Hi. I moved your post from this thread to its own thread, as your post is more of a question than showcase feedback - you’re also more likely to get help from others if you keep questions in a separate thread.

Can you please share the error you are getting with the alpha? Thanks.

I archived all the files drive_zip, but does not write an error on alpha. Alpha is out of control.

Hm, I get this error:

Traceback (most recent call last):
  File "\armsdk/armory\blender\arm\", line 146, in poll_threads
    raise e
  File "\armsdk/armory\blender\arm\", line 139, in poll_threads
  File "\armsdk/armory\blender\arm\", line 497, in build_done
  File "\armsdk/armory\blender\arm\", line 604, in build_success
    state.proc_play = run_proc(cmd, play_done)
  File "\armsdk/armory\blender\arm\", line 80, in run_proc
    p = subprocess.Popen(cmd)
  File "\3.3\python\lib\", line 966, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "\3.3\python\lib\", line 1435, in _execute_child
    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified

Please ignore what I said above. It’s apparently due to an unrelated issue that I didn’t notice before on further expectation.

I can reproduce the issue, very strange. @timodriaan do you think you could look into his when you have time? Alpha values also appear to be clamped on export, so I can’t test at runtime to see if alpha > 1.0 resolves the issue.

Alpha = 1.0

Alpha = 100,000

as I wrote above, there is a connection with the alpha test. is it possible to gain control over the alpha test through nodes?

Alpha is a factor and can not be greater than one.

UPD/ I’m sorry. I didn’t immediately understand what you were talking about.

UPD2/ The slider clearly lacks precision.
This works just about right

In my opinion Armory2D in general is very crooked and not of high quality. A lot of problems in it.
And this is taking into account that I implemented a fairly simple project.

This Armory2D? What does that have to do with the issue at hand might I ask?

It’s about the canvas. (in the picture)
If I understand it correctly, the slider is a component of it.
Maybe it’s not related to the canvas, but the slider doesn’t handle extreme values correctly. You move the mouse all the way to the right, but instead of 1 you get a value close to 1, but not 1. (For example 0.99998)
Similar inaccuracies are encountered when picking colors of elements in the color wheel inside the canvas setting.
The mouse sticks to the color picker, or something else.

Again, I could be wrong. But I see what I see and what I sing! ))) It feels like the implementation on the settings canvas in weapon2D just terrible, although the problem may be somewhere at another level.

I don’t believe it is (feel free to disagree)? If the issue was caused by the Canvas, disabling both the Canvas trait, as well as the Node trait should resolve the issue - but it doesn’t. That’s because it appears to be a material problem with how Blender exports to Armory, or how Armory interprets those exported values.

1 Like

It looks like you’re right. The value alpha=1 is only available if displayed directly in the node.
When you plug any value into the alpha 1 slot, it becomes less than one. But at 1.0001 there is no transparency.

However, if the parameter is engaged - even 100 does not help.

At some point in the data exchange between armory and blender, data loss occurs and 1 becomes unequal to 1

Once again, I had similar problems when working with the canvas (when selecting colors of elements). That’s why I thought it was the problem.