In-House 2D Support with Unity 4.3

I don't if you guys heard about this, if not, here you go: http://www.gamasutra.com/view/news/199109/Unity_introduces_new_2D_tools.php

Especially the Box2D integration sounds really great!

 

I have already built 2D and GUI systems for my current game, but the native solutions shown for both look good. The 2D system was a surprise, and aims higher than I would have expected. Nice work.

 

Finally!

 

It was on the Unite 2013 stream. It looks awesome. Definitely makes all the 2D solutions in Asset Store look weak now, I hope this will force them to "up their game" in order to compete against Unity's native solution.

 

They will have to if they want to keep going. 2D has been a big hole for a long time and now it will be filled natively and many of the reasons for custom 2D solutions will be extinct. .. atlasing is automated, sprite animation, collider generation, 2d scene view etc... removes a lot of the need for a 2D tool... so they'll have to bring something new to the game.

 

Oh crap, I was resisting to upgrade to 4.x for so long ...

 

Me too , now I have to upgrade

 

So exciting! Long time coming and it's getting closer. Atlasing in particular! Good stuffs.
Gigi.

 

Very cool news. Can't wait to see this in action. I'm interested to see what the 2D tools are and if the mentioned dedicated 2D rendering system integrates with the rest as opposed to the traditional ortho camera method, e.g. integrating 3d elements or using it as a texture in a 3d scene etc.

I also wonder whether there's any optimization on the 2D rendering to give it gains over the traditional method, or if it's just the same and purely down to the tools. If there are gains then is it to be the basis for the future GUI?

 

Great. 2D should be built in.

 

@Per - all of those questions are answered in the Unite Keynote, which you can watch on YouTube now I believe. Seriously it was amazing.

Everything from optimization to atlasing! Wow and double wow!

 

This is extremely exciting stuff and I look forward to getting my hands on it

 

I love Unity!

 

I skimmed some visual parts of the live feed but didn't listen. .. from what it looked like atlasing etc is automatic although speed will probably be similar to how sprite tools are now... 2d physics will definitely be faster, and things are generally more integrated rather than shoved into custom inspectors. I doubt it has anything to do with the new GUI because that's 3D based although I'm sure they'll do atlasing for gui elements (didnt they do that already?)

I think there will still be some areas of opportunity for advanced features for 3rd party tools, particular with regard to animation (didn't see bone animation/vertex animation?), and tilemapping etc.

 

I am wondering if Unity has been spending all this time working on 2D stuff so that they could watch how the community came up with 3rd party solutions and be thus inspired. I mean, Unity's integration of 2D is much tigher and more `Unity-ish`... ie you can tell they've done some thinking of their own, but I think asset store tools often act as a test-bed for ideas and solutions which Unity then can base their integrations off of. e.g. their 2d solution addresses the same issues that 2dtoolkit, uni2d, spritemanager etc address... atlases, minimizing geometry, collider generation, etc.

 

Woot, this is fantastic news as far as I am concerned.

Believe me when I say we have created three large 2D games and the trouble we've had even with the best of plug-in libraries, this is an absolutely brilliant addition and much wanted. Funny thing is we just decided not to do another 2D game, maybe we'll change our mind when we see these new features in 4.3.

Great stuff!

 

Unity isn't intentionally waiting for 3rd party solutions to then "steal" from, but there is definitely a healthy ecosystem where some of the best programmers from the A$ community are being hired at Unity. Juha Kiili (RageSpline) is now at Unity working on the 2D framework and Michael Lyashenko (NGUI) is working on the new Unity GUI. Same goes for Tim Cooper (Strumpy Shader Editor) who will hopefully someday be given enough time to return to creating a built-in visual shader editor for Unity

And all of those "2d solutions" you mention are more or less fundamentals of making a good 2D framework for Unity so there is of course going to be a lot of feature overlap with existing A$ tools.

 

I'm a little pissed. I had been working on my own 2D solution that I was planning on using in several projects, and had gotten into an alpha phase. Now along comes this first-party solution that's going to be integrated into the base engine, and it looks to knock all the work I had been doing into a cocked hat. It's a little frustrating in that sense.

At the same time, I can't really complain. This sort of thing is EXACTLY what I wanted to use, and should accelerate a lot of the projects I had planned. I'll use my own solution for the time being, but I will be jumping on this thing with both feet when it comes out. Very much looking forward to getting my hands on these new 2D tools. I'm especially excited for the Box2D integration and automatic sprite atlas generation. Those are going to help out a lot for performance and time saving.

 

Very pleased to hear unity are doing the sensible thing and seeing what there is out there that there's demand for and bringing it "native". Autodesk do this EVERY year without fail. It not only is a good thing for customers in general, it's a good thing for unity as well. It's good for customers because we know it will be supported going into the future and will most likely be much faster.

In the case of sprite middleware being obsolete - far from it. The 2D Toolkit guy already has plans in place. I know full well he will move to adjust 2D toolkit to encompass these optimisations. 2D Toolkit has more than just sprites - we've got a robust tile map editor among other niceties. I don't see myself not using it anytime soon - especially it's clever shaped colliders per tile being mixed in the tilemap.

I expect him to integrate the Box2D style collision system and so on. This isn't the death of sprite middleware, it's the optimisation and evolution of sprite middleware.

Great news.

I'd love to see michael's work with TNet also eventually make its way into Unity as it does a lot of things considerably better than unity's own solution does... and some things nowhere near as good. A mix would be superb. Perhaps Unity should just buy TNet and become a little more serious about networking. TNet is a viable alternative to Photon at a fraction of the price.

I like the idea, the concept of a company hiring from it's brightest users and using it to create an even better product across the board.

I can't wait to see what unity are doing next. It's nice to know our investments are safe.

 

I second that.

 

If anyone has any questions about the new 2D stuff, I'll be happy to answer.

 

Does the integrated 2D make obsolete the current tools of the asset store?
I mean, IF i planned to buy 2dToolkit (for example) :
a) go for it, or
b) this is not necessary with the 4.3

 

