Assigning multiple materials to a polygon

[Tomos Halsey]

Unfortunately none of the DAE files in the examples show signs of "sharing the same polygons". If we take a look at the COLLADA Documentation here it dictates that geometry is defined inside of the <mesh> tags wich contain sets of <triangles> tags. These tags get assigned materials by defining a material attribute that corresponds with a defined <library_materials> tag further up in the file.

So with that being said if we look into the files provided we can see two sets of <triangles> inside the <mesh> tags. This means that there is litteratly TWO sets of identical mesh with two seperate materials assigned so what does this mean? It means that this isn't an SL "bug" but an exporter bug that writes a DAE file with double the polys in overtop of the previously defined set. SO the uploader isnt "glitching" or "bugging" at all but just reading a normal COLLADA file with two sets of gerometry and two material faces.

Here is our proof that the example files from the youtube page are just normal COLLADAS.

<library_materials>    <material id="ccc" name="ccc">      <instance_effect url="#ccc-fx"/>    </material>    <material id="bbb" name="bbb">      <instance_effect url="#bbb-fx"/>    </material></library_materials>

 And the corresponding triangles the materials are being assigned to...(i truncated a little to save space)

<library_geometries>    <geometry id="wall_test-lib" name="wall_testMesh">      <mesh>        <source id="wall_test-POSITION">          <float_array id="wall_test-POSITION-array" count="96">-146.407776 -118.058250 0.000000146.407776 -118.058250 0.000000-146.407776 118.058250 0.000000146.407776 118.058250 0.000000-86.165428 19.481628 0.000002-86.165428 -19.481628 -0.00000286.165428 -19.481628 -0.00000286.165428 19.481628 0.000002[...]</float_array>          <technique_common>            <accessor source="#wall_test-POSITION-array" count="32" stride="3">              <param name="X" type="float"/>              <param name="Y" type="float"/>              <param name="Z" type="float"/>            </accessor>          </technique_common>        </source>        <source id="wall_test-Normal0">          <float_array id="wall_test-Normal0-array" count="522">0.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.000000[...]</float_array>          <technique_common>            <accessor source="#wall_test-Normal0-array" count="174" stride="3">              <param name="X" type="float"/>              <param name="Y" type="float"/>              <param name="Z" type="float"/>            </accessor>          </technique_common>        </source>        <source id="wall_test-UV0">          <float_array id="wall_test-UV0-array" count="168">0.000000 0.0000000.638178 0.0000000.371744 0.1628240.266434 0.1628240.894690 0.4951810.638178 0.7914250.198716 0.9196800.093406 0.919680[...]</float_array>          <technique_common>            <accessor source="#wall_test-UV0-array" count="84" stride="2">              <param name="S" type="float"/>              <param name="T" type="float"/>            </accessor>          </technique_common>        </source>        <vertices id="wall_test-VERTEX">          <input semantic="POSITION" source="#wall_test-POSITION"/>        </vertices>        <triangles count="58" material="ccc">          <input semantic="VERTEX" offset="0" source="#wall_test-VERTEX"/>          <input semantic="NORMAL" offset="1" source="#wall_test-Normal0"/>          <input semantic="TEXCOORD" offset="2" set="0" source="#wall_test-UV0"/>          <p>9 0 9 10 1 80 11 2 81 11 3 81 8 4 8 9 5 9 2 6 0 0 7 1 5 8 2 5 9 2 4 10 3 2 11 0 [...]</p>        </triangles>        <triangles count="58" material="bbb">          <input semantic="VERTEX" offset="0" source="#wall_test-VERTEX"/>          <input semantic="NORMAL" offset="1" source="#wall_test-Normal0"/>          <input semantic="TEXCOORD" offset="2" set="0" source="#wall_test-UV0"/>          <p> 9 0 9 10 1 80 11 2 81 11 3 81 8 4 8 9 5 9 2 6 0 0 7 1 5 8 2 5 9 2 4 10 3 2 11 0 [...]</p>        </triangles>      </mesh>    </geometry>  </library_geometries>

 

