Getting the correct value of the "alphaSource" property from Bitmap texturemap via maxscript.

[maxtoolsQUR5M]

When I try to get the alphaSource value from the Bitmap in scene through the maxscript, I always get 0, even if this value is not actually 0 (it can actually be either 1 or 2).

If you first open the map in the material editor, then the alphaSource value through the maxscript will be displayed correctly.

What could be the issue?
How to get the actual value of the alphaSource property from the Bitmap texturemap through maxscript, without first opening this map in the material editor ???

[denisT.MaxDoctor]

I think you mean BitmapTexture not Bitmap...

But anyway I can't see the problem you are talking about. In my opinion, everything works correctly and as expected.

I can only help if you post your code, an example texture, and list the steps to reproduce the issue.

[maxtoolsQUR5M]

Yes, you think right. That's how I wrote "Bitmap texturemap".
OK. Suppose you have a scene, and you know for sure that you have V-Ray materials in this scene, in the diffuse slot (texmap_diffuse) of which there are Bitmap texturemaps with some textures. You open this scene in 3ds Max and want to get the values from "alphaSource" property of these maps is. But you don't want to open the material editor and look for those maps and manually load each of them to see if they have that value. You want to get these values through a Maxscript function.
I use something like this code:

bmTexArray=getClassinstances Bitmaptexture
for i in bmTexArray where i.filename!="" do (
	format "Bitmap = %\nalphaSource = %\n\n" i (i.alphaSource as string)
)

As a result of this code, I get the following information for each map:

Bitmap = AI54_001_wood_V1_001_Diffuse:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_001_Reflection:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_001_Normal:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_001_Glossiness:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_001_IOR:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_002_Diffuse:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_002_Reflection:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_002_Normal:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_002_Glossiness:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_002_IOR:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_003_Diffuse:Bitmap
alphaSource = 0

Bitmap = AI54_001_wood_V1_003_Reflection:Bitmap
alphaSource = 0

.......... 

As you can see, here all the maps show the same value "0" for "alphaSource" property. But if I then look at some of these maps in the material editor, I see that these values are in fact very different: some actually have "0", but others may have a "2" or "1" value. For example, the code showed that the "AI54_001_wood_V1_001_Diffuse:Bitmap" map had an "alphaSource" property of 0, but when I opened this map in the material editor, I see that the "Alpha Source" value was actually set to "None (Opaque)" , so "alphaSource" is 2.
Then I run the code above again, and now I see that for those maps that I opened in the material editor, the "alphaSource" value is taken correctly, that is, the one that I see in the material editor!

So my question is: is it possible to get out the correct (real!) value of "alphaSource" in Bitmaptexture maps without first opening them in the material editor??

[denisT.MaxDoctor]

Oh... Now I see the problem. It was hard to figure it out from your original post without further explanation.

The point is that at the moment of assigning a Bitmap Texture, the system has no decision what state to set for the alphaSource parameter, and set the value to 0. When the system needs to show the UI, it must make this decision and then some internal logic chooses the most appropriate for the texture, taking into account the presence of a texture file and an alpha channel, data format, color format, etc.

States: 1 - FILE, 2 - RGB and 3 - NONE. MaxScript uses a different numbering.

We can't tell for sure which state will be chosen and set by the system, but we can check if the 'decision' has been made. The MAX SDK provides BitmapTex::GetAlphaSource(). This method is not published for MaxScript, but can be called using the dotnet MAX API.

Unfortunately, I don't have time to look into this, but I know that Serejah is a big dotnet MAX API master. If you ask him the right way, he will hopefully be able to help you.

[denisT.MaxDoctor]

In general, we can only guess which state will be set by default, but...

If your texture doesn't have a file, 99.99% will choose ALPHA_NONE (3 for SDK, and 2 for MXS). 😎

[Serejah]

getting all sorts of animatables is fairly easy

(
	g = (dotNetClass "Autodesk.Max.GlobalInterface").Instance
	
	for bm in getClassInstances bitmapTexture do
	(
		anim = g.animatable.getanimbyhandle (dotNetObject "System.UIntPtr" (getHandleByAnim bm))
			
		format "mxs:'%'  -  .net:'%'    filename: '%'\n" bm.AlphaSource anim.AlphaSource bm.FileName
	)

)

[maxtoolsQUR5M]

Thanks @Serejah and @denisT.MaxDoctor , but that didn't solve the problem.
Through .net and animatables I get the same wrong result as through maxscript. You still have to open Bitmap texturemaps in the material editor to see what value is actually specified in the "Alpha Source" parameter, because through maxscript and through .net, values most often shown that are different from the actual ones (basically always "0" , which means "use the image alpha channel"). But the fact is that it is not always necessary to use the image's alpha channel, especially if the texture is used in a diffuse material slot, in which case the value of the "Alpha Source" property is set to "None (Opaque)" or "alphaSource=2".
The problem is that when opening previously saved scenes in which the "Alpha Source" value was specified as "None (Opaque)" on the used Bitmap textures, "Image Alpha" or "alphaSource=0" is still taken through maxscript, , although should be "alphaSource=2".

