Official First batch of 2D Features for Project Tiny 0.22 is now available

2D Foundational Features for Project Tiny 0.22

We are releasing the first batch of 2D features for Project Tiny!

Important Note: This release is targeted for Tiny 0.22 only. This means that trying to use 2D Entities with other versions of Tiny will not work at this time.

This is a foundational set of 2D features. As such it is focused on supporting basic rendering of sprites and collision detection in 2D.

Rendering

• Sprite conversion
  
• Sprite Renderer conversion
• Sprites/Default Material conversion
• Sprite Atlas conversion
• Runtime 2D rendering pipeline
• Editor 2D rendering pipeline

Physical Collision Detection

• Primitive colliders conversion
• Compound collider conversion
• Rigidbody2D conversion
• Physics broadphase
• Broadphase querying API

Playable Demos:

Play Tiny Gems


Play Tiny Spaceship

Getting Started:
Here's a preconfigured project to get you started quickly:
2D Entities Starter

Samples:
The source projects for the playable demos above are also available for you to explore. Find them here:
Project Tiny Samples

Documentation:
For more detailed instructions on how to use 2D entities see the package docs here:
2D Entities Package Docs

Please share your experience with the tools by replying to this post or creating a new one. How does this feature help you achieve your desired outcomes? What works as expected? And what doesn’t? We’re excited to hear back from you!

We will be curating answers to frequently asked questions in the discussion.

 

Known issues

• The aspect ratio is fixed at 16:9
  • Frustum culling is done in a 16:9 frustum
  • Projection matrix is locked at a 16:9 aspect ratio
• In the editor, the audio will not be played when triggered
• You have to keep the Main Camera SubScene open in Edit mode at all times to see anything being rendered in the GameView window
• There is a max string length to the build path
• Sharing assets between SubScenes is currently not supported
• Adding a dot (.) in the runtime assembly definition will cause the Run Build action to fail for android
• Adding spaces in the Build Settings filename will cause the build pipeline to fail building
• In the editor during Play Mode, the Scene View will not visualise the contents of a SubScene correctly, if the SubScene is in Edit Mode.
• You must decorate your converter with the

  ConverterVersion

  attribute. You should increment the version number every time you change the converter.
• The Profiler, Entity Debugger, Frame Debugger can be used within the Editor but cannot be connected to Project Tiny builds.
• Batching results will differ between editor and Project Tiny builds because they don't share the same render pipeline.

 

Common Questions

For general information regarding Project Tiny, see the Project Tiny documentation.

I drag-and-dropped a Sprite from Project to the Scene View and when I build the player the Sprite does not display.
A sprite must be inside a SubScene for it to be converted and displayed in a build. If you created the Sprite by dragging and dropping it from the Project view to the Scene, you will still need to move it into one of the SubScenes in your hierarchy.


I have a system that operates on a Rotation Component and I noticed that during Play Mode in the editor my Sprite doesn't rotate.
The GameObject that contains the transform component, must be inside a SubScene for it to be converted and operated on by a system.


During Play Mode in the editor, I noticed that if a SubScene is in Edit Mode, the Scene View doesn't visualise its contents correctly.
A SubScene needs to be closed during Play Mode to ensure its contents are displayed correctly. The one exception to this is the SubScene that contains the Main Camera. This SubScene should always be in Edit Mode, otherwise the Game View will not render anything.

I am seeing the following warning after compilation has finished

Assembly for Assembly Definition File '[asmdef filename] will not be compiled, because it has no scripts associated with it.

This warning is issued if Unity detects that an assembly does not contain any scripts. This is commonly seen in Tiny projects without any scripts.


I am seeing the following error when I build

Build [Build Settings Name] failed in BuildStepGenerateBeeFiles after [x]s.

Could not find a part of the path

This is most likely caused by the project being located on a too long path in disk. Try to shorten the path, i.e. C:/Projects/MyTinyProject/


I am seeing the following error when I build

