AWS Thinkbox Discussion Forums

MultiMat Indices Are Off - *EDIT:Not a Bug*

Deprecated Frost MX 1.0 Beta Bug Reports
#1
  1. Create Frost Object
  2. Enable “Use Radius Channel” and set Viewport Resolution to 6.0 (for better visualization)
  3. Load the attached .CSV file into the Particle File slot.

CSV Contents:

float32 Position[0],float32 Position[1],float32 Position[2], int16 MtlIndex, float32 Radius 0,0,0,1,1 10,0,0,2,2 20,0,0,3,4 There should now be 3 spheres emitting from the origin, getting larger along X. Each has a material index 1,2 and 3 respectively.
4. Create a multi material, such:

mat1 = Standardmaterial diffuse:[255,0,0] name:"red" mat2 = standardmaterial diffuse:[0,255,0] name:"green" mat3 = standardmaterial diffuse:[0,0,255] name:"blue" materialArray = #(mat1,mat2,mat3) multimat= multimaterial materialList:materialArray medit.PutMtlToMtlEditor multimat 1

Assign it to the frost object from material editor slot #1

  1. Change the material dropdown to “ID from mtlIndex Channel”
  2. The CSV file clearly shows that the first particle [0,0,0] should be index 1 (red), followed by 2 (green), followed by 3 (blue). This is not the case. It seems the Indices are off one. Probably a 1-base error?
    myparticlefile - Copy.csv (129 Bytes)
#2

I am pretty sure PFlow (and thus Frost, too) uses 0-based MtlIndex.

#3

It seems impossible to set a sub mat ID to 0 in the multi/sub-object material. Were you saying this isn’t an error or just pointing out it’s not a base issue?

#4

Indeed setting the indices to 0,1,2 fixes the problem. But as I said the ID’s in the multimat are still 1,2,3 and can’t be set to 0. Is this just something you have to live with and work around?

#5

Dude, the mix of Zero and One based stuff in max is aggravating at best. It needs to be standardized just for headaches sake. :confused:

#6

I know it is inconsistent, but when PFlow saves out a MtlIndex channel, it is zero-based. I know that Mesh Faces use 1-based MateriaID values, but PFlow does not. So when you bake a PFlow to PRT, the values are off by 1, but they work ok with things like Frost etc., so you set your Material IDs in the Multi Material to 1,2,3… but in the PRT you have to use 0,1,2… to get them to align. The reason we insist on using MtlIndex as 0-based is that if you load a PRT file saved from PFlow back into PFlow, the values should still make sense, and since PFlow expects them to be 0,1,2… that’s what we give it. So Frost is caught in the middle and if you are making a KCM or a CSV, you have to work 0-based on the particle side, 1-based on the MultiMaterial side!

The alternative would be to shift the content of the MtlIndex by +1 when saving to PRT and by -1 when loading into PFlow, but that wouldn’t be very clean either…

Blame Oleg? :wink:

#7

I was just thinking that :mrgreen:

#8

Yes the particle ID and Index thing ugh

Privacy | Site terms | Cookie preferences