Black square on my mesh after texturing ....

[LeiaMelo]

Hello,

 

here is my problem, I made a trouser, rigged it, as good as possible I hope, then, mark seam and edit uv map.

After this work, I realized the others 4 sizes (Xs, S, ...). For that I copied my first mesh with shift+D, then modified it for a perfect (I hope) fit with the others sizes.

 

So when I export in collada, then upload in Second life, then texturing it, I have those black square which appears ...

I don't know why I have that !! My mormals are goods, so I suppose it's the uv map ?

I don't bake the texture, cause I want to realize some differents pants with this mesh ....

Is anybody ahve an idea ?

Thx

[Drongle McMahon]

Looks like a UV mapping problem to me. There are three kinds of area. Two seem to have the same texture but with different scaling. So those are mapped with different ratio of mesh area to UV area. The third looks like a solid brown colour which could be one pixel from the same texture. That would happen where the UV map of that area was completely collapsed to a point, so that the whole area receives the pixel colour at that point.

I don't know what software you are using, but it probably has the facility to look at the texturing before you upload it. That would reveal these sorts of problems. Also, you can select parts of the mesh geometry and see where the corresponding vertices appear in the UV map. It's possible that you UV mapped the separate pieces separately, so tyhat they gor different scaling. The collapsed parts could have escaped mapping altogether, or could have been constrained by inappropriate UV seams.

You need to make sure all vertices are selected and then redo the mapping. Then apply a texture in the 3D program to make sure there are noi problems because of bad seams.

There is another problem that can arise if your mesh has more than 21844 trianles, but I don't think that's the problem here.

[LeiaMelo]

Thx for the answer ....

I use Blender, and the different "black squares" appears randomly with different upload in Second life.

The texture on the pocket is different cause I use multi-texture, so 2 differents uv map.

My mesh has 30055 (I have a belt in rope) so what is the problem with that ?

 

[Drongle McMahon]

I use Blender, and the different "black squares" appears randomly with different upload in Second life.

That sounds a bit like what happens when some faces are unmapped - random mapping, often from one texture pixel. I think it's due to the use of uninitialised data where map data is missing. Turn on face select mode, deselect everything, turn on synchronied selection and select all in the UV window. Are all the faces in the 3D view selected? Also, apply a test vtexture by loading it in the UV edit window while the whole mesh is selected, choose disply - textured solid on the right of the 3D view and check that everything is textured as it should be.

The texture on the pocket is different cause I use multi-texture, so 2 differents uv map.

OK, that should explain the different scales.

My mesh has 30055 (I have a belt in rope) so what is the problem with that ?

 There is a part of the source code that starts a new "hidden" material (but with the same name) when the triangle count for one material exceeds 21844. When you check "select faces" and apply a colour (and I assume texture - I didn't test that*), it gets applied to only the "hidden" material, leaving others unchanged. You have to select the unchanged bits and apply it there too. Strangely, if you keep applying new colours, it eventually starts affecting the whole area (I don't understand that on. Probably something to do with the same niming.) If this is your problem, then that should be the solution. The test meshes I investigated this with were all triagulated and the aberrant colours were triangular. If you are uploading quads, that may explain the difference. The amount of dark patches seems abou right with the triangle count you have given.

On the other hand, I would suggest that 30k triangles is very excessive for this item. There is no LI-like penalty for attached mesh, but it still affects the fps by giving the gpu too much work, especially for the wearer who sees the highest LOD all the time, but also for everyone else with possibly less powerful graphics cards. The simplest solution would be to simplify the mesh. Halving would take it below the 21844, but I would suggest being more drastic. Use smooth shading, not high poly density, foe smoothness.

*ETA: So I tested it. Effects of adding textures with selec faces and dialog, or by dropping them on the mesh, is the same as for colours. More below.

[LeiaMelo]

Firstable, thx for your quick answers ...

Secondly, for :