Yeah, so overall it looks like there is no Black Magic or Magical Bugs that allow for this. It's just a simple file with duplicated polys that have two seperate materials on them.

[Johnny Bunderfeld]

Thank you Kit! 

I've been pulling my hair out, trying to figure out why I couldn't duplicate the results from your youtube video showing the brick wall and the shadows.  I didn't understand that you HAD to use the FBX exporter to convert the files over.  This simple paragraph of yours, explaining why the exporter is a must has done wonders for me. I was able to get your results in minuets.

I'm now off to create! Thank you x1000!

[Selina Anatra]

Has anyone had an issue with the new 5.0 viewers uploading meshes with this trick applied?  I've been getting an error parsing the file, but when I strip the duplicate material definitions its ok.

[Achille Putzo]

On 3/11/2015 at 6:18 AM, Tomos Halsey said:

Unfortunately none of the DAE files in the examples show signs of "sharing the same polygons". If we take a look at the COLLADA Documentation here it dictates that geometry is defined inside of the <mesh> tags wich contain sets of <triangles> tags. These tags get assigned materials by defining a material attribute that corresponds with a defined <library_materials> tag further up in the file.

So with that being said if we look into the files provided we can see two sets of <triangles> inside the <mesh> tags. This means that there is litteratly TWO sets of identical mesh with two seperate materials assigned so what does this mean? It means that this isn't an SL "bug" but an exporter bug that writes a DAE file with double the polys in overtop of the previously defined set. SO the uploader isnt "glitching" or "bugging" at all but just reading a normal COLLADA file with two sets of gerometry and two material faces.

Here is our proof that the example files from the youtube page are just normal COLLADAS.

<library_materials>    <material id="ccc" name="ccc">      <instance_effect url="#ccc-fx"/>    </material>    <material id="bbb" name="bbb">      <instance_effect url="#bbb-fx"/>    </material></library_materials>

 And the corresponding triangles the materials are being assigned to...(i truncated a little to save space)

<library_geometries>    <geometry id="wall_test-lib" name="wall_testMesh">      <mesh>        <source id="wall_test-POSITION">          <float_array id="wall_test-POSITION-array" count="96">-146.407776 -118.058250 0.000000146.407776 -118.058250 0.000000-146.407776 118.058250 0.000000146.407776 118.058250 0.000000-86.165428 19.481628 0.000002-86.165428 -19.481628 -0.00000286.165428 -19.481628 -0.00000286.165428 19.481628 0.000002[...]</float_array>          <technique_common>            <accessor source="#wall_test-POSITION-array" count="32" stride="3">              <param name="X" type="float"/>              <param name="Y" type="float"/>              <param name="Z" type="float"/>            </accessor>          </technique_common>        </source>        <source id="wall_test-Normal0">          <float_array id="wall_test-Normal0-array" count="522">0.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.0000000.000000 0.000000 1.000000[...]</float_array>          <technique_common>            <accessor source="#wall_test-Normal0-array" count="174" stride="3">              <param name="X" type="float"/>              <param name="Y" type="float"/>              <param name="Z" type="float"/>            </accessor>          </technique_common>        </source>        <source id="wall_test-UV0">          <float_array id="wall_test-UV0-array" count="168">0.000000 0.0000000.638178 0.0000000.371744 0.1628240.266434 0.1628240.894690 0.4951810.638178 0.7914250.198716 0.9196800.093406 0.919680[...]</float_array>          <technique_common>            <accessor source="#wall_test-UV0-array" count="84" stride="2">              <param name="S" type="float"/>              <param name="T" type="float"/>            </accessor>          </technique_common>        </source>        <vertices id="wall_test-VERTEX">          <input semantic="POSITION" source="#wall_test-POSITION"/>        </vertices>        <triangles count="58" material="ccc">          <input semantic="VERTEX" offset="0" source="#wall_test-VERTEX"/>          <input semantic="NORMAL" offset="1" source="#wall_test-Normal0"/>          <input semantic="TEXCOORD" offset="2" set="0" source="#wall_test-UV0"/>          <p>9 0 9 10 1 80 11 2 81 11 3 81 8 4 8 9 5 9 2 6 0 0 7 1 5 8 2 5 9 2 4 10 3 2 11 0 [...]</p>        </triangles>        <triangles count="58" material="bbb">          <input semantic="VERTEX" offset="0" source="#wall_test-VERTEX"/>          <input semantic="NORMAL" offset="1" source="#wall_test-Normal0"/>          <input semantic="TEXCOORD" offset="2" set="0" source="#wall_test-UV0"/>          <p> 9 0 9 10 1 80 11 2 81 11 3 81 8 4 8 9 5 9 2 6 0 0 7 1 5 8 2 5 9 2 4 10 3 2 11 0 [...]</p>        </triangles>      </mesh>    </geometry>  </library_geometries>

 