a) Tile map support?

b) Multiple resolution asset workflow? For example, high resolution sprite for high end device, low resolution sprite for medium/low device. In 2DToolkit, this can be solved easily.

c) http://esotericsoftware.com/ integration ?

 

Congrats Keely on being able to work on the official 2D tools at Unity... awesome job to have.

I presume some kind of tilemap system will be coming in future, with better tools than just the usual `click tile place tile`? More automation/procedural painting would be good there.

Any sign of possible particle system optimizations that work in 2d only? After all, sprite and particles have lots in common.

Is there going to be an support for tilemap-based collisions ie collision detection not based on physics? like fake physics?

It'd be cool to have a mecanim-style retargetable control system for 2d games where you can like plug in a `mario controller` or a `zool controller` or whatever and have it work with your own animation stuff.... and what about the bone-based and vertex-animation stuff you can do in Smooth Moves etc?

Will there be any shaders designed/optimized for 2d?

Any kind of 2d lighting/shadow solutions? There are many optimizations that can be made there.

Maybe I can also mention a desire for a faster pipeline for uploading changes to textures... currently SetPixels() and Apply() is just not fast enough. The simple inclusion of being able to upload only a rectangular portion of a texture would help immensely... ie see glTexSubImage2d(). It's been supported in GL for over 10 years and would really improve streaming texture modifications instead of having to upload the entire texture (which currently forces having to have lots of small textures and thus lots of draw calls).

Any kind of per-pixel collision detection, non-polygon based?

 

Can we apply to join the beta?

 

Why'd you end up using Box2D over Chipmunk Physics? It looks like it was Chipmunk to begin with.

http://unity3d.com/ninjacamp/projects/10080

Cheers,
-Jon

 

Also on the topic of Chipmunk2d physics - can you please add the Chipmunk developers to the beta program for 4.3 so they can get a head start on integrating Chipmunk2d for Unity with the 4.3 2d stuff?

 

Will there be blending between 2d layers like in Photoshop?

 

I don't really want to comment on this for the hopefully obvious reasons. I think you need to just use the info you have and make a decision on your own.

 

Aras' *whistle* the other day was an evil whistle

In a Ninja Camp Unity had last year Aras and Juha did publicly mention that they were experimenting with Box2D IIRC.

PS - did you lose your Aarku forum account? Would you like me to try and get it back for you?

 

Not on the first release. We are thinking about it, though. Lot's of hard design problems involved.

We have a multiplier that allows you to tweak world-units-per-pixel ratio per asset. So for you SD sprite you would set this to say 1.0x and then for your HD asset 0.5x. This way both assets will appear as same world space size, but different resolution. It's up to you to choose which sprite asset to use so the workflow is unfortunately quite manual in the first release. You can use for example asset bundles to make it a bit more convenient.

We are thinking about solving this in a more automatic manner, but couldn't nail the workflow yet, so we had to leave it for later.

I think it's up to them to do integration. We are surely inspired by their great animation tools, though.

 

Any vector based features? Thanks for answering questions

 

Thanks

Not on the first version. We are thinking about it.

We haven't touched particle systems for the first release. Obvious thing to do first would be to make it support our sprite asset, but other than that I think Shuriken is really fast as is so I'd rather use resources on more immediate problems.

First we need a support for tilemaps, and only after that tilemap-based collisions so I'd rather not speculate that far.

I can see your point about retargetable 2d stuff, but I don't think it will happen anywhere in the near future.
Bone-based skeletal stuff we are researching heavily and it is pretty obvious direction to go, but I can't make any promises.

Right now we only have the default sprite shader.

Not right now. Of course you are free to write your own shaders on sprites so in theory anything is possible by users.

I assume you tried SetPixels32() too. Can't comment much about the openGL stuff. I'll try to get a comment from the gfx team.

Quite hard to incorporate into the Unity design, because it's not really pixel-based. I think we are not doing this.

 

We do not have vector features for 4.3. We are still undecided whether we should go this way or not.

 

Not out of the box. You can try to make something similar with your own shaders, though.

 