Build [BuildSetting] failed in BuildStepRunBee after [x]s.

...

[Project]/Library/PackageCache/com.unity.dots.runtime@0.22.0-preview.3/bee~/BuildProgramSources/BuildProgram.bee.cs:448: error: Program ../../Builds/[BuildSettings]/[ProjectAssembly].dll is an executable-like thing, but doesn't reference anything with Main (System.InvalidProgramException)

The build system cannot find the Tiny assemblies. Make sure that Use GUID is deselected in your runtime .asmdef, and try again.


I am seeing the following error when I build

Build [BuildSetting] failed in BuildStepRunBee after [x]s.

tundra: error: unable to map [BuildSetting] to any named node or input/output file

stevedore: warning: unrecognized config setting: retries

Make sure your root assembly definitions (Root Assembly) name in the name field matches the file name.


I am seeing the following error when building on MacOS

Build <NameOfBuild> failed in BuildStepRunBee after X.XXs.

[E] DAG generator driver failed: mono --debug ...

error: Object reference not set to an instance of an object (System.NullReferenceException)

  at Bee.Toolchain.IOS.IOSToolchain..ctor

  at Bee.Toolchain.IOS.IOSAppToolchain..ctor

…

Before creating an iOS build for the first time, follow these steps to make sure everything is setup correctly.

1. Open the terminal
2. Enter xcode-select -p
3. Ensure /Applications/Xcode.app/Contents/Developer is printed
4. If it is not, enter sudo xcode-select -r
5. Enter xcode-select -p to ensure that you now get the expected output

I set the background color of the camera, but in the build the background is black
Make sure to set the background colors alpha to 1


My authoring/conversion scripts does not convert the data exactly how I written it in the authoring script
The converted result is cached to speed up the development process. To update the conversion cache, make sure to add a ConverterVersion- attribute above your conversion class, and increment the version for every change you make.

 

Are you creating a project from scratch or did you use the Starter Kit?

 

thanks for the feedback. We'll make sure it gets updated...

 

That requirement will also be lifted in tiny 0.23, fwiw.

 

The current plan is to have 2D Entities depend on Project Tiny. Do you have any use case in mind where 2D Entities have a different dependency structure?

 

Right now our focus is to continue develop our 2d pipeline on top of dots runtime/project tiny.
We have had internal discussions on whether or not we should add support for "hybrid" dots, but right now it is not a very high priority.

If we hear more users telling us there is a big need for this due to certain use cases, we will for sure re-evaluate the priority for this.

 

FWIW, while it does depend on tiny and that's what we're focusing on, we are not particularly intending to put up any roadblocks for building with hybrid. We need it to work in hybrid anyway for the time being in order for play mode to work. And indeed, hybrid does have many features tiny lacks today, like UI.

But on the other hand, we do believe dots runtime as a framework can scale in every dimension very well, and in the long term we believe it will actually scale better than hybrid. I'd hope that we can even make a UI situation that you would prefer to the current hybrid one, but we'll leave that for you to judge when we ship it.

 

Thank you for the heads up. Right now we do not have support for mixed 2d and 3d rendering. This is something we will look into in the future.

 

Even though the 2d rendering part and the 2d physics part is in the same package, your tiny builds only need to include the assemblies you need. If you do not require any 2d rendering features, you can remove those assemblies from your build asmdef. You are correct in that 2D Physics does not depend on 2D Rendering, so that is a totally viable thing to do.

 

Sounds like the "Known Issues" post above:

 

@pavank_unity Right now we recommend just modifying our provided samples rather than creating a new project, as there are too many pitfalls in creating a new project. We are working on fixing that.

If modifying samples can't work for you, could you paste the error you find when you try to run?

 

@pavank_unity @ajaykumarkaranam188 there are a few pitfalls, like @elliotc-unity stated. Have a look at the Getting Started section in the 2D Package documentation, maybe there is a step or two that was overlooked.

