2020 Roadmap Q&A - Core Engine & Creator Tools

[mfuad]

@foshe_5

Are we going to get on editor playtesting for AR foundation without building for mobile devices?

I’ll provide a deeper view into our work on AR remoting, and hopefully address your question in doing so. AR remoting is currently in development; the first version will include the ability to test baseline AR features (camera, input, raycast, planes) on handheld AR (ARCore, ARKit) devices, without having to build the app. We we will soon be conducting user studies to gather feedback on early versions of the feature. As it continues to mature, we’ll aim to have a pre-release version publicly available for wider feedback thereafter. In terms of testing in the editor without using a device at all, we don’t have concrete plans to share at this time. We’ll share here as soon as we have an update.

[Schubkraft]

@Kolyasisan

Do you have any plans on upgrading Unity’s Runtime (editor and player) to a newer one (.NET Core for example)?

Our current mono is circa late-2017/early-2018. We are working on updating the fork to recent master. At this point, it’s likely to be available during the 2021 release cycle. The work is underway, but it likely won’t be ready for 2020 releases.

[TheOtherMonarch]

I heard on the forums that Dots, ECS, Unity.Mathematics and Dots physics currently supports deterministic floating-point calculations on the same architecture.

Can you say a little more about determinism in unity? What are the plans for the sum checking of scenes? Sum checking would make detecting out of sync errors easier in multiplayer deterministic networking or any other critical cases which require verification.

Answer:

@""

Hello,

Yes, Joachim Ante recently clarified the current state of determinism in DOTS. I would recommend following up there for a more in depth discussion.

We do take deterministic behaviour seriously in DOTS and want our users to be able to make informed choices about when something is or isn’t deterministic. We still have some way to go, but we are continuing our efforts to deliver deterministic floating point calculations across different architectures.

In regards to checksum comparison in order to prevent sync errors, that is something that can be done today, and something we will likely offer in the future as part of the Core DOTS package.

[Uli_Okm]

Hello! Great presentation
Just to know, there any ETA for Tiny + UI Elements Subset?
Thanks

Answer:

@""

Hi and thanks for the feedback!

We’re currently looking at a Q4 release.

[Bivens32]

For the new environment system, have you guys thought of making a “TerrainGraph” akin to ShaderGraph or VFXGraph? I’ve done some experiments with the Job System and manipulating noise and terrain heights with a graph and it seems to work really fast. I’m just imagining that it would be cool to embed a graph inside of a terrain layer. Then you could apply that terrain graph or stack of layers to a terrain at runtime. You could also just make it easy to apply a shader from ShaderGraph to a layer in the terrain. Maybe you could have a special output node for that.

Answer:

@quixotic

Thank you for the suggestion! Our goal is to make artist-friendly, performant systems that scale well - we’ll go into specifics when we’re closer to release. Right now our focus is on nailing our MVP and getting out a good initial experience.

[ans_unity]

@willgoldstone

You’re referring to Prefab Handles, basically we’re making it possible to specify your own prefabs as handles / manipulators so you can easily package up exactly the right geometry and more for your tools. As for the API I’m not sure but @ans_unity may know more.

@MechaWolf99

In the World-building section you talk about foundation APIs, are you able to tell us a bit more about them? What are they, what will/can they be used for?

You also talk about being able to create your own manipulators using the APIs(?). The demonstration video is small, and hard to read the text. What are they exactly? Are they custom shaped gizmos/handles that are made using GameObjects? Sounds like you can have them even play sounds and things from within the editor?

Hi MechaWolf99,

We are working on several APIs; we want the Scene Tools to be generic concepts that are used as frameworks both internally and externally. We propose solutions out of the box but let you extend it to your liking.

In that specific case we are talking about the Prefab Handles that let you create handles through gameobjects and provides a framework that works in any context. You basically create your own prefab that can be used to replace/create gizmos, handles and manipulators.

Hope this helps!

[willgoldstone]

@Onigiri

Long time ago there were plans for new better roadmap page/site with up to date info. Is this in development or dropped?

It’s still planned - something we need to get on with - we know! Sorry for the delay on this front!

[quixotic]

@Kronnect

Thanks for the presentation.
Once deferred rendering is added to URP, are you planning to add surface shader-like syntax in the future to make it easier to build multi-rendering path shaders using code?