[Serejah]

---

@maxtoolsQUR5M  написал (-а):

... when opening previously saved scenes in which the "Alpha Source" value was specified as "None (Opaque)" on the used Bitmap textures, "Image Alpha" or "alphaSource=0" is still taken through maxscript, , although should be "alphaSource=2".

---

Made a test scene and couldn't reproduce the issue in 2014 nor 2020, so it could be either a bug of your max version (most likely) or less likely some thirdparty script or plugin messing with the values

or maybe the texture file itself doesn't contain alpha channel, but the alphaSource property remained unchanged for some reason.

[maxtoolsQUR5M]

---

@Serejah  написал (-а):

---

@maxtoolsQUR5M  написал (-а):

... when opening previously saved scenes in which the "Alpha Source" value was specified as "None (Opaque)" on the used Bitmap textures, "Image Alpha" or "alphaSource=0" is still taken through maxscript, , although should be "alphaSource=2".

---

Made a test scene and couldn't reproduce the issue in 2014 nor 2020, so it could be either a bug of your max version (most likely) or less likely some thirdparty script or plugin messing with the values

or maybe the texture file itself doesn't contain alpha channel, but the alphaSource property remained unchanged for some reason.

---

I tested on 2020 and 2023 versions of 3ds Max.
At first I thought that there was something wrong with my scenes, and therefore I took a scene from the library "Evermotion Archinteriors vol.54" to check. But this scene has the same problem.
I just opened the scene and ran your code, which printed to the Maxscript Listener the values of the "alphaSource" properties of all the Bitmap texturemaps used in the scene. Then I opened one of the Bitmap "AI54_001_wood_V1_001_Diffuse" in the material editor (I just took the first one from the Maxscript Listener list) for which "alphaSource" your code showed "0" (i.e. "Image Alpha" in the Bitmap interface) and saw that on in fact, this value shows "None (Opaque)" (i.e. "alphaSource=2"). Also, I noticed that when opening this map in the material editor in the upper window of the Maxscript Listener, this line "meditMaterials[1].alphaSource = 2" was printed. It looks like 3ds Max doesn't know what value the "alphaSource" property has until I open this map in the material editor. But isn't the value of this property stored in the scene??
I took a screenshot showing it all:

[Serejah]

And all of a sudden I can reproduce it

seems like applying it to a something visible in viewport could solve the issue, but I'm not sure

[denisT.MaxDoctor]

I get the impression that you didn't read my explanation carefully.

I'm pretty sure that the scene you're looking at was made (bitmap texture assignment) by some script. And it's the user's prerogative to set the AlphaSource state. But the system, even if the user hasn't set the state, should be able to render the materials somehow. In this case, it makes its own decision. This is reflected in the user interface.
So if you see 0 in the dotnet method, it means that the state is not yet defined, but in case of empty filename it will be "None (Opaque)"!

That's what your and Serejah's tests confirm.

[denisT.MaxDoctor]

... deleted ...

[denisT.MaxDoctor]

Also, I'm pretty sure that if the state is undefined and the texture file has a valid file, but the texture file doesn't support or doesn't have an alpha channel, the system will also pick the "None (opaque)" state.

If the texture file has an alpha channel, there are only two options - "Image Alpha" or "None (Opaque)"... what the system will choose in this case you can check yourself and tell us the result.

[maxtoolsQUR5M]

---

@denisT.MaxDoctor  написал (-а):

I get the impression that you didn't read my explanation carefully.

I'm pretty sure that the scene you're looking at was made (bitmap texture assignment) by some script. And it's the user's prerogative to set the AlphaSource state. But the system, even if the user hasn't set the state, should be able to render the materials somehow. In this case, it makes its own decision. This is reflected in the user interface.
So if you see 0 in the dotnet method, it means that the state is not yet defined, but in case of empty filename it will be "None (Opaque)"!

That's what your and Serejah's tests confirm.

Also, I'm pretty sure that if the state is undefined and the texture file has a valid file, but the texture file doesn't support or doesn't have an alpha channel, the system will also pick the "None (opaque)" state.

If the texture file has an alpha channel, there are only two options - "Image Alpha" or "None (Opaque)"... what the system will choose in this case you can check yourself and tell us the result.

---

It seems to me that you did not carefully read all my messages. But maybe it's because of the difficulties of translation (I don't speak English very well). Although it looks like @Serejah got the gist of the problem. The problem is that maxscript incorrectly takes the values from the "alphaSource" property in Bitmaps even when the user has previously specified this value. And this applies not only to the scene that I indicated as an example. This applies to all scenes that I personally created earlier and in which I personally set the desired values in the "alphaSource" property in the Bitmaps when they were created in the material editor.
Everything you wrote is correct. But only for those cases when a new map is created. When creating a Bitmap in the Material Editor and loading a 3ds max texture image into it, it first determines whether this image has an alpha channel, and if it does, then sets the "Image Alpha" value in the "Alpha Source" property, if the image does not have alpha channel, then 3ds max sets this value to "None (Opaque)". The user (i.e. me) then changes this value to what I think is the correct one to use in that particular location.

