Thanks for the reply, I’ll make sure to keep watching this space for updates. Really hoping for something Sprite lamp-esque that supports self-shadowing. Any word on raycasting platforming / 90’s Lucasarts-esque fake z-depth?
Amazing! Keep up the awesome work!
This is great stuff! I’m excited for what’s to come.
I want to express my support for your project, though I will also admit that it sucks there’s so little development on Paper2D that it has come to this to make it happen. My team is currently working in Paper2D and there are so many brick wall limitations in it right now.
The highest priorities for me would be:
Support for other collision shapes besides capsule (this is a big one)
Layer locking
More flipbook animation control
2D collision and physics
Best of luck with it, I hope you’re able to make the improvements we’d all like to see.
First update looks good!
Hi all, thanks for your encouragement and feature suggestions. I am noting them all down, so keep them coming! Time for a quick progress update 
My focus at the moment is to make a VERY rough and ready prototype of the core feature set the plugin needs to be usable. This is so I can discover any blocking issues early before I come back and reimplement everything properly. I have made a basic asset pipeline for setting up sprites and rendering them through the batched renderer. This also includes auto creating dynamic materials inside the renderer dependent on what the sprites need.
Doing this has highlighted some issues that are a little problematic:
-
I cannot see a way to implement priority layer rendering that will override depth sorting into scene. This means all render sorting must be done via camera depth, which is not ideal. I can still implement layer helpers that will control visibility, selection and auto depth placement, but it will not be as flexible as having a true render order ability.
-
Editor selection on batched geometry is also proving problematic. The only way I have managed to solve this atm is to not batch anything while in the editor viewport. This allows things to be selected individually in editor and then batch as normal in game view. The downside to this is performance in editor and selecting things when testing the game will not work correctly. There may be a better solution to this that I’m still investigating.
Next I want to dig into how the layer system will work as this is potential blocker to the plugin being developed if a usable solution cannot be found.
I am loving the rapid progress on this 
Great work! Thanks for the update. I think the layer helpers would be sufficient if there is no better solution, as long as the workflow is intuitive, and you can keep two objects from inter-shuffling their child actors
I’ll throw two more in for the wishlist:
1 - I’d love to see some kind of improved Matinee (Sequencer?) support for 2D types, being able to control flipbooks or change 2D specific properties on the timeline would be fantastic.
2 - If there was some way to author root-motion for 2D animations, that would be excellent. I’ve always wanted to have my 2D animations have pixel-perfect movement without having to teleport the root. (ie. climbing up a ledge, and have the player root actually move each frame with the animation, and ending up at the top of ledge). Not sure how feasible that would be to implement, but I’m throwing it out there.
Haha thanks! It feels like that atm because I am just writing prototype code to explore how everything can fit together. It will probably take a few months to come back and write this all to a production standard with everything hooked up to Blueprint and all the editors / thumbnail previews / versioning etc working. But we’ll see
Some good news about layering in my next post!
I’m not that experienced with Sequencer’s code implementation atm, so I cant say if that is possible or not, but it sounds like something I should support if it is.
Interesting, are you talking about frame by frame sprite animation here or 2d skeletal?
Hi all! Some good news about layering
I’ve been experimenting with different solutions to implement layering support and I’ve discovered that because all Scissor Components are drawn through a single renderer actor, I actually have explicit control over draw order to do whatever layering solution I like! Here I have setup a prototype with SortingLayer and OrderInLayer variables. You can see as I change them the draw order updates accordingly even though they are all drawn at the same depth value.
In fact SortingLayer will override scene depth, so it is possible to have something that is physically behind something else, draw on top of it. SortingLayer & OrderInLayer are what another popular engine uses for their sprite sorting, but I’m open to suggestions if anyone has any ideas for a better system.
As always, there are some tradeoffs to this implementation. For this to work all Scissor Components must only use translucent materials as opaque materials are drawn in a separate render pass that can only be correctly scene combined via scene depth. At first I thought this was a deal breaker, but then I noticed that Unity also only supplies translucent materials for their sprite implementation. If you change a Unity sprite to use an Opaque shader it will indeed break render order and their sorting no longer works.
A more significant downside is because the ScissorRendererActor that actually does all the render calls to the underlying engine is always at the root of the world, this messes up layer sorting with other non Scissor things that need drawing (such as meshes or particles). I’m looking into a way to get the renderer to spawn a new component (that can have a real depth) for each sorting layer that may alleviate some of this, but I’m not sure yet.
Next I want to take a quick look at how 2d physics can work. I feel like it will need to be a separate implementation to the current physics interface, so I want to try and work out the implications of that.
Excellent! That looks very promising, great work. I would add that Unity has recently added a Sorting Group functionality, which allows one object’s entire hierarchy to pass over/under another, even if they share sorting layers and orders that would otherwise shuffle their parts together. See here for more detailed explanation with pictures: https://docs.unity3d.com/Manual/SortingGroup.html
For my use case, it was frame by frame. I had a sprite sheet animation of a dude climbing up a ledge and I needed an elegant and seamless way to transition the player character up the ledge with the animation. I don’t remember exactly what I tried, but I wasn’t able to get a good solution for all my 2D cinematic needs so I switched to Unity which allowed me to create a frame by frame animation with associated transform changes per frame. The root motion in Unity was still not working as intended, but I was able to get something I could work with.
Awesome!
Here is another motivational bump!
Keep up the great work! looking forward to the results.
Ah, I see what you mean now. Yes I’ve hit this issue in the past and I’m not sure there is a perfect solution. Root motion is something I’d like to consider for skeletal animation, so let me have a think about what we can also do for frame by frame stuff.
Hi everyone, I was a little ill last week so I only had a couple of days to work on the plugin.
I have spent that time investigating possible options to fully integrate Box2D for ‘real’ 2D physics support. I can see in the engine source that Paper2D made some headway on this, but has also hit a few issues due to the differences between how box2d works and what is required for the Unreal physics interface. Reading around the forums a little has highlighted that box2d will also need some extension work itself to fully fill out the Unreal physics interface requirements and that I would need to do all this via pull requests to continue that integration further.
This lead to me making a quick prototype to see if we could just have Box2D running as a completely separate 2D physics world, with its own set of custom components. This way I can fully expose everything box2d has to offer without having to shoehorn it into the current Unreal physics interface.
Here I have setup some Actors that each have a ScissorSprite, ScissorPhysicsBody and ScissorPhysicsPolygon components. Like the renderer side, you have to add a ScissorPhysicsWorld to your level that the components can register and set themselves up with.
As a quick test this approach does seem like a promising direction, but the downside will be any other system outside of Scissor land will not have access to the physics as it expects. This means that things like the character controller etc will not work out of the box. But it is my intention to include a more platformer orientated controller that can take advantage of everything Scissor2D has to offer anyway, so it may be fine.
I have one final area I want to explore before I start to go back and work on everything property and that is what we can do to make the viewport better for 2D work. Ideally I would like a real 2D mode that can support perspective cameras properly while having a good interface to move the world around and edit things in view.
Investigations ahoy!
Nice! great job 
Good luck.
Thanks for explaining your process and considerations. It’s very interesting, and I hope to learn from your implementations if/when source code becomes available. I’m very good at Unity C#, and I’m trying to learn Unreal C++ which seems to be taking more time to really click for me than Unity did.
Anyways thanks for the update, and great work!
Man, I will only say the following.
If you start selling this solution and already works better than paper2d on the span of June to July. I would buy it immediately. I have a budget for critical tools on our company and this fits the definition pretty well.
So , you have my support, and if you start selling it please send me an IM asap.
Good luck
Must… have… another… update…
Hi everyone! thanks for your patience.
I’ve been digging into what I can do to customize the editor for 2D work via plugins. There isn’t a huge amount of documentation for this kinda thing other than looking into the engine source to see how other things have been implemented, so everything has been a little slow going.
But my investigations have proved fruitful, here I have made a little prototype of a possible “2D Mode” for the perspective camera, that takes over the scene view perspective controls and fixes the rotation down the Y axis and also gives drag scene controls like the orthographic view.
There is a lot I can do with different editor modes, and it will be my intention to make a Tilmap & 2D Landscape modes that can be accessed similarly to the current 3D Landscape mode. Each of these will have a set of tools that lets you edit the scene directly in the scene view instead of a separate asset viewer as Paper2D does now.
This work brings my initial prototyping to an end, the next step is to make a more detailed production plan for all the features I want to cover and then we should be able to get a better view on a future release schedule. As always if you have any requests or ideas you’d like to see, please do let me know