Jump to content
Sign in to follow this  
Kaluura Boa

Error: The material of the model is not... BANG! BANG! BANG!

Recommended Posts

I now have 3 holes in my screen through which ones I can see the wall...

Seriously, I am overfed up with this error. "The material of the model is not a subset blah blah blah". I have been fighting for hours with the uploader which is apparently more stubborn than me...

I made a low LOD version of my model as a second object in the scene of the original object (which I deleted before to save and export). The materials are all the same, all present, all used. There are 8 of them, not too many. There are no loose vertex or face without material anywhere.

The materials are the same since I simply re-used the ones from the original model. And still, the uploader always spits the same error.

I tried everything, down to merging the low LOD model into the original scene, re-applying all the materials one by one and cleaning up the list with the Outliner. Save, quit, load, verify, save.

Total failure!

I cannot think of anything I overlooked. Do you?

All this, using Blender 2.63 and LL's viewer 3.3.0 and 3.3.1. (The latter reported the same error for files that I already uploaded weeks ago so I tried an older version...)

The only way to make the uploader accept my files was to edit the Collada files by hand and to replace everything that was material related in the low LOD file with the same thing from the high LOD file. (The difference was a matter of order of the materials and the resulting different numbering later in the file.) This is not a practical solution...

Any idea? The old trick of the cactus on top of the screen did not turn well with my flat screen... :smileywink:

Share this post


Link to post
Share on other sites

I had a look with a cube with three materials, a copy of it after the materials were added and a new cube to which the materials were applied (Which is much more cumbersome that it is in 2.49. Oh dear!!).

The exporter is messing with the material names*. In Bkender they have the defaults Material.001, Material.002, Material.003. In the original and copied cubes they are Material_0011, Material_0022 and Material_0033. In the one cwhere they were applied manually, they are Material_0021, Material_0012,  Material_0033. The extra digit on the enmd appears to be the sequence number of the slot for the object - they are in a different order in the last cube.  If I reassign the materials to tyhe same order as in the original, then the error goes away. So that is the work-around.

Now, is this a bug or a feature? I can't answer for the Blender exporter crew here. I can't imagine why they have added the slot number to the material name. If you change the material via any of the object slots, it affects the material with the same name in the slots of the other objects. So I don't see any reason for distinguishing the materials that way. The name seems to be definitive. In that case, I would say this is a bug in the exporter. On the other hand, if there is a good reson for adding the slot number, which I haven't seen, then it is a feature we may have to live with by ensuring the materials appear in the same slots for each object (Ugh!).

Gaia - Can you shed any more light on this?

* By material name here, I really mean the material attribute of the <polylist> tag for each material. This links to the material indirectly through the <instance_material> symbol attribute. It is this material atribute that the uploader checks for the subset condition. It does not test whether it acyually links to an identical material (which is a whole other potential bag of worms - nobody has complained yet though!).

ETA - Blender 2.49 exporter does not add this slot number. It uses the unadorned material name. So it does not have this problem.

Share this post


Link to post
Share on other sites

I may add: Kaluura, you can edit the dae-files manually (just open with a text editior. At the end of each file you find the materials listed, compare the names and edit them, sometimes it takes less effort than redoing the whole model from the scratch...

Share this post


Link to post
Share on other sites

Mikki. What software/exporter are you using. For the B;lender exporters, you can find something like this for each object in the scene, as you say, near the bottom of the file ...

      <node id="cucopy" type="NODE">
        <translate sid="location">3.427666 0 0</translate>
        <rotate sid="rotationZ">0 0 1 0</rotate>
        <rotate sid="rotationY">0 1 0 0</rotate>
        <rotate sid="rotationX">1 0 0 0</rotate>
        <scale sid="scale">1 1 1</scale>
        <instance_geometry url="#Cube_001-mesh">
          <bind_material>
            <technique_common>
              <instance_material symbol="Material_0011" target="#Material_001-material"/>
              <instance_material symbol="Material_0022" target="#Material_002-material"/>
              <instance_material symbol="Material_0033" target="#Material_003-material"/>
            </technique_common>
          </bind_material>
        </instance_geometry>
      </node>

The material names that the uploader looks at are those between the quotes in the symbol="xxxxx" bits. The other places where they have to be altered is much higher up in the file. They are in bits like ....

        <polylist material="Material_0022" count="1">
          <input semantic="VERTEX" source="#Cube_001-mesh-vertices" offset="0"/>
          <input semantic="NORMAL" source="#Cube_001-mesh-normals" offset="1"/>
          <vcount>4 </vcount>
          <p>0 3 3 3 7 3 4 3</p>
(where ploylist is replaced by triangles in Blender 2.49)

So I suppose. you could look at the 'list' near the end of the file and the use search and replace to remove the extra terminal disgit that is causing this problem. I think that is a bit harder than simply reselecting the material to be put in each slot in the objects. That is done via a simple browse button under the slots (in 2.63) - it looks like a little globe. No rebuilding of the model is required.

Share this post


Link to post
Share on other sites

I use Blender 2.6x, and when I get that particular error I try fixing it with editing the dae files, it's a quick workaround once you know how to do it

Share this post


Link to post
Share on other sites

well, i see the problem and no  i can not tell why it was solved like this. Maybe just another "small issue" like the lot i found recently. (and which where fixed faster than i could type the error reports, thanks to one of the main Blender developers!)

I am currently chasing Collada bugs in blender anyways so i can add this issue to the list :)

Thanks for the hint!

Share this post


Link to post
Share on other sites

Now, I know what I did differently from previously: I created a new object in the scene instead of simply modifying my model to create a lower LOD.

So I have another workaround which is one step before editing the Collada file by hand: Have all your LODs in a single object.

You can work in several objects and merge them. (Just do not forget to put them on a line if you do no want to have a massive mess of vertices in one place and keep an eye on the material list if you merge from files.) You re-load this multi-LOD file to save each LOD in deleting all the vertices of the other LODs. You can do the UV mapping before or after merging, or even in each separately saved LOD file, it does not matter.

...And the uploader is happy. Its food is already fully chewed.

Still, it remains that either the Blender exporter or SL importer must be patched. I guess that the Blender's side of the things will happen in less time than LL need to mark a Jira as "Won't finish".

Share this post


Link to post
Share on other sites

Possible, but I don't think changing the uploader would be very useful here. It would have to go back to ignoring the material names and using the order inside the geometry tags. That caused all sorts of problems before it was fixed. I suppose they could follow the indirect liks and compare the actual material definitions, but that would probably open up a whole new set of potential errors. Better to have the exporter use the same name for the same thing, I think.

Share this post


Link to post
Share on other sites

I also had this problem trying to upload LOD models, over and over again. I kept being told I didn't have the same # of faces and/or that the materials were not a subset. I did make sure the order of the materials was the same. I never was able to upload but Nacy was able to do it somehow.  I would still be sitting here fuming if not for her. :-)

 

ETA:  But remember, making LOD's is quick and easy!

Share this post


Link to post
Share on other sites

If you get the error message about same number of faces, you can ignore it for now. It's a bug that it still appears, and you can (should be able to) upload anyway even though it's there (in the latest viewers). The subset error will stop you uploading though.

Share this post


Link to post
Share on other sites


Drongle McMahon wrote:

If you get the error message about same number of faces, you can ignore it for now. It's a bug that it still appears, and you can (should be able to) upload anyway even though it's there (in the latest viewers). The subset error will stop you uploading though.

 

I've found (at least on the beta grid) that if you go ahead an upload despite the "different number of texturable faces" error, it will upload, but it removes the material id that isn't present in all the LODs. I assume this isn't expected behavior?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...