You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to be able to have parallax-ish effects on background (behind the main world) and foreground (in front of the main world). The most sensible way for this, with the most flexibility, seems to be to swap the OrthographicProjection of the Camera2dBundle with a PerspectiveProjection.
That works neatly, however, it requires that the Z axis of the transform of the objects is set correctly.
For instance, bevy_ecs_ldtk sets the Z coordinate of the LDTK layers in increments of 1, starting at 0 for each level. I could modify that crate to instead use a value from an ldtk attribute in order to have more fine-grained control over the layers.
Then I could put background layers e.g. at z = -1, the main world at z = 0, and the foreground at z = 1.
However, I would also want the player to be at z = 0, but always render in front of the main world (but behind the foreground). I could set the player z to 0.0001, but that seems like a crude hack (and I don't know if this might still cause visual artifacts or even z-order-fighting under odd transform conditions).
Ideally, there would be an optional struct ZSortOverride(pub f32) component I could add to sprites rendered with the 2d pipeline which makes those entities which have that component use the ZSortOverride value instead of the Z value from the transform when they set the sort_key of the Transparent2d struct.
It seems that hacking that into bevy_ecs_tilemap and bevy_ecs_ldtk would be simple, however I'd also need support for this for standard bevy sprites, because I'm not keen on reinventing sprite rendering.
Is this a viable approach I'm taking here? Is this something which could get merged?
As for now, I'll look into patching the ldtk crate to allow me to override the Z value and see where that gets me, but I'd still like to have this discussion.
I am aware of #1275, but I'm not sure if that explicitly decouples transform-z from order-z, and also not how much traction that currently has.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi there!
I'm looking into making a platformer game.
I would like to be able to have parallax-ish effects on background (behind the main world) and foreground (in front of the main world). The most sensible way for this, with the most flexibility, seems to be to swap the OrthographicProjection of the Camera2dBundle with a PerspectiveProjection.
That works neatly, however, it requires that the Z axis of the transform of the objects is set correctly.
For instance,
bevy_ecs_ldtk
sets the Z coordinate of the LDTK layers in increments of 1, starting at 0 for each level. I could modify that crate to instead use a value from an ldtk attribute in order to have more fine-grained control over the layers.Then I could put background layers e.g. at z = -1, the main world at z = 0, and the foreground at z = 1.
However, I would also want the player to be at z = 0, but always render in front of the main world (but behind the foreground). I could set the player z to 0.0001, but that seems like a crude hack (and I don't know if this might still cause visual artifacts or even z-order-fighting under odd transform conditions).
Ideally, there would be an optional
struct ZSortOverride(pub f32)
component I could add to sprites rendered with the 2d pipeline which makes those entities which have that component use theZSortOverride
value instead of the Z value from the transform when they set thesort_key
of theTransparent2d
struct.It seems that hacking that into
bevy_ecs_tilemap
andbevy_ecs_ldtk
would be simple, however I'd also need support for this for standard bevy sprites, because I'm not keen on reinventing sprite rendering.Is this a viable approach I'm taking here? Is this something which could get merged?
As for now, I'll look into patching the ldtk crate to allow me to override the Z value and see where that gets me, but I'd still like to have this discussion.
I am aware of #1275, but I'm not sure if that explicitly decouples transform-z from order-z, and also not how much traction that currently has.
Beta Was this translation helpful? Give feedback.
All reactions