A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Project Tiny' started by HonorableDaniel, Dec 26, 2019.
Does Project Tiny support VR? If not, is it on the roadmap?
Currently, Project Tiny does not support VR. Right now we have 2D and Unity.Physics support planned for release in January. In Q1 2020 we will layout a more precise roadmap on what is coming to Project Tiny in the future.
Hi Ted, I just got Unity.Physics to run within Tiny Runtime, wanted to know if i'm probably missing something since I didn't get to test it fully (just a physics ball falling on a plane, with some restitution).
All I had to do was change the TinyExportDriver class and add another BlobAssetStore argument to the constructor, and populate the BlobAssetStore member of the parent GameObjectConversionSettings, so the collision conversion could add the collision data to the build. Seems to work in standalone windows and in wasm builds.
Is there other stuff that needs to be done to get Unity.Physics functional in Tiny, or is this all that is needed? I was afraid maybe i'll discover later that it's still not fully functional, and more work would need to get done, finding myself in a rabbit hole.
firstname.lastname@example.org\Unity.Entities.Runtime.Build\TinyExportDriver.cs line 27
public TinyExportDriver(BuildContext context, DirectoryInfo exportDataRoot, BlobAssetStore blobStore)
BlobAssetStore = blobStore;
BuildSettings = BuildContextInternals.GetBuildSettings(context);
m_ExportDataRoot = exportDataRoot;
Of course I had to make the BlobAssetStore member public in the com.unity.entitites package / GameOBjectConversionSettings class, but since that class also has virtual members, I'd argue BlobAssetStore should be modifyable from derived classes anyway, since it seems the base class is intended for extension.
We almost shipped with Unity.Physics support in Tiny Racing, but cut it because fixed timestep support didn't make it into this release. Without that, things can get very unstable if you ever have a hitch. So, you can either implement fixed timestep updating yourself, or wait for the next release.
Interesting. I saw the fixedFrameRateEnabled public member in TinyEnvironment.cs, would I have to set that to true, and if so, how? Accessing the TinyEnvironment system directly from one of my systems and then setting it, or some other way?
It didn't seem to be referenced from anywhere else in the code.
Later edit: Seems to work. It's framerate-dependent, with just this change, of course, but just doing this avoids instability in physics I suppose. Now if only I could figure out how to step the physics manually.
Would alternating the fixedFrameDeltaTime between 0 and 1/60 depending on how far behind physics time is from realtime be correct?
I know there was a solution a while ago to update the physics groups from within the FixedUpdate of a MonoBehaviour, but that's not an option in Tiny
We're working on a solution that will allow physics (and other systems) to run with a fixed update, while allowing rendering etc to run at variable update for DOTS in general. We didn't have time to get this in place before this first release, so didn't showcase Unity.Physics with the TinyRacing demo, but in general things "work". Look out for the new functionality in the near future (a few weeks).
Thanks, that's great news!
Is 2D also include UI?
UI will not be included in the January release, but will be in introduced in a future version.