Yeah, so overall it looks like there is no Black Magic or Magical Bugs that allow for this. It's just a simple file with duplicated polys that have two seperate materials on them.

is it possible to create a videotutorial?

[Kyrah Abattoir]

I'd like to point out that, despite the interesting results, this is not lightmapping, so it still is effectively a normal rendering pass followed by an (expensive) alpha blending pass.

[Macrocosm Draegonne]

8 hours ago, Kyrah Abattoir said:

I'd like to point out that, despite the interesting results, this is not lightmapping, so it still is effectively a normal rendering pass followed by an (expensive) alpha blending pass.

I was wondering about that , Is there any way we can test this more detailed? 

I was curious if since the textures are in the exact same space that the renderer wouldnt have to calculate the alpha more than once right? 

Even if you moved about with the camera there should be not be a need for another alpha pass on the same surfaces already in view right? There is nothing to calculate as far as difference behind the alpha, unless it just recalculates it all again because thats how it works?

When I tested there was zero performance loss, so its hard to know without good testing to see what its doing.

Edited October 26, 2018 by Macrocosm Draegonne

[Kyrah Abattoir]

Rendering is always done in two passes

Pass 1, front to back for opaque objects.

Pass 2, back to front for transparent objects.

For an isolated object there won't be any noticeable performance cost, but you're still rendering everything twice, the real test is if something like this becomes widespread.

Will the cost of rendering that second alpha map be offset by the reduction in texture usage, basically.

Linden labs give us a lightmapped shader already...

[Macrocosm Draegonne]

48 minutes ago, Kyrah Abattoir said:

Rendering is always done in two passes

Pass 1, front to back for opaque objects.

Pass 2, back to front for transparent objects.

For an isolated object there won't be any noticeable performance cost, but you're still rendering everything twice, the real test is if something like this becomes widespread.

Will the cost of rendering that second alpha map be offset by the reduction in texture usage, basically.

Linden labs give us a lightmapped shader already...

Ok, I see what you're saying, I believe I read somewhere (an unconfirmed theory) that when the alpha occupied the exact same space as a plain diffuse it possibly wouldn't have to work as hard.  I will try and devise a way to test it better.

Oh, and yes I totally agree, more shaders!   I bet they want to add more but its waiting on other work to clear first.

[Kyrah Abattoir]

By definition alpha textures are always rendered in "front" of something opaque (even if it's just the sky).

As for more shaders, one can hope.

[Macrocosm Draegonne]

21 hours ago, Kyrah Abattoir said:

By definition alpha textures are always rendered in "front" of something opaque (even if it's just the sky).

As for more shaders, one can hope.

I guess it depends on how opacity is calculated, I generally prefer as few as is possible on alpha blends, however i didnt get any of the performance hit when the surfaces were low-poly, the exact same size (a joined copy), and zero space separating them, diffuse in the back, alpha the child layer.  It seemed as though the renderer did one pass on that and didnt have to calculate it again because there was no angle change between the two layers.  There must be a way to know, but I bet it would take reading the code of alpha rendering, which its probably huge mindnumbing code lol!  I will make some more versions to test, and see what of the dev widgets in the viewer might give some clues, and if there is any performance benefit at all or its just an illusion because it looks so much better, everything seems better lol.