Pawn Collision and Sprite Rotation

So, I’m confused as to what to do next… I know the way pawn movement and character movement works is it moves the Root and the children get ignored as far as collision is concerned. My Issue is I intended on using a Pawn for my character because that capsule component doesn’t like non-uniforn shapes (you can’t easily wrap a circle around a rectangle for example) however I can’t find out how to change the rotation of Sprites. They always import in on ZX axis and can’t be changed like you can with a 3D model. Is there any way to flip sprites so I can use a sprite as a root component and have it be on the XY instead of the ZX?

This question is about keeping Sprites as a Root and still getting them to be on the XY plane instead of ZX which leaves me with only doing 2D platformer stuff.

Before I get a response of “this has been asked before and answered” and my question locked. I searched for about an hour trying to find a solution to my problem and only found 1 question related Here

I’d really like to help answer this question, but I’m not sure I completely understand your problem, could you please try to clarify your issue?

I’ve been building a 2D game in the XY plane for a bit and I don’t seem to have the issue that I think you’re describing. But I can rotate my sprites just fine even if they are not the root component.

EX:

Collision spheres and capsule components (like the one for the Character blueprints) don’t play well with weird shapes. So my goal was to use a pawn and just use the collision from the sprite. The issue is that if the sprite is the root component you’re not allowed to use the XY plane. I was hoping there would be a solution to just “lay the sprite down flat” instead of doing something hacky like using a collision box for the root since even a box is less detailed than I’d like it.
http://puu.sh/nlDYH/d0f265c291.png Example of why I don’t enjoy the collision shapes as root components.
Red = Default size of collision shape
Green = covering the whole sprite
Black= example shape

You’re left with large areas of empty space that still act as collision or clipping as the base object is bigger than the collision. Again, this if fine for things that are shaped in sizes like 32x32 and cover MOST that space but something like a ship wouldn’t work well with a box or sphere collision component.

Is there a reason you can’t use the default scene component as the root, allowing you to rotate the child flipbook/sprite?

Yes, there is a reason.

From what I understand if I try to just use a scene component and try to move the child component (in this case a sprite) it doesn’t actually move the actor it’ll just move the child component and whatever is attached to it. It becomes really hacky to try and use this method as you start to try and do more complex things.

The issue is not being able to use Sprites as the Root and have them be anything other than the default rotation. You can use a Mesh as a Root easily because you import a Mesh with different rotations but it seems when it comes to 2D UE4 only supports it in a minimal capacity.

I think I actually understand your point more now.

Currently,as far as I know, you cannot rotate the root component of a blueprint inside of the blueprint editor. I’m fairly sure that this is by design. Here’s why: The root component denotes the primary component of an object (ie instance of a blueprint). The world transform (position, rotation and scale) of an object is entirely dependent upon the world transform of its root component. Think of it like this: the root component represents the actual location and rotation of the object

If you want to rotate the root component, you would just rotate the entire of the object instance that appears in the game world (ie. In the editor window). When you rotate the root component, you are effectively rotating the entire object. if you want your blueprint (the one that has the sprite component) to use the sprite as it’s root, then all of the other components of the blueprint will follow the transform of the sprite, and the sprite’s transform can only be changed by rotating the entire object. Meaning: There is no way for the object to default to the XY plane when you drag it into the editor (to my knowledge). However, you can very easily drag+drop the BP in to the editor, and then simply rotate the object into the XY plane (like I’ve done below):

(Before Rotation PERSP)

(After Rotation PERSP)

80211-capture5.png

(After Rotation TOP VIEW)

This will work just fine for making a game in the XY plane, although you will have to rotate your object manually.

Although I will say, using a sprite as the root is not really the best way to do things. The reason that the scene component exists is to create an object “center” that ties components together. Scene components have no collision, so you can still use a scene component as the root and use the Sprite’s fine-tuned collision.

For example, say that you have a Jack-and-Daxter, Banjo-Kazooie, or Dust-Fidget style character (if you aren’t familiar with any of these characters see this [Dust:AET video][4] ). In these instances you may have a single character object that actually consists of two separate sprites. If you make your main sprite the root component, you may run into issues. If you want to scale your main-sprite, move it, or perform almost any operation on it, you will affect all of the other connected components. Meaning, in the case of the “Dust-like” character, you would not only scale the main character, but also the companion. Sometimes this is desired, but if you wanted to keep the companion at it’s default size, it’s impossible without a crazy workaround.* The scene component would allow you to treat the main character sprite as the main sprite, but also make it possible to independently alter the secondary sprite.

To speak to the following issue:

From what I understand if I try to just use a scene component and try to move the child component (in this case a >sprite) it doesn’t actually move the actor it’ll just move the child component and whatever is attached to it. It becomes >really hacky to try and use this method as you start to try and do more complex things.

This is true, if you use a scene component, and then move the child component, then you are changing the child’s location relative to the root (in this case the scene component). But if you are trying to move an object that is visually represented by a sprite component, then you shouldn’t be moving the sprite component. Instead, you should be moving the entire object, IE the root.

Hope that helps some.

*This workaround would involve creating an entirely separate companion character that has to constantly track the location of the main character and move to that location, which can potentially introduce more overhead.

See my answer below, but for short: If you’re trying to move the actor as a whole, then you should move the actor, not the sprite component (unless you are intentionally trying to move the visual representation away from the actual object).

how exactly would you move the actor if you’re using a pawn with a Root of “Scene”? using FloatingPawnMovement doesn’t work because it teleports children, ignoring their collision. This isn’t a different question but related to my issue. As you said Scene doesn’t have collision so using the movement component means all the children don’t have their collision counted.

To be honest… I’m not sure. According to the documentation, you’re right about FloatingPawnMovement. I’ve never personally seen issues with FloatingPawnMovement and the setup I described, but given the documentation, it’s likely I’ve just never set up a situation that causes issues. My first thought is to scramble around and try a different movement component (Interp_To_Movement looks like a good candidate). However, I will say that if you are shooting for a 2D-style game in the X,Y plane, it may just be better to do things the old fashioned way. Meaning, remove you movement component entirely and manually move your sprite blueprint around the world (AddActorWorldOffset and similar). In my 2D game, I have movement set up this way because I’m shooting for a more retro theme and control style.

mind sharing how AddActorWorldOffset works better? AddActorWorldOffset | Unreal Engine Documentation says with sweep on it only cars about the root component still. So, I’m STILL limited to capsules, spheres and boxes which just won’t cut it for something that isn’t just a “top down guy taking up most the sphere”.

a 2D spaceship would NEVER work in this case. Imagine a triangle ship if you would. There is seemingly zero solutions that wouldn’t make the ship either collide too far away or clip through things.

Sorry for the delayed response. This week’s been pretty busy. Anyhow: It doesn’t really matter HOW you move your character (or to be less specific your blueprint–actor-- of any type). When you read that documentation, it’s primarily talking about ROOT actors with collision. Scene components do no have collision. Therefore, the collision of your object when you use a scene component as the root, depends on the component highest in the hierarchy which has collision settings. For example:

these sprites both have a scene component as their root, but their collision is entirely dependent upon the collision of the sprites as shown in this image:

and this image:

.

If you want to use true collision to simulate hit events, then you will need to turn on “Simulate Physics” on your two actors and then add velocity/force (instead of AddActor____Offset, affects the actor kinematically (ie without using the physics engine)).

The point: if you have a scene component as your root component, the object’s collision can still be determined (more or less) by the collision of the representative sprite.

Hope that helps.

EDIT: To see my images well, you may need to right click them and do “Open in new Tab”