If for “multi-rendering path shaders” you want something like LODs within your shaders you can use keyword switches to build out different variants for your Shader Graphs (see documentation: https://docs.unity3d.com/Packages/com.unity.shadergraph@8.0/manual/Keywords.html).

If you’re looking for supporting multiple render pipelines within your Shader Graph we’re doing work there, and this will also it easier to get more specific about stages (see a UX mock up and more info https://portal.productboard.com/8ufdwj59ehtmsvxenjumxo82/c/52-master-stack-and-stage-blocks).

Currently we are not working on surface shaders and the shader team’s focus is on building the best possible shader graph and artists tools possible. Our goal is for you to be able to do what you could do with surface shaders with Shader Graph (supporting both node and code paths). That being said we are actively engaging with a users who see a big desire for surface shaders on the forums here: https://discussions.unity.com/t/781021 We would value any contribution.

[ans_unity]

@chrisk

A quick question, the Roadmap said Kinematica is in Preview but I don’t find it anywhere.

Hi chrisk,

Kinematica preview package is ready and will be released by the end of April. I’m happy that you’re looking for it, it’s going to be awesome!

Cheers!

[JoNax97]

Hi! First of all I wanted to thank everyone involved in this roadmap session, the QA and the recent “state of unity” forum post. This kind of communication is really appreciated.

In the XR slide you mention “On-device remoting for handheld AR”, I’m not sure what it means. Could you clarify a bit?

Answer:

@mfuad

I’ll provide a deeper view into our work on AR remoting, and hopefully address your question in doing so. AR remoting is currently in development; the first version will include the ability to test baseline AR features (camera, input, raycast, planes) on handheld AR (ARCore, ARKit) devices, without having to build the app. We we will soon be conducting user studies to gather feedback on early versions of the feature. As it continues to mature, we’ll aim to have a pre-release version publicly available for wider feedback thereafter. In terms of testing in the editor without using a device at all, we don’t have concrete plans to share at this time. We’ll share here as soon as we have an update.

[MartinGram]

@Jawsarn

Working with DOTS tech of Physics, NetCode etc with debugging tools such as full stack traces and non burst code causes the editor to be very slow (around 10 fps), while built version runs very well. Are there any plans of improving the editor experience when using DOTS tech?

Hi Jawsarn,

Thanks for the feedback. This is something we are aware of and want to improve however we can.

Not directly related but we are working on improving the general visibility of what DOTS is doing while in the editor (What was previously constrained to the entity debugger). Also we have added Native debugging of Burst in the 1.3 release.

[Shizola]

I’m interested in RTXGI from Nvidia RTX Global Illumination (RTXGI) | NVIDIA Developer

Do you have any information about how / when Unity will implement this? Thanks.

Answer:

@quixotic

Thanks for your feedback, we have nothing new on this today. You can check out the talk we did a while ago while working on a prototype for the technique:
https://www.youtube.com/watch?v=F3hIculYFwM

And we do hope you’ll check out our current implementation of ray tracing we recently did a blog post on it you can check out: https://blogs.unity3d.com/2020/03/06/high-definition-render-pipeline-real-time-ray-tracing-is-now-in-preview/

[quixotic]

@Onigiri

Hi! Thank you for roadmap. Is it possible to use new environment system with custom meshes or it’s working only with terrain? If i wanna paint textures or place grass on meshes will it work?

We want to enable this in our new non-destructive environment, and we’re discussing how this can be integrated. We will share more once the plans firm up.

[mfuad]

@Johnny-Fuzz1

XR Foundation and Direct Support with external tools like MRTK.

I know the Microsoft MRTK plugin very well and in my opinion is one of the best XR toolkits out there - also given the recent work to open that up even more from the community - what my question is more so about is the roadmap and support for integrating these tools within Unity’s XR Foundation service. Microsoft has a package manager plug-in for MRTK and I know going forward this will probably be more on Microsoft than Unity - just wanted to see what additional information could be provided in these circumstances.

Thanks,

We don’t have any plans for direct integration of MRTK, but it’s worth noting that Microsoft has released a new version of MRTK (2.3) that includes support for XR SDK, which is our plugin framework that AR Foundation is built on top of. So current guidance is to use Unity’s Windows XR Plugin and Microsoft’s MRTK 2.3.

[MartinGram]

@andreicfsteaua

Regarding creation workflows, atm there is no full DOTS scene control during playmode like the traditional hierarchy for OOP. For example, if I instantiate a prefab at runtime, I cannot modify it using the editor during playmode for testing. Are you developing such a functionality?

Hello,

We are currently looking into how we can improve the user experience of working with DOTS in the editor in general. One area in particular is how to view what is in a scene more clearly.

There will be updates throughout the year on those efforts in the DOTS subforum.

[valarnur]

I wonder about foliage and grass support for HDRP terrain in 19.3. Could you improve these tools.

Answer:

@quixotic

We have started developing a new non-destructive layer-based environment system for terrain and other environment elements, we’ll follow up with more detail once we have plans to share, including SpeedTree support. In the meantime, current terrain system is in maintenance mode - we’re evaluating support for features like SpeedTree and will share the plans once we have them firmed up.

[Laex410]

Thanks for the overview.

Quick question: Why are you guys focusing on enabling tens of thousands of cameras by moving the system to dots? Is that really something you guys should focus on? Last time I checked no game needed anything close to that amount of cameras. Is that really a feature anyone asked for?

This is just one example of a roadmap feature that is just weird.The priorities mostly just seem wrong.

Overall almost the whole roadmap just feels kinda off. Some improvements like the new importer, the profiler features and the quality of life improvements in the editor are really nice (should have been improved years ago but better late than never, and the improvements are really really good thus far, great job by the teams) but quite a lot of improvements seem unnecessary, especially when looking at the massive issues Unity has.

URP not having a deferred renderer after almost 2 years is pretty rough, HDRP seems to only work well for artists (no shader documentation / the whole documentation seems to be geared towards artists instead of programmers, the fixed render queue with only limited injection points limits expandability, no realtime GI solution throughout 2020, …), why are there multiple physics solutions but both are in preview, why isn’t there proper build support for more platforms when using cloud builds, why is this the third networking solution in like 5 years, why is there a focus on machine learning but there aren’t even proper AI tools in Unity (Why isn’t there any form of behaviour tree), why the hell are sculpting tools in Unity? I cannot imagine a single person using them instead of ZBrush/Blender and why does it take about another full year to add C# expandability to the VFX graph?

I now this has been brought up quite a lot in forums etc. but you guys should really finally create a game using your own engine and tools instead of just making demos for specific features (with sometimes really hacky code in them) and calling it a day. It helps Unreal a lot, I’m sure it would help you guys as well.

This post got longer than originally planed and I’m sorry for some of the passive aggressive tone throughout it, I think I just had way higher expectations of this roadmap.

Answer:

@""

Thanks for the note and feedback. Long notes are fine! It is definitely good to let us know what you are thinking and seeing. Sorry that the roadmap didn’t meet your expectations. The specific points of feedback you have are good, and at the risk of sounding like I am deflecting, we are working on a solution for a lot of them.

I can tell you that internally there is a big focus on core product quality. We are also taking a more holistic view of what quality means. For instance, we have expanded the notion of high user pain bugs (which we have blogged about before) to include workflow/QoL issues - which are strictly not a bug by definition, but from a user perspective totally are. That is an example of one of the ways we are making things better.

Something else to add a bit of context around is that Unity is transforming. If you take your point about Physics engines for instance. Unity ships with a verified Physics implementation (based on PhysX), that has been in the product for many years. Many projects ship successfully on this. As we evolve the engine forward we are looking at new implementations - the two in preview Unity Physics and Havok Physics are made to leverage the future DOTS based architecture of Unity. That area is still a construction site, thus providing users with a clear picture while so many systems are in preview is a challenge. It is a challenge we have accepted though and we are going to tighten up how we expose preview packages to our users. To ensure that there is safety in their usage, and the expectation is clear between user and Unity.

Point taken on some of the tools, we are a believer in the right tool for the right job. We also hear from a lot of users that want to perform some activities in Unity without switching context. In many cases though (like the examples) there are amazing tools out there for some tasks.

Also, we are investing in production validation for our work. It was referenced in the roadmap talk. This is an internal team that builds vertical slices representing the sort of quality, scale, and content that our customers will be building. We’ll have different teams working on different areas - one focused on a high-end networked shooter, one on an async mobile network game, etc. The goal is that these teams work in partnership with devs internally and battle test (in the moment) the features being developed. You are going to start to see the results of this with our 2020, 2021 tech streams.

Overall, we will continue to listen carefully to the feedback and iterate on our plans. Again, thanks for providing your perspective.

Best,
Andrew.

[quixotic]

@yahorkleban

Hi! Thanks for the mini presentation!

I wonder if the VFX sample projects shown in this presentation are available somewhere to have a look? (like github or learn portal)

Cheers!

Yes, our VFX Graph sample project is here, and here’s a blog post that goes into detail on them.

[ans_unity]

@TextusGames

The shown layout of the visual graph is horizontal.
For me, it is logical to use a more modern vertical graph layout which allows separating flow (vertical) inputs and
parameter (horizontal) inputs. With is leading in more readable graphs.(However, you will need to introduce port proxies like in Bolt 2.)
Dots visual scripting is supporting vertical layout, why not to support it here.

Will visual script also support vertical layout? Or both layouts?
Do you consider to add proxy ports (connected parameters with hidden wires)?
Will this allow calling any function from c# class (static, generic, any…) without writing custom node?

Here is how it looks in bolt 2.
Both vertical and horizontal layouts are supported.
Proxy ports are supported (connected to any parameter but hiding wire).
Callingalmostf any function of any c# class or component are supported.

Hi TextusGames,

We are still experimenting with both options: the vertical flow is great for visibility when we have only one execution flow but is more difficult to handle for multiple flows (lack of space for the nodes because we still write text horizontally). Also in a context where the VS graph framework is also used for other graphs (state machine, procedural graphs, animation graphs, etc.) we have to consider several other use cases. We hope to be able to offer both options but we may have limit ourselves to only one for the first release.

Proxy ports are going to be supported as they are a great tool in larger graphs.

You can’t directly call classes in DOTS VS but you certainly write your own nodes.

Thanks for the feedback and have a great day!

[MattMurch]

Thanks for the update, I can hardly wait for this round of developments!

Is there any news about Cinecast development?

Answer:

@""

Yes! It’s in active development and working well so far. Can’t provide a whole lot of detail, but expect to hear news about it in the near(-ish) term!