Another question regarding lighting a sprite

[Michael]

Hello everyone,

I was hoping someone could help me with the generation of the normals for our sprites:
The spritesheets used have the option normals only enabled, and that works from one side, however it only seems to be generating them for the front side of the sprite, and not the back. Our sprites are getting flipped continuously, so I was wondering if there is any way to tell tk2d to generate the invert normals for the mesh as well, so both sides work ?
Thanks very much!

[unikronsoftware]

3 options.

Option 1 - Simple shader option - The shader needs to use a hard coded normal which isn't affected by the transform matrix, always pointing out of the screen. You won't be able to correctly rotate the sprites on the X or Y axis, though you normally wouldn't need to do this with 2d sprites. Z rotation will work just fine. Another downside is it won't work in fixed function, but does anyone care about this any more?

Option 2 - Not so simple but will work in any case - Modify the sprite collection builder so it builds both front and back facing polygons. This is really really simple as the runtime code is built to cope with any arbitrary number of polygons. Change the shader and set cull mode to defaults (CCW, I think). Now everything should work just fine.

Option 3 - Get our lighting plugin (it'll be really cheap, but it isn't ready yet...). That does stuff very differently to the suggestions above, but I've not had the time to turn it from prototype to product just yet.

[Michael]

Thank you for the quick response, in regards to the options mentioned, the second option seems the one that will be most useful, so I've been tinkering with getting that to work, but I must be making quite some silly mistakes here.

Going through the SpriteCollectionBuilder, it seems to me that the polygons are being set up in the UpdateVertexCache() ? (line 1246). The positions just set up the points of the rectangle (Ignoring the custom geometry part, as that's not being used ), and the actual polygons are instantiated at
1525: if (!thisTexParam.customSpriteGeometry): Which sets up the indices.

Thinking in DirectX terms, the indices would be ones that actually set up the polygons, as the 6 indices basically relate to 2 triangles with each 3 points. So with that in mind I changed the following part to create more indices than the standard front side

            _{// build sprite definition
            if (!thisTexParam.customSpriteGeometry)
            {
               coll.spriteDefinitions.indices = new int[ 6 * (positions.Count / 2) ]; //(/4 became /2) Get double of indices instead of only 6, so the back can be created as well
               for (int j = 0; j < positions.Count / 4; ++j)
               {
                  //Triangles
                  //0,3,1
                  //2,3,0
                  coll.spriteDefinitions.indices[j * 6 + 0] = j * 4 + 0;
                  coll.spriteDefinitions.indices[j * 6 + 1] = j * 4 + 3;
                  coll.spriteDefinitions.indices[j * 6 + 2] = j * 4 + 1;
                  coll.spriteDefinitions.indices[j * 6 + 3] = j * 4 + 2;
                  coll.spriteDefinitions.indices[j * 6 + 4] = j * 4 + 3;
                  coll.spriteDefinitions.indices[j * 6 + 5] = j * 4 + 0;
                  
                  //Triangles
                  //1,0,3
                  //0,2,3
                  coll.spriteDefinitions.indices[j * 6 + 6] = j * 4 + 1;
                  coll.spriteDefinitions.indices[j * 6 + 7] = j * 4 + 0;
                  coll.spriteDefinitions.indices[j * 6 + 8] = j * 4 + 3;
                  coll.spriteDefinitions.indices[j * 6 + 9] = j * 4 + 0;
                  coll.spriteDefinitions.indices[j * 6 + 10] = j * 4 + 2;
                  coll.spriteDefinitions.indices[j * 6 + 11] = j * 4 + 3;
               }
               coll.spriteDefinitions.complexGeometry = false;
            }}


Sadly no cigar. Am I looking in completely the wrong place, or just missing something extra perhaps ?

[unikronsoftware]

Yup, its not quite as straightforward as that. Thankfully, its not too complicated either.

Why your change didn't work is the new indices use the same vertices. As they share normals, the backfacing (0, 0, -1) and forward facing (0, 0, 1) normals get averaged out to (0, 0, 0).

What you need is to duplicate the vertices to make sure the normals don't get cancelled out. So all that needs to be done is:

Code: [Select]

// build sprite definition
if (!thisTexParam.customSpriteGeometry)
{
positions.Add(positions[3]); uvs.Add(uvs[3]);
positions.Add(positions[1]); uvs.Add(uvs[1]);
positions.Add(positions[2]); uvs.Add(uvs[2]);
positions.Add(positions[0]); uvs.Add(uvs[0]);

That adds a duplicate set of vertices in the right order for the next bit of code - no further changes required. I will add it as an option to the builder... probably under an "Advanced" tab somewhere.

[Michael]

Thanks very much, that worked great !

[Michael]

Sorry for resurrecting this topic back all of a sudden, but we only just noticed an issue with the lighting now that our characters are running through really light varying environments.

The back side of the sprite seems to be lit much brighter than the front. Would there be anything else that could be the cause of this ?

[unikronsoftware]

I'd put a plane in the scene to ensure there isn't some weird lighting in the scene. The front and the back should behave identically to any other object in the scene.

[cworboys]

I will add it as an option to the builder... probably under an "Advanced" tab somewhere.

Did this ever make it into an update?  If so, where can I access it?

[unikronsoftware]

Yes it did. In the sprite collection editor, select the sprite you want to make 2 sided, and select "Double Sided" for Render Mesh.