Is there any way to use Normal Maps on image sheets?

I have an image sheet with characters that are to be used in a sprite animation. I’ve also created a second image sheet with a normal map of the characters (same exact layout). I can’t find a way to use these two image sheets so that I can get a nice lighting effect on the characters using the composite effects with 1 point light.

At the moment it seems to be an impossible task.

Can anyone shed some light on this?  ( pun intended  ;) )

CompositePaint and Sprites don’t mix. Why they don’t and why they didn’t make them so, I do not know. I wanted to do something similar with adding different effects on top of a sprites (frozen, burnt etc) using compositePaint.  I was told that it isn’t possible at the moment. I did add a feature request in January. It probably won’t get far, but I have to try. Just doing color changes with filters looks so-so and creating dozens of alternate sprites for various effects would be a huge undertaking.

http://feedback.coronalabs.com/forums/188732-corona-sdk-feature-requests-feedback/suggestions/6935528-allow-compositepaint-to-be-used-with-animated-spri

It’s a shame. It’s the first time I’m looking at using some of the more advanced shader features of Graphics 2, and not being able to use normal maps on image sheets and sprites is severely limiting the usefulness of the effects. If anything I’d think it just *has* to be available for sprites.

I hate to admit it, but it looks like I might have to start looking more seriously at the other game engines that begin with “U”.   :unsure:

CompositePaint does work with imagesheets in general, just not sprite objects. I want to believe it was just an oversight and they will implement it. However being Corona SDK is mostly a game creation SDK, sprites should of been top of the list for all the fancy 2.0 features to be compatible with. My guess they have moved on and it would require a lot of requests to get implemented now.

 
Hear, hear!
 

My guess they have moved on and it would require a lot of requests to get implemented now.

…that’s what I fear.

Yea, this is an oversight. We’re still recovering from GDC, but it’s on our radar.

And off the top of my head, the one thing that’s awkward is that the sprite object’s image sheet corresponds to “paint1” in the composite paint. We’ll have to think about what the cleanest way to express this in the Lua API, given this awkwardness. Maybe the simplest is to omit “paint1”

local compositePaint = {     type = "composite",     -- paint1 is nil, so object's paint1 is not updated     paint2 = { type="image", filename="dust.png" } } sprite.fill = compositePaint

Oh, of course, the other limitation is that the same texture coordinates used in “paint1” will also be used in “paint2”, so the frames in the image sheets you use for both textures have to match up.

Does that work for the majority of scenarios you’re using?

Thanks for the reply.
 

Does that work for the majority of scenarios you’re using?

 
As far as I can see, yes.

I’ve been using Sprite Illuminator to create the Normal Maps for my sprite sheets, so they will have an identical layout.

I will just add my 2 cents so there is another voice to this discussion. My requirements differ from those of ingemar.

If I am understanding your limitation, to require another imagesheet that more or less mirrors the original sprite’s imagesheet in size and frame structure, it would fail in purpose for me. If I need twice the texture memory to achieve the effect, it would just be better to make the second imagesheet the sprites + overlay already combined in photoshop and just switch up the sprite.

Ideally the compositePaint would just not need paint1 (this would be whatever frame the sprite is) and paint2 would need to be an image big enough to cover the largest frame used in that sprite object.

Below will be examples of what I am trying to accomplish. The examples shows one sprite frame, 3 overlay graphics that are the size of the frame and the end results with the overlays blended into the frame for different effects (frozen, burning, poisoned). Three small images, that if made the right size I could use across multiple sprite object in an entire game.

The sprite frame.

example.png

Example of frozen.

overlay1.png example1.png

Example of burning.

overlay2.png example2.png

Example of poisoned.

overlay3.png example3.png

@ingemar, do you have a sample set of image sheets (one with the sprite, and the other with a normal map) that we could use as we implement this?

@anderoth, having separate uv’s for the second texture would require increasing the vertex element size. That requires deeper investigation especially to understand potential performance implications given the cache locality changes. We’re inclined to get the simple case (same uv’s) working as a first step before committing to more complex cases (different uv’s for each texture)

@walter 

I’ll whip up a sample project. I guess the easiest way to submit and track this would be to post it as a bug report. 

I’ll report back with a case number once I’m done.

Yup, bug report would be perfect.

Using Normal Maps with sprite sheets reported as Case 39633.

Hi Walter,

we need to do the same stuff as Anderoth, we are

* using a snapshot of our liquidFun-particles to generate a texture of our water

* the water texture then is set to alpha = .5 to make it semitransparent and then we use a filter to enhance the edges (looks nice)

Now I would love to use CompositePaint to use my custom fragment water shader with two textures:

The first texture is my semitransparent water, the second texture is the background behind the water. With this I could make the view through the water very realistic.

So it’s in principle the same case as with Anderoth, I need to apply a snapshot of my parallax background directly to paint2 - I don’t want to save the snapshot to a file and then apply it as paint2, this is needed every frame and would be hell for the performance.

Best,

Andreas

CompositePaint and Sprites don’t mix. Why they don’t and why they didn’t make them so, I do not know. I wanted to do something similar with adding different effects on top of a sprites (frozen, burnt etc) using compositePaint.  I was told that it isn’t possible at the moment. I did add a feature request in January. It probably won’t get far, but I have to try. Just doing color changes with filters looks so-so and creating dozens of alternate sprites for various effects would be a huge undertaking.

http://feedback.coronalabs.com/forums/188732-corona-sdk-feature-requests-feedback/suggestions/6935528-allow-compositepaint-to-be-used-with-animated-spri

It’s a shame. It’s the first time I’m looking at using some of the more advanced shader features of Graphics 2, and not being able to use normal maps on image sheets and sprites is severely limiting the usefulness of the effects. If anything I’d think it just *has* to be available for sprites.

I hate to admit it, but it looks like I might have to start looking more seriously at the other game engines that begin with “U”.   :unsure:

CompositePaint does work with imagesheets in general, just not sprite objects. I want to believe it was just an oversight and they will implement it. However being Corona SDK is mostly a game creation SDK, sprites should of been top of the list for all the fancy 2.0 features to be compatible with. My guess they have moved on and it would require a lot of requests to get implemented now.

 
Hear, hear!
 

My guess they have moved on and it would require a lot of requests to get implemented now.

…that’s what I fear.

Yea, this is an oversight. We’re still recovering from GDC, but it’s on our radar.

And off the top of my head, the one thing that’s awkward is that the sprite object’s image sheet corresponds to “paint1” in the composite paint. We’ll have to think about what the cleanest way to express this in the Lua API, given this awkwardness. Maybe the simplest is to omit “paint1”

local compositePaint = {     type = "composite",     -- paint1 is nil, so object's paint1 is not updated     paint2 = { type="image", filename="dust.png" } } sprite.fill = compositePaint