1. "That sounds a bit like what happens when some faces are unmapped - random mapping, often from one texture pixel. I think it's due to the use of uninitialised data where map data is missing. Turn on face select mode, deselect everything, turn on synchronied selection and select all in the UV window. Are all the faces in the 3D view selected? Also, apply a test vtexture by loading it in the UV edit window while the whole mesh is selected, choose disply - textured solid on the right of the 3D view and check that everything is textured as it should be."

I check this point all is alright, so this is not this problem ...

2. "There is a part of the source code that starts a new "hidden" material (but with the same name) when the triangle count for one material exceeds 21844. When you check "select faces" and apply a colour (and I assume texture - I didn't test that), it gets applied to only the "hidden" material, leaving others unchanged. You have to select the unchanged bits and apply it there too. Strangely, if you keep applying new colours, it eventually starts affecting the whole area (I don't understand that on. Probably something to do with the same niming.) If this is your problem, then that should be the solution. The test meshes I investigated this with were all triangulated and the aberrant colors were triangular. If you are uploading quads, that may explain the difference. The amount of dark patches seems abou right with the triangle count you have given.

On the other hand, I would suggest that 30k triangles is very excessive for this item. There is no LI-like penalty for attached mesh, but it still affects the fps by giving the gpu too much work, especially for the wearer who sees the highest LOD all the time, but also for everyone else with possibly less powerful graphics cards. The simplest solution would be to simplify the mesh. Halving would take it below the 21844, but I would suggest being more drastic. Use smooth shading, not high poly density, foe smoothness."

The english is not my first language (sorry for my expression) so I have to translate first but may be the solution is here. I use the decimate modifier on my mesh to make a mesh with less than 20 000 triangles and first upload, it looks nice. No square !

Unfortunately, the decimate makes a mesh very awful ... So I have to check a solution ....

Thx for all

[Drongle McMahon]

Yes. Decimate isn't usually very nice. It looks as if you have a mesh made of nice regular quads. If that's right, you could just select every second horizontal edge loop and use mesh->dissolve. That will reduce the triangle count in a regular way without affecting the UV map. You have to check the "dissolve vertices" option that comes up on the operator options when you use dissolve for this. Otherwise the vertices are left there and the triangles will come back when you upload.

[LeiaMelo]

Excellent tips, and this is exactly "limited dissolve" whiwh I have to do ....

I "understand" a great thing, and now, I will watch carefuly about this

Thx again for this very helpful answer : I reduce and dissolve some loop edge, and no more black squares .... :matte-motes-bashful-cute-2:

 

[Codewarrior Congrejo]

Just in addition and to keep in mind for future meshes you make:

As Drongle already said 30 K tris for just some pants is way too much. Its not only heavy on the graphical side it also is on CPU and memory because for the moving avatar and its animations all these vertices and their positions, their weightinformation and much more have to be stored and updated all the time.

As comparison for you: the whole SL default mesh avatar has around 3668 vertices / 7186 Tris (plus a few for the eyes / and lashes) and that is a full avatar.

Gamecharacters in general for an engine and environment like SL should allways have around a maximum of 6-7 K tris for the avatar itself and keep the attachments and addons also close to the amount of the single bodypart they are being close to. Normals, Smoothing and other tricks will help you achieve everything needed with way less polygons =)

For the best allways build your clothes similar to the density and edgeflow of the avatarmesh which is supposed to be wearing it. This will give you a ca. value of how many tris you should use and also ensure that the clothing item will move and work well along with the avatar when being in motion / animated.

I know its easy to become lost with all the things that are needed to know, so for tricks on how to achieve the most with the lowest amount of polygons possible have a look at Polycount.com: http://www.polycount.com/forum/ and here : http://wiki.polycount.com/

have fun creating, Cheers! Code

[Codewarrior Congrejo]

@ Drongle: latest version of Blender now also finally has the decimator with preserving UV capabilities. They finally made it work (from Version 2.65a on ) =)

And i still like to work with decimators in some cases. Especially for lower LODs of objects that dont need a very precise shape definition. And with cutting your model in half and mirroring it before decimating also the uneven distribution of triangles isnt really an issue, after applying a mirror everything is even on both sides again.

 