I will try again to explain the situation in more detail...

Let's say I have a finished scene that uses materials with Bitmap texturemaps in a diffuse slot.
I created each of these maps manually in the material editor, without using maxscript and regardless of whether the image in these maps has an alpha channel, I always specified "None (Opaque)" for the "Alpha Source" property (for a diffuse slot, I it is not necessary). When creating these maps and loading texture files into them, 3ds max first set the "Alpha Source" value itself, depending on whether this image has an alpha channel or not. In some maps, the "Alpha Source" value was set to "Image Alpha" because an alpha channel was found in the loaded texture, but I immediately toggled "None (Opaque)".
Next, I open this scene in 3ds max and want to check if I missed something and if all my maps are set up correctly. To do this, I run the code above. As a result, I see that for Bitmap maps, in which I myself set the necessary values ​​for the "alphaSource" property, maxscript took the values not the ones that I set, but those that 3ds max usually sets when creating a map in the default material editor, depending on whether the image has an alpha channel or not, while ignoring the values that I specified in the material editor earlier.
The problem is that maxscript (.net too) ignores the values that I manually set in the material editor for each Bitmap, and takes the ones that 3ds Max automatically sets when loading the image into the map.

I hope I was able to explain and you will understand the problem correctly.

[denisT.MaxDoctor]

Luckily, the MAX SDK has the code for the BitmapTexture. Here's what they do (where I got a little wrong).

There are three alpha source values:

ALPHA_FILE = 0

ALPHA_RGB = 2

ALPHA_NONE = 3

they correspond to the three paramblock values we have in MXS as an alphaSource property:

ALPHA_FILE >> 0

ALPHA_RGB >> 1

ALPHA_NET >> 2

when we create a new BitmapTexture the default value is 0.

when we create a UI for the first time (e.g. open a material edit), if the value is not 0 and the bitmap texture has an alpha channel, the value will be set to 0 anyway.

if we change the value manually or programmatically after the UI has been created, the value will remain as we set it with whatever convention for alpha to exist.

but...

when a bitmap texture is loaded (for example, when loading a scene), if the bitmap texture has no bitmap or no alpha channel and is set to ALPHA_FILE, its alphasource value will be changed to 2 (ALPHA_NONE).

[denisT.MaxDoctor]

Now about your case. I could reproduce the problem you have! But I'm currently using MAX 2020+ and the problem is now "half" fixed, at least for those versions.

the MXS alphaSource value is shown as current on first load, but the SDK value shows 0, where it might actually be something else.

What version of MAX are you using?

[maxtoolsQUR5M]

---

@denisT.MaxDoctor  написал (-а):

Now about your case. I could reproduce the problem you have! But I'm currently using MAX 2020+ and the problem is now "half" fixed, at least for those versions.

the MXS alphaSource value is shown as current on first load, but the SDK value shows 0, where it might actually be something else.

What version of MAX are you using?

---

As I wrote above, I tested this in different versions of 3ds Max, from 2018 to 2023. I am currently using 3ds Max 2023. The problem remains. Until I open the Bitmap in the Material Editor, MXS shows a value of 0 (Image Alpha) instead of the 2 (None (Opaque)) I set earlier. I understand that this happens mainly with those maps in the texture files of which there is an alpha channel, but which were forcibly set to "None (Opaque)".

[Serejah]

It is the BMSampler::Init method that is responsible for setting up the value when MtlEditor opens up. Not sure if there's any workaround

upd:

(
g = (dotNetClass "Autodesk.Max.GlobalInterface").Instance
tex = (getclassinstances bitmaptexture)[1]
format "1: %\n" tex.alphasource
a = g.animatable.getanimbyhandle (dotNetObject "System.UIntPtr" (gethandlebyanim tex))
format "2: %\n" a.alphasource

x = a.GetBitmap 0
x.toggleFlag 2048 -- MAP_PROXY   ((DWORD)(1<<11))
a.update currenttime.ticks (g.interval.create())	
format "3: %\n" a.alphasource
)

and this is the listener output:

1: 2
2: 0
3: 3

I don't know anything about all of this. Not sure if it is safe & robust.

Wonder why such threads are never visited by max developers

[denisT.MaxDoctor]

the only chance I see to solve the problem is if you post an example file and steps (maybe a code that you use) to reproduce the issue.

please make the example scene version 2020, and using only built-in materials (Standard) and texture maps (Bitmaptexture).

[futengda]

@maxtoolsQUR5M 

I finally found a workaround using sme api, try this:

sme.open()

sme.SetMtlInParamEditor bmt

print bmt.alphaSource