Check your P.M inbox.If it works i would have asked for a warm cup of british tea as a reward but it is too **** hot (for winter) where i live right now, so i will stick with beer offer . 
Thanks a lot yet again, .
I have tested your materials in 2D side scroller project you uploaded, but unfortunately sprite still looks wrong 
On screenshot from your Spartan game project it looks perfect, so there must be some random setting in your project that is fixing problem.
(**: **If you’re reading , it would be great if you could comment on problem as well. It’s peculiar that it doesn’t look correct, even when using Paper2D demo scene with recommended TranslucentUnlitSpriteMaterial)
Can I make flipbooks cast shadows like normal sprites?
There seems to be lots of commits from over last week or so. Mostly involving switching over of 2d editors into their own editors and modes in UI (notably tileset editor). Thanks for work your putting in .
Any chance tileset painting bug (where it paints a tile offset +1 in x&y in viewport) could be looked at please?
So, I was finally able to find a way to cut sprites in UE4, (watch video of it here: https://www…com/3DZJV791RsQ)
only limitation with above is physics. I split sprites by essentially duplicating sprites, and alphaing out parts to create pieces. works great, its fast, and looks good. However, I’m not able to create Sprite Actors dynamically, so basically I use Parent Sprite’s and construct more of those and set its sprite to new ones I created, consequently their Physics Bodies are still size of Original sprite.
Looking at what others did for Dynamic Meshes, I assume I could create a subclass off of UPaperSprite to do same, but I’m not sure if would be enough to get creating dynamic sprite actors to work.
Noland if you out there, can you give me any direction to push over finish line?
Just to follow up on transparency issue, it seems that problem stems from using a 32-bit texture with an alpha channel as opposed to using a 24-bit diffuse texture + a separate 8-bit alpha texture.
32-bit textures are consistently too bright and exhibit alpha artifacts whereas same texture split up in a 24-bit diffuse texture and an 8-bit alpha channel texture are rendered correctly… 
As far as I can tell, it’s in fact a general problem with Translucent Unlit materials (i.e. Paper2D is most likely not to blame), so I have posted a new thread about problem over here.
“Paper2D: Fix off-by-one rendering for orthogonal tile maps”
Thank you
Hey !
Now that you are back and in full force may i ask for something that is very simple for you to make but it will be a huge time saver for us?
As you already know when we import flipbooks from Texturepacker system takes sprites coordinates from texture through file.Every time we pack something texture packer automatically (and depending setting we give it like 1024x1024,1024x512,2048x1024 etc) assigns sprites into different columns (x,y) rows and thus EVERY time we add a new animation new sprites have different coordinates in both X and Y axis.
means that if we want to align our animations (for example idle,run,attack,jump etc) we need to first figure out how many pixels we need to move all sprites of a particular animation in both axis and then change one by one (or if you are lucky and you have many sprites packed in same row then with property matrix you can sort them and save some time but that means that you have to work double hard on other axis ) all of origin points.
Imagine that it took 2 people and one of us had a calculator (YES a CALCULATOR!) adding (for example)3 pixels in X axis and 17 in Y .He was adding numbers like 3248( is coordinate of sprite within texture) + 17 then telling me result and i had to input it one by one in right field.After a few hundred sprites you would make a mistake and then one frame of animation was off , you had to figure out which one was it and then go back and fix it.
I am no programmer but i think it is super easy for you to create 2 fields (x,y) where we can input numbers and then system can automatically add them or subtract them from original coordinates.It would literally take us seconds to align animations with zero mistakes and it would save us countless hours of tedious and unnecessary work.
Please fix .Dont make me beg…
umm , I’m not sure if I follow you but if TexturePacker provides the .paper2dsprites with missinformation about coordinates it is not unreal editor job to fix it!
I mean, I think that if you have to offset texturepacker because it does not respect your original coordinates, then blame should be for texturepacker or your animation tool.
I use texturepacker and it works nice for me :S
problem is not with texturepacker but with unreal and how it manipulates data from texturepacker.
It is a little difficult to explain with words but let me try.Lets say that you have a jumping animation.your player starts from bottom center of your png.While he jumps his body is moving away from bottom and going up. changes size of png.If your player is 100px and jumps 500px then you end up with a last frame of 600px tall.correct?
Now if you want to keep your texture size small (2048x2048) for size and memory reasons (especially mobile) you need to crop 500px of white space so you can keep everything neat and tidy.problem lies in fact that your player until he reaches his maximum jump height he has to go through all sort of different Y numbers (height).He starts from Y=0 then next frame is Y=17 then Y=45 and so on until he reaches 500.Now with all those different png sizes Texture packer puts them in most efficient way possible inside a texture but that means random x and y coordinates for every frame.So if you want for any reason to offset something you are screwed! only solution to is if lets us input an offset that automatically is getting added to original coordinates. Trust me. i have more than 60 animations and a few thousand sprites currently in my game and it is a nightmare if you ever need to change anything with current system.
Umm I might be missing something but what I do is set option of “trim images” in TexturePacker and it does all trimming and you can forget about having textures with big white(transparent)spaces … does it work for you? or you have any other issue?
Yesterday i received an answer regarding translucent z order issues.If you want to read about it (especially my fellow alldogsgotoheaven) here is link : Rendering "Jerkiness" in Unreal (Paper2D) + Translucent Z order issues - Rendering - Epic Developer Community Forums
Now that works in tilemap editor i have a suggestion to make.Please expose per layer in tile map editor.Let us set z order for a layer and whatever enters there it can automatically have that Translucency Sort Priority.It will be so much faster and less prone to mistakes.way it works now is (let me use my favorite word ) tedious.You have to be really careful what you choose (not easy when you have 12000 sprites in there) and you need to open every blueprint that has a sprite or flipbook and set it manually.And not to mention that if for any reason you want to use that BP on a different Translucency Sort Priority setting you need to make another one!
It has nothing to do with trimming.Texture packer works wonderfully!problem is with how difficult it is to set a custom pivot point for any given flipbook.Instead of only inputting an offset number and unreal do rest for you ,you now have to MANUALLY change all sprites origin point one by one.If you have a flipbook that contains 60 sprites and you need to change x and y you need to do 120 times!
I hope i was more clear time
any news on flipbook using current sprite collision ? 
He just started working on it!! Whoooohooooo!
Cool to know ! From where did you know that?!
Search for an Unreal Engine video with Marsh and it will help you understand everything.
Trello board indicates that flipbook collision is in 4.7 in a “limited” fashion, so yay!
Edit: And thanks to for work!
He just marked task as completed on Paper 2D task roadmap.
Hey ,
I want to try out how flipbook collisions work but I am afraid they will slow down my game to a halt. How expensive are they in an actual game (with dozens of instances using them) and is huge performance cost something temporary?