[Drongle McMahon]

"Blender now ... decimator with preserving UV capabilities"

Yes. I haven't got round to trying it yet. I guess it can be a great time saver, but I do like precise control (although the decimnator might well do a better job than I do! :matte-motes-shocked:)

[Codewarrior Congrejo]

haha, well control is surely somewhat less when using the decimator algorithms. And I clearly would never leave it untouched / unedited in the end.

But I agree with you and repeat what I said. I am mostly using it for shapes that don't have a really sensitive shaping such as an avatar (especially would never run it over the area of a creature's or human's face  - that gives nasty results and is rather an addition for the horrorcabinett .. lol) For those I prefer control and my own 'handstitching' to optimize it's count.

Apart from that it still can often teach you how far you can actually break a model down and still preserve its look. Btw. The new decimator also offers now to either triangulate or keep as many quads as possible - which I find a very good attempt.

Cheers ! code

[LeiaMelo]

A great thx for all thoses answers ...

30 K tri is very too much and now I realize it ! I have to reduce it ... and it's better for the $, the more you upload, the moer you pay ! Thx for the links, and the advise.

But now, I have an another question, just curiosity, if you want to do a complex mesh, more than 21k tris, how do you texturize it ? I read the limit is about 66 K tris, but if you have a limit with the texture ??

 

[Codewarrior Congrejo]

You are very welcome =)

To answer your new question: 

As Drongle already mentioned there are issues with meshes of more then 21844 tris. To quote his answer here:  "There is a part of the source code that starts a new "hidden" material (but with the same name) when the triangle count for one material exceeds 21844. When you check "select faces" and apply a color (and I assume texture - I didn't test that), it gets applied to only the "hidden" material, leaving others unchanged. You have to select the unchanged bits and apply it there too"

What you can do is making sure to separate into several faces / materials. In that case break the model down into 2 UV / Material areas. So the amount of assigned tris for one material doesn't exceed this limit. 

To achieve this you set your UV Seams as usual along the model and make an additional UV seam where you plan to split it into a new material. Try to choose this area of the mesh wisely because you have to keep in mind this is a 'break in the texture' so you will need to ensure that you paint the connecting areas on both textures in a way that the seam won't be visible or at least not noticeable. And this can be very tricky at times.

