As you may have noticed, there was an unsupported experimental plugin named Paper2D already present in the 4.0 launch.
I’m very happy to announce that we’re going to be taking it from experimental to a supported engine feature over time. The goal of Paper2D is first-class support for making 2D and hybrid 2D/3D games in UE4.
Anyone who is interested will be able to follow along with the live Perforce->GitHub mirroring, and you can see the current Paper2D Trello Board here (tasks / roadmap / etc…).
As a disclaimer, anything listed on the roadmap may not actually make it into the engine as planned today; we may run into complications that push out a feature, or we may have reason to stop working on it altogether. Items in our backlog may never see the light of day either, as they are simply ideas we’ve discussed but haven’t yet figured out if or how they would best fit into the engine. While we intend for most items on the roadmap to end up surfacing as estimated, we want to make it clear that there is no guarantee of a feature being added to the engine even if it’s currently listed.
There is a quick start guide / initial docs thread on the forum which covers more about what is considered fully supported, available as early access, or totally experimental as of the 4.3 release.
Note: These updates will pertain to the main branch on GitHub unless otherwise stated.
[Weekly 2D Status 6/30/2014]
Everything listed here will be in 4.3, but later updates will be about future releases as we have branched for 4.3 today. I’ve also taken a pass at updating the 2D Trello roadmap to reflect completed work and changed priorities.
Enabled Paper2D plugin by default in the engine, so it will be usable in content-only games in 4.3
Editor and documentation work to properly message the state of Paper2D in 4.3
Overall Paper2D in 4.3 is an Early access preview - While not considered production-ready, it is a step beyond ‘experimental’ and is being provided as a preview of things to come
Created placeholder editor intro tutorials, etc…
Sprites and Flipbooks are Early access
2D collision/physics, terrain splines, atlasing groups, and tile maps are Experimental (hidden behind enable flags where possible)
Created 2D side scroller game template (BP and C++ variations)
Productization / usability polish pass
Added pixels per unreal unit scaling factor to sprites, with a per-project default setting
It may be applicable for some uses, but UMG is our proposed solution for editor-centric UI and HUD stuff. We’ll be collaborating to share code wherever it makes sense (e.g., text formatting and layout, possibly atlas generation code, etc…), and will probably support things like drawing paper sprites on a UCanvas / AHUD, as well as drawing them as widgets in UMG.
@hbrock and @xgalaxy, now that the public overall roadmap is up, I’ll try to get the trello board for Paper2D up.
There are a number of serial dependencies I need to work thru first before others can just jump in without the ground shifting out from underneath them. After that, it will be much easier to grab work from the ‘nice to have list’ or improve what is there, especially adding features to the sprite editor, etc…
I’m currently focused on the core bits that are necessary to even consider using Paper2D in a game (namely efficient rendering support with automatic atlas generation and batching).
@ssfulfe, 2d textured splines is already on my radar, though I haven’t seen Ferr2DTerrain before, which seems to go a bit beyond it (slope detection changing the border texture / etc…). I’d love to have features like that, but fundamentals come first I think UbiArt does a similar system for their platforms and terrain as well.
Thanks for moving paper 2d to a supported feature. I tried using the plugin yesterday. I could successfully create the sprites and placed a few in the viewport after doing so. The major pain is the placement as it is 3d viewport placing 2d assets is tough maybe only for me. A 2d viewport would help for easier alignment of 2d assets.
As a disclaimer, anything listed in the current version may not actually make it into the engine as planned today; we may run into complications that push out a feature, or we may have reason to stop working on it altogether. Items in our backlog may never see the light of day either, as they are simply ideas we’ve discussed but haven’t yet figured out if or how they would best fit into the engine. While we intend for most items on the roadmap to end up surfacing as estimated, we want to make it clear that there is no guarantee of a feature being added to the engine even if it’s currently listed.
Why dont you assemble a team from forum members who are interested in 2D features you can mentor us in the right direction so we can help in the development of 2D features. So we can get Paper 2D features faster :). By the way if you consider doing it i am in.
I’m excited about the development of Paper2D in UE 4 and wanted to offer a feature idea, that may not have been considered already. I believe it would be really useful to be able to import SVG assets from Illustrator or other vector drawing apps into UE4 and then dynamically rasterized into a sprite context when needed. In other words, the SVG file remains an asset in a UE4 project, and only rasterized once when it is used on screen, or updated when a sprite is scaled to a larger size on screen or when multiple resolutions of the sprite are required. From my understanding, sprites are usually more performant in games, but vector graphics can take up far less storage space especially when high or multi resolution images are required, not to mention the creation of sprite sheets/atlases. And of course, sometimes the style of your assets require a more clean vector graphics look anyways. Seems like a waste to have to rasterize vector graphics into PNG files beforehand just to get that look.
I believe this Vector/Sprite hybrid concept would make a lot of sense for Paper2d in UE4. The key however, is that you’re not trying to rasterize vectors into sprites all the time, only when an update is needed. I’m interested to know if there are reasons why you think this would be a bad idea or perhaps just a useless one!!
Using vector art can be quite nice for sharp images at any resolution, but there are certainly some potential downsides to rasterizing it into a cache. For example, imagine that you have multiple instances of the same object, each independently zooming in and out (e.g., a bunch of buttons that can all play their own bounce animation when clicked, or spawning characters or whatever). If you place every unique scale (and possibly rotation) instance in the cache, you can quickly run out of memory and crash if the cache can grow unbounded, or thrash the cache + force a rendering flush if the cache has a maximum size.
Slate actually handles something like this with a runtime atlas for font characters, rasterizing characters as needed at each scale size used in a frame. This works pretty well in practice, though quickly zooming in and out in a Blueprint can pollute the cache temporarily.
I agree that it would be quite useful, even if it just rasterizes to the maximum size on load, reducing your download size. I’ll add it to the roadmap as a wishlist item.
On that note, has anyone worked with SVG before? I had a quick look around for svg libraries and didn’t see much with a suitable license, seems like most things use LGPL. This looks interesting GitHub - memononen/nanosvg: Simple stupid SVG parser but it’s not clear how compatible it is (SVG is a pretty complex format and I get antsy whenever someone rolls their own XML parser).