Sweet, I was hoping for something like this. For gaining pixel-style art, the important factor is the sprite's pixel density in relation to each other. As long as that is consistent things will look as they ought to look.

What about billboarding? Is there going to be a default solution for this, or will I need to roll my own? Not really a priority feature, but I am curious. Also, will it be possible to use the new 2D tools in conjunction with the default particle system?

 

If by billboarding you mean automatically camera facing meshes, then yes you need to roll your own.

We haven't touched Shuriken in any way and it can't currently take our sprite asset as input. Something that might be improved in the future.

You can still use Shuriken in your 2D games obviously. Just like you can put 3D meshes in your 2D game. Our 2D stuff still lives in a standard Unity 3D scene. We just made it more convenient to operate on from 2D point of view.

 

Yeah, I'm sure they looked into every reasonable looking solution. I'm just curious what the reasons were for the choice. I understand if they don't want to say them here. Also, I'm biased because I know the radawesome Chipmunk developers well and they're local.

-aarku ;-)

p.s. I changed it to just my name maybe in 2008? I don't know if that is good or not, at the time it seemed like a good idea. I just noticed my post count and super hipster ~March 2005 forum join date are gone now. Ah well.

 

Explain. While the guy working on 2D at Unity made RageSpline (awesome product no doubt), 2D Toolkit is far more popular than that plugin ever was. Why is everyone so sure that the built-in one will be any better than #1 most popular 3rd party 2D plugin? Better support possibly, since it's made by "THE company", but I don't know if it will be definitively better than 2d Toolkit. Of course people who haven't bought a 2D plugin yet will no longer NEED to buy one.

I'm not convinced until I try it. And for the record, I do not have 2D Toolkit. I am of course playing devil's advocate. Keely rocks. More choices is always good.

Of course the box 2D has me excited

 

Are there any updates to the font/text rendering system coming, to go with the big 2D and UI updates?

Both NGUI and 2D Toolkit provide their own font rendering solutions (using BMFont to generate textures and spacing data), and for some projects, this can provide more flexibility than Unity's font system - especially if you want 'arcadey' fonts (adding an outline/bevel/drop-shadow etc. in Photoshop).

Also, you get full control over the font textures and shaders - so you can mipmap the font texture, and apply a negative mip bias, for best results with scaled fonts (I wrote a blog post about this, here: http://inverseblue.com/?p=268) - something that I couldn't do with a standard TextMesh font (at least last time I tried, which was a while ago)

 

Let me help: YOU SHOULD!

 

+1 for Vector-Features.

Native Support for Adobe Illustrator Files would be awesome!

 

I was wondering if the packing algorithm for atlases has been improved? Maybe to support cropping/trimming and rotation?

Too many atlases in texture memory / too big ends up being a real problem in mobile development, and using a custom texture packer to allow rotation in atlas creation is a bit of a pain.

4.3 looks like it's going to be amazing - thanks for all the work!

 

I create most of my graphics in Illustrator, so I also agree it would be brilliant.

 

SetPixels() already supports updating a sub-rect of a texture (check the overloaded function), though whether internally this uses glTexSubImage2d (or DX equivalent) is unknown. I guess it could be determined by doing some simple tests and seeing what if any performance increase there is. However since setPixels is so slow anyway its probably not worth it.

However SetPixels32 does not have this overload, which is a really shame and somewhat mystifying.

Though overall I agree with ImaginaryHuman, the performance cost currently for updating textures on the fly via Unity is very high, even with SetPixels32 when compared to doing it yourself through opengl bindings. In addition there is a lack of consistency, i.e. the aforementioned lack of SetPixels32() overload, but also lack of being able to update 8bit or 16 bit textures and probably others.

It would be really nice to get a new suite of functions for dealing with this stuff that uses pure byte arrays instead of native Unity types (Color or Color32), since conversion from color clearly is a bottleneck and I get a feeling even color32 is not optimal. It might be that Unity is also updating and keeping a copy of the texture as image data, which would add to the performance issue, and is something that could probably be skipped (maybe as a bool option in any function) when that is not needed. These functions though maybe not as straightforward as the current Unity ones for developers make sense to me as if you are updating textures with high frequency or performance needs then you are probably a capable programmer who can understand how to use byte arrays.

 

Great news! Anyone else hope this is the first step towards a new GUI?

 

Any plans to add TexturePacker (http://www.codeandweb.com/texturepacker) import option to the sprite editor?

 

Actually the packing algorithm we use for our automatic packing for sprites (note: will be pro only) is much much better when compared to the Texture2D.PackTextures(). Unfortunately we don't yet expose this as a public API yet, but maybe somewhere in the future.

The difference is that while PackTextures() uses rects, we can now use complex shapes in our packing. This is because SpriteRenderer component actually doesn't render quads, but it renders a complex mesh that follows the contours of the alpha. For example if you had a circle shaped sprite, we render circle shaped mesh underneath. Main reason for this is to save fillrate, but it also means that while packing the sprites, we can actually pack the circle shape and not the quad shape.

The end result is that depending on the shapes of your sprites, you get a lot tighter packing. Sometimes you save almost half the space when compared to the old one.