create a new Image of the same resolution as the first one used in your material nr. 1 (otherwise you will have different looks / resolutions and that simply isn't nice to look at)

With the faces selected create and assign a new material to them. And assign this new Image to this material.

Make sure to select this new image in the image / UV view, and now Unwrap your model again. (Maybe 'pin' the Vertices of the former UV layout that you don't want to change in case you already made textures for it and to spare some work -  and then just select and unwrap the ones of the new UV area)

Save your file and the new image to your hard drive.

When you now export your object to DAE and imported it into SL it will - just like a default cube in  SL - have an additional 'face' that you can select in certain and pull its image texture onto it.

The maximum of Faces / Materials a mesh for SL can have is 8. 

PS: but I still barely can think of any object that would need such a high amount of tris (except for certain high density structures). Even with a full avatar and clothes and hair combined in one mesh it shouldn't reach such an amount.

To reach smoothness and round shapes or even sharp corners a lot people are mislead by the thought to achieve this by adding more faces and edgeloops. Because they can see the higher smoothing or more defined areas when pulling their subdivision levels up in their editing software.

But all of this can be reached with Normal-Smoothing, Smoothing groups to create sharp optical breaks, and a generally good all over topology of the mesh construct.

Also to make clothing work good with animation etc is a matter of where you placed your edgeloops and how the edgeflow fits to the underlying mesh and the armature that is later on moving it and not only by just adding an enormous amount of more faces. (high end game engines do this by adding tessellation at rendertime to smoothen the result even more - but also there the raw model itself is always made with the lowest possible amount of faces / tris / verts in mind to achieve a certain quality)

Try to optimize as much as you can, to know how to optimize a model and keep it as low as needed to lower render impact and CPU power is what differentiates a 'good modeller and artist' from a 'I can do mesh' person =)

 

 

[Drongle McMahon]

Hopefully, you won't be using more than 21844 triangles now. However, in case anyone has to, I did a few more experiments with my >174752 triangle cube. If you set the texture in the edit dialog without using Select Face, it will set the same texture for all the triangle. What happens if you drop a texture on the mesh, or choose a texture from the dialog while usin Select Face, depends on which pseudo-face your drop/selectio falls on. On one of them, all the faces receive the texture. On all the others, it appeaers on just the selected face!

To clarify this, I tried changing the colour by a sinple script. It turns out that if you change face 0, all the pseudo-faces get coloured. If you use any other face number, nothing happens. I assume this is a side-effect of the fact that the pseudo-materials all have the same name. Presumably the llSetColor works through a name-based face/material list that only has one entry (0) with all the triangles in it. It appears that the selection (explicit or by dropping) works differently, and only if you happen to have selected pseudo-face 0 does it then get applied to all others with the same name.

I would have to look through the source code again to find out why this is. It's possible the behaviour of face 0 is supposed to happen for all the pseudo-faces, and that its failure is a(nother) bug. I'll have to make another jira with this new info to add it to the existing one for the holes.

[Codewarrior Congrejo]

i assume it is a memory limit in storing the materialindex for all the faces / vertices in a mesh. it would also make sense in that case to just assign the first material or maybe the on-most-vertices used material to the pseudo faces in order to possibly cover it with something that is close by.  That selecting face 0 leads towards all faces ( the pseudo ones included) makes sense since the index should contain all faces and accordingly sets the material to all of them. Why on the other hand there is a 'break' that splits certain of those into a separate selectable face/material is indeed odd. 

On the other hand it comes to mind that it might be a workflow related problem. When you work with subdivision on an obejct that eventually already got a metarial assigned it for sure does assign the same material in your editor to the subdivision faces- without needing to select / assign those newly subdivided faces again . But i am wondering if the metarialindex info gets distorted that way. and the editor itself can handle it due to its internal way it stores the informations, but maybe SL can't.

Did you try to export that 'massively faced' cube (lol) with other programs as well, to see if it would behave differently ?
Would maybe be a pointer towards if the Editor assigns unreadable values to the indexes and thus is a problem from there. Or if it is just the same no matter from where you export it ?

[Drongle McMahon]

In the SL internal data format, each material has a list of triangles and each triangle consists of three pointers to vertices (each vertex having position, normal and UV vdata). These indices are 16bit, which limits the vertex list, per material, to 65536. The code contains a check on the size of the vertex list that should give an error messgae when it reaches 65537 and, presumably, abort the upload.

However, there is another check that limits the number of indices in the triangle list, which intervenes when the triangle count exceeds 21844 (65532/3). This will always be reached before the 64k vertex limit, even with completely fragmented UV or faceted triangle so that each triangle requires three unique vertex list entries. When it intervenes, it doesn't stop the upload, but instead it starts a new "pseudo-material", resetting the vertex list counter for the new material. So the 64k limit cannot ever be reached. (I can't see why this extra limit was introduced. There doesn't seem to be any need for a 16-bit counter or index into the triangle list, but who knows.)

In fact, you can upload apparently unlimited numbers of triangles, but if you exceed 8x21844 (174752), the next ones go into a ninth pseudo-material (and so-on) which gets culled by the limit to eight materials. The culled triangles appear as holes.

Which triangles appear in which pseudo-material seems to be dependent on the order they happen to be received by the uploader from the 3D authoring program and exporter, which can depend on the internals of those programs and on how the mesh was made. In a Blender mesh made by subdivision and finally triangulating, the triangles are scattered over the mesh surface in a Serpinski-fractal-like pattern. So are the holes that are left by going over the 174752 limit. I guess that is the result of adding the new faces at each subdivision to the end of the existing list inside Blender.

I can understand why dropping a texture on the surface or selecting a face affects only one pseudo-face/ Both involve looking through the triangle lists to see which material was clicked. Then the code could just fill in the remainder of the triangles in the list where the hit was found. However, that doesn't explain the different behaviour for material 0 where all faces get the texture. I might look at the source for an explanation there. The scripted changes work the other way round - pick a list from its index and apply to those triangls. Scripts run on the server, so I can't look for this.

I can say it's not just the fact that the pseudo-materials have the same name. Editing a simple collada file to make four materials on a panel have the same name doesn't produce any strange behaviour. This is consistent with the situation before material sorting by name was introduced to correctly assign materials at different LODs. Before that, the names were irrelevant and only the order in the collada file mattered.

[Codewarrior Congrejo]

I see. Hmmm..

<triangles count="528" material="MATERIALNAME">
   <input offset="0" semantic="VERTEX" source="#ID7" />
   <p>0 1 2 1 0 3...</p>
</triangles>
In this example the mesh has originally  266 verts in the <source>  and the model contains 528 tris. In general it should be N vertices = N/3 triangles. But it reuses the vertices between the connected tris (stated in the <p> element)

Which would mean the data any software has to read needs to a ) contain all the <source> IDs = vertices, 'plus' the list of pointers (<p>) vertices to reuse within a tris. 

