Post by mastiphal87 in Eclipse Light Engine comments

Viewing post in Eclipse Light Engine comments

I was hoping to use this asset (https://marketplace.yoyogames.com/assets/4720/draw-sprite-pos-fixed) to fix the default draw_sprite_pos(). What is cool is that this asset allows color and alpha which is not currently supported by draw_sprite_pos(), and it fixed the weird texture effects.

So I added it in into my project, added the scripts/shader, and used the draw scripts in the normal/material events. In the material event, I ran the added script (draw_sprite_pos_fixed) including the material variable (as color), and shadow_depth variable (as alpha). In the normal event, I ran the added script (draw_sprite_pos_fixed) including the normal variable (as color), and LE_NORMAL_ANGLE variable (as alpha). Essentially, I tried to replace the ordinary draw events from the example project with this draw_sprite_pos_fixed script.

Unfortunately, the draw_sprite_pos_fixed script appears to be adding a black box around the entire sprite (and any other objects with similar draw events). This issue does not occur if either (1) I only run the script in the draw event or (2) I remove the following 2 lines from the script:

shader_set(sh_perspective);

vertex_submit(v_buffer, pr_trianglestrip, texture);

My guess is setting new shaders while the normal/material shaders are doing their work by the light engine is causing the issue. Any idea on how I might go about getting this script to be compatible? The original GM function is just not enough to make use of this powerful lighting system.

Badwrong Games1 year ago

If that asset uses a shader then it would have to be completely combined with many of the eclipse shaders. They use an extra transform that their special shader uses.

The only simple method would be to draw it first to a surface then draw it normally from that surface with the eclipse stuff. That also means getting the current shader, current MRT surfaces, etc. Then after drawing it, restore those.

Deleted post1 year ago

Deleted 1 year ago

Deleted post1 year ago

Deleted 1 year ago

mastiphal871 year ago(+1)

I've been tinkering with the system all day. I've fixed the black box and I figured I would make this post to just let anyone know if they want to use this add_on or draw_sprite_pos. So, what I've done is create a new prefab le_game_pos, which is just like le_game, except that it draws differently in the order. All it has for drawing is a draw function which uses draw_sprite_pos_fixed() (the asset I linked above).

Then, in light_engine, on the pre-composite (MRT) event (and pre-composite event), and AFTER it draws normal surface/material surface for other objects (e.g., le_game), I have it draw the normals and material for le_game_pos to each surface (surface_normal / surface_material) WITHOUT the shaders. For example, the normal code looks like:

if (!surface_exists(surface_normal)) surface_normal = surface_create(_s_width, _s_height);

surface_set_target(surface_normal);

with (__le_game_pos){ //draw script here}

surface_reset_target()

...do same for material map.

Now, since I'm not putting shaders in, the sprites may not getting the full shaders, but the lighting still applies to some extent and it does not look bad.

Badwrong Games1 year ago

Sounds, good and thanks for sharing.

Note that I use the depth buffer to sort the depth of everything when drawing the normal and material maps. If not using the depth buffer things will simply draw in order, which may be ok depending on your own game.

One reason this type of drawing isn't supported directly by Eclipse is because it would be far simpler to just do it in full 3D. For normal map to display correctly after applying a transform such as draw_sprite_pos_fixed() you need to use tangent space to create a TBN matrix. The efficient way to use that matrix is to transform the actual light positions by the transpose. Since Eclipse is more or less a 2D lighting solution (using some 3D maths) that entire process is skipped because the normal maps all sit on a plane facing upward toward the viewpoint. Its cheaper and works well with how default GM drawing works.

So, doing full 3D transformed sprites would really be easier in a normal 3D lighting solution.

Some other things to note, when drawing normal maps I use the alpha channel to encode the emissive value of that pixel. So, you would actually want to draw in 0 alpha if there would be no emissive. That can be done for the entire normal map sprite, or per-pixel in the normal map itself.

mastiphal871 year ago

That makes a lot of sense. I was just trying to add some cool top down parallax effects to add more of a 3d feel in addition to the 3d lighting. It's very impressive what this light system can do for 2d graphics. I did not want to touch 3D in GML, so I'll pass on figuring any of that out, ha!

"Some other things to note, when drawing normal maps I use the alpha channel to encode the emissive value of that pixel. So, you would actually want to draw in 0 alpha if there would be no emissive. That can be done for the entire normal map sprite, or per-pixel in the normal map itself."

I was just using the alpha setup from the other object normal draw events, which uses LE_NORMAL_ANGLE for the draw events in the events I listed. I could always have it send the emissive variable instead.

Badwrong Games1 year ago

Gotcha. So, that macro packs alpha and the rotation value into one float. Then in the shader it rotates the normal vector around the z axis according to the image angle of the instance.

itch.io

Viewing post in Eclipse Light Engine comments