Jump to content

Texture faces and numbers


Siddean Munro
 Share

You are about to reply to a thread that has been inactive for 4557 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hi!  I'm creating a set of mesh objects that will be texture changeable by script for several texture faces per object.  The problem I have is in the face number assignment.  I want face 1 on object A and object B to be the same material face - but SL seems to see fit to assign different face numbers and I can't work out why.  I am using Zbrush and polygroups to assign my material faces, but when I upload it to SL, the texture face numbered "1" on object A is called face "5" on object B, and face 5 on object A is face 3 on object B.  So my scripting is going to be hellishly hard working out which texture goes on which face.

I hope I have explained this well enough to understand, I barely understand it myself!  If there is some script that reassigns face numbering, or some way to create the material faces in Blender or Zbrush that might influence it?

The only way I have worked out is that if I create the polygroups on object A first, and then duplicate object A to create object B, the faces have the same numbering in SL.

[edit] I should add that I could do the last thing I mentioned, but all the sculpting work is done and that'd basically mean I have to redo it all :(

Link to comment
Share on other sites

 

The face numbers come from the order in which the faces are defined in the collada file. Each <triangles> and <polylist> defines a (part of a ) face; if you have the optional material  attribute the parts with the same material form one face.

But how can you control the order of the elements in  Zbrush collada exporter, not the faintest clue.

 

 See this for more info http://community.secondlife.com/t5/Mesh/Multiple-materials/m-p/1187185#M8278

 

Link to comment
Share on other sites

Material rules for lower LOD meshes changed recently, but as far as I know the way the materials of the high LOD mesh translate into face numbers has not. If that is correct, then the following applies. The Collada (dae) file defines the geometry of the mesh in a <geometry> section. Within this there are a number of <triangles> (or maybe <polygons> or <polylist>?) sections, each of which which lists the triangles for a 'submesh' that bears one material. The inworld face numbers are applied in the order of appearance of these 'submeshes'. Thus your solution lies in editing or controlling the order of these sections in the two objects.

I don't know about Zbrush, or the Blender 2.5 exporter, but in the Blender 2.49 exporter, the order is the same as the order of the material indices for the object. So you can ensure the same inworld face numbers by making sure the materials have the same indices in each object before (re)exporting them from Blender 2.49. (Can anyone add info for 2.5x and Zbrush?).

As far as lower LOD meshes are concerned, the new rule is that they must carry a subset (possibly all) of the materials used in the high LOD mesh. In this context, the identity of the materials is taken from the "material" attribute of the <triangles> (etc.) tag. This is an indirect link to the material definition.

There are two ways to ensure this is the same in Blender 2.49. First, if the LOD meshes are in the same file, you can use the Link and Pipelines panel to assign the same material, by unique name, to the appropriate material indices of both meshes. The exporter will then use the same "material" attribute.

Alternatively, you can edit the "material" attributes by hand. Note however that, unless you edit the other end of the link as well (the "symbol" attribute of an <instance_geometry>),  this will destroy the link to the actual material (and texture if there) so that texturing/colouring wil have to be applied inworld. It does not matter if the link is broken. That simply applies default material/texture. In fact you can delete the entire <library_effects> and <library_materials> sections without losing your inworld faces.

 

Link to comment
Share on other sites

Thanks LindaB!  I figured it out actually, for anyone who might be looking for the same answer... in blender the face # order when the model uploads to SL is determined by the material groups order so that's cool.  I was having issues importing my obj's from Zbrush to blender because the UV map was being destroyed/deleted for some bizarre reason so I have to export the colladas from Zbrush, into blender, assign the material groups in the correct order and then export again for upload to SL - that way it all seems to work :)  Learning excercise for next time I guess!  Do things in the correct order the first time to avoid redoing work! :o

 

[edit] thanks for your reply Drongle!  It's good to know I'm on the right track.  I might have to ask over at Zbrush Central about polygroups and the order, as far as I know there is no order

Link to comment
Share on other sites

Ordering is a problem. That's why they changed the rules for low LOD materials, because people had problems with materials rearranging on LOD switches. Now the code re-orders the lower LOD faces according to the order of materials attributes in the high LOD mesh. Hence the requirement for it to be a subset. That re-ordering gives me reasonable confidence that the <triangles> order still determines the face numbers, but it could change again!

The other place it's a problem is the association of LOD meshes in a multi-object upload with the right objects in the high LOD. That is determined by the order of the <geometry> tags. In the Blender 2.49 exporter, this seems to be random, so I changed my exporter script to put them in alphabetic order. That way you can control the order by using appropriate object names. Unfortunately, the 2.5x exporter is not a script. It must be likely they will change this to some sort of name-based association instead (or did they already?).

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4557 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...