SL stores 3 pointers. Then yes, here we reach that first break in the 'triangle/material grouping.'
Interesting: 16 Bit limitation of 65536 divided by the first limitation/ break of 21844= 3,00018 .. A float..hmmmm 

(that horrible word 'rounding errors' comes to mind , lol )

But still yet so far sl still seems to do it right, until we reach the  <library_materials> part (I guess library_effects they skip mostly due to not being in need to assign specularity etc. My guess is they just read up to the <phong> / <blinn> but I might be mistaken) 

In Collada each triangle group is separated by material and material ID. To find those you read through <library_materials>. The nodes in the library on the other hand only contains only one type of child <instance_effect> with an attribute = 'url'. Which refers to <library_effects> and completes the definition of the material.

Though it still does not clarify why it would treat material 0 differently.

What I could think of is maybe a reason of what was SL meant to be and what is it now.
Before mesh introduction everything - except the internal prims - had just one face / one material.
Speaking of sculpties here - them being the only thing a user could actively add to the environment-  thus had to be read in and stored, applied with material etc.
Sculpties could just have one material/texture. Thus there was not even a need to read for more materials then index 0, all the code in SL had to take care of was : assign material 0 to 'all' tris.
(and the internal prims also just had prolly an own predefined material structure due to having a fix / predictable number of faces for each prim where u could assign a texture to)

I am wondering if the old behavior plays a role in the code here, since SL still contains sculpties - and won't remove them any time soon for understandable reasons.

Plus you also still can on a mesh (when you do not have a certain face selected) apply one texture across the whole mesh. But that is prolly not the issue as I assume all it does it telling it to set texture (diffuse) X to material 0,1,2,3 ... At the same time.

But I still can't let go of the thought regarding sculpties and how the code may have been altered or where the procedures for mesh and sculpties maybe kind of interfere / mix up. Even with separated codeparts after detecting if its mesh or sculptie it could still intermingle somehow somewhere along the lines of interpreting tris, materials, etc.

Just an idea =)

[LeiaMelo]

Oh my god ! So talented !

Great thx for this discussion, I'm not at this level, but it's very kind to share your knowledge :matte-motes-smile:

 

 

[Codewarrior Congrejo]

haha, no problem =)
I was already afraid we would have scared you away with our rather technical debate at the end.

Cheers! Code

[LeiaMelo]

To be honest, I was lost after the second sentence :matte-motes-silly:

As the level is high and my english not excellent, i had big difficults to tranlate it.

But I don't give up and I'm sure, one day this discuss will be very helpful !

 

Big thx again for your help and your kindness.