https://docs.unity3d.com/Packages/com.unity.2d.entities@0.22/manual/2D-rendering.html

Keep us posted on your progress.

 

Do you have the tiny-required toolchains to compile for mac and/or windows? Windows requires VS C++ and .NET desktop workload, and Mac requires Xcode command line tools IIRC.

(We obviously need to make that error message better.)

 

No but you can do that with your own "ICollector" on the output side. The downside there being that this is done after the narrowphase so is far less efficient.

I was considering this ability so we can filter at the broadphase level. We could certainly extend the IgnoreHit API to include an optional NativeList of bodies for instance. By far the fastest way though is obviously via a CollisionFilter.

If you have any suggestions on how you'd like to present that list of bodies to ignore then, I'm happy to listen. It would seem improving the IgnoreHit to simply allow this might be the easiest approach.

 

What do you mean by "working fine" and do you mean the DOTS physics or classic physics?

As the release states, there's no contacts reported or solved in this release so you won't get collision response.

 

Hello @ktorz ,
Currently Unity NetCode does not support Project Tiny.

 

@ajaykumarkaranam188 right now project tiny does not have any UI implementation.
To give you an idea of what is currently supported, have a look at the demos we have shipped.
TinyGems
TinySpaceship
TinyRacing

The projects to all of these demos can be found in the ProjectTinySamples - repository.

 

Yes, you already described that and I fully understand so I can only reiterate what I said which is that there's no collision response. Collision response is what stops colliders from being overlapped. Sounds like by "physics" you are referring to this.

Hope that helps.

 

Hi,
We are working on UI, we know it's a super important feature. Timing for when we can share details is still uncertain. Overall we will continue to provide updates as much as possible when we publish a new preview. We understand it's frustrating not knowing, however we want to be careful and only share when timelines are super solid, so you can plan accordingly.
Keep sharing feedback on features you need the most. Also keep in mind what was shared last September at Unite Copenhagen 2019 during roadmap of Project Tiny (session recording and quick summary), the high level goals are the same.
JC

 

Hey @Shredder25 ,
Thank you for your feedback!

We have discovered an issue where GenerateAuthoringComponent would crash the editor in certain situations. In the next version, we have fixed this issue.
If you only use IConvertGameObjectToEntity, does the crashing issue go away?

If you close your subscene, is the jerky-ness still there in editor playmode?

Are you referring to the SortLayer component which is attached to the same Entity which has the SpriteRenderer component?

In the editor, we are rendering using different data sources depending on the view (Scene View & Game View) and whether or not the subscene is open (Edit mode) or closed.
- If the subscene is open (Edit mode), the Game View will render with data converted over into the ECS world. The Scene View will render with data from the actual Game Objects.
- If the subscene is closed, both the Scene View and Game View will render with data converted over into the ECS world.
This is not an ideal setup, and we are looking into ways we can improve this workflow.

Could you share some code on how you implemented this?

What error are you seeing? and when does it throw this error?

Thanks again for your feedback, this is really helpful for us!

 

CastCollider can use a collider you explicitly create (that won't be in the broadphase) but if you're referencing an existing collider that is in the broadphase (world) then it has no way to know you want to ignore the body it's attached to. But, as you say, if you're sure your CollisionFilter for that collider is set so it doesn't intersect with the layer its on then it won't or shouldn't detect it so I'm not sure what's going on there. Note that all queries provide an IgnoreHit but I'm not sure how you're referring to the collider but if you know the body index it's attached to you can use this to explicitly tell it to ignore it.

 

Any "jerky" motion would be caused by the update rate of the component systems. Are you sure this is limited to physics though? I find that "Menu > Jobs > Leak Detection" set to anything other than "Off" causes this because of its overhead. Also, it takes a little while for Burst to do its job so you'll initially get jerky/stuttering when hitting play too. None of this exists in a build.

EDIT: Feel free to DM me or create another thread and send me the link if you want to work out physics issues. It's better than doing everything here. Happy to help.