Hey Adrei,
How familiar are you with Corona? If I asked you to make an object and then attach a touch joint to it, would that make sense to you?
This is definitely a solvable problem by the way.
I’m digging into your code a little bit and a few things pop out at me. I’m not quite sure what the logic is behind your Remap functions [lua] posX = Remap(posX, -1,1,0,1)
posY = Remap(posY, -1,1,0,1)[/lua]
It seems like it might be better to use raw trig functions anchored by physical positions (making the light a display object to you can observe it better) rather than relative positions. With relative positions the math might seem like it’s working but then quadrant issues pop up and there is no way to see why (without an observable object that lets you say - "Oh!, the computer thinks the light is here!).
Your normal maps look a little odd to me but I might just be used to my own workflow. I use Sprite Illuminator, what are you using?
I totally understand wanting your own codebase for shading but just in case you throw in the towel, I recently changed the Dynamic Shader to a subscription to encourage more people to try it.
Another tip, use real life objects and a ton of drawing calculations to help you figure out all the trig.
More thoughts. . .
I find that it’s easy to come up with calculations that are trig approximations but they inevitably fail at some point. In all the mess of calculations, keep in mind the following:
-
The y axis is reversed in Corona
-
Rotation is measured clockwise and starts at 12 o’clock
-
trig angles calculations go counter-clockwise and start at 3’clock
If any of these three things is overlooked, the calculations will fall apart in one quadrant or another.
Not very familiar, just started using it about a week ago.
I’m digging into your code a little bit and a few things pop out at me. I’m not quite sure what the logic is behind your Remap functions
- posX = Remap(posX, -1,1,0,1)
- posY = Remap(posY, -1,1,0,1)
This supposed to normalize the value from [-1,1] to [0,1] range - corona texture space.
Your normal maps look a little odd to me but I might just be used to my own workflow. I use Sprite Illuminator, what are you using?
I use 3D applications like Cinema4D, or Blender. I used Blender for this one.
I am definitely considering your plugin. How do they work anyway? Since they are on the server, does this mean I can only apply it during build and not in simulator?
Thanks for looking into this, by the way.
You actually got me thinking on inverted Y axis, and since I got the desired light motion there is probably nothing to do in my code anymore. The issue is with normal data that affects the actual shading / light casting.
I made this normal map by baking in onto another plane using object space and setting Y normal to -Y, guess what? The point light result is exactly what I was after! the directional light is still off - instead of going full circle around the plane, it appears to bounce from 0 to 90 degrees. Getting closer! 
Point light, correct!
Directional light, not so 
I think I got satisfactory result with point light for now, will post back if I find anything new on directional light normals.
Thanks for input.
Yeah, I thought those normal maps looked funky!
You were using the same normal map for the point and directional lighting? If so, that doesn’t really make sense to me unless it’s a normal map setting issue again. Try adjust the directional z value as well.
@sporkfin: Yes, same map, I used constant value for Z coordinate, thought it only affects the “height” of the light from the surface. Hmm…
--dirLightDirection testPlate.fill.effect.pointLightPos = { posX, posY, 0.2}