DOTS Visual Scripting 2nd experimental drop

[thierry_unity]

Hi all!

Here is the 2nd drop of Visual Scripting! We squashed a few bugs and added a couple of new features that should help you out. As usual, don’t expect this to be fully polished and usable in a production environment. We are still pretty early in development. Also, note that with summer at our doors, expect the response rate on the forum to slow down a bit.
Without any further ado, here what’s changed in this release:

• Upgraded the code to be compatible with 2019.3 along with couple of UI fixes (you’ll need at least 2019.3.0a4)

• Graph states events (we’ll find a better name eventually, or maybe if any of you have good suggestions for us?): OnStart, OnDestroy
  

  

• Entity Instantiate Node
  

• Floating minimap (it’s now possible to dock the minimap outside of the Visual Scripting Editor window)
  

  

• Double-click on console errors will focus on the error in the graph

• Corrupted nodes can be cleaned when opening a graph

You can download the new zipped package HERE

We are planning to have a 3rd drop around mid-august. Until then, please give us your feedback here.

[techmage]

This is a related but somewhat unrelated question, I am wanting to get clearer understanding on this visual scripting system, but also some insight into it’s roadmap, and how that relates to my own efforts.

I was working on this, GTLogicGraph, which is a mutation of the ShaderGraph, but for more generic logic.
https://github.com/rygo6/GTLogicGraph

More specifically what it does is, you chain together a series of nodes, and each node does an operation on a piece of data. I have set it up so you add your graph on a component in your scene, then you can feed the graph inputs with things from the scene, such a transform or curve in the scene. Then that same component will output the results of the graph through firing UnityEvents on the component, which can be hooked up to anything.

I have been using this to build out a node based procedural modelling system. So for example, to make a race track. I have a curve component for you draw a curve in the scene. Then you input this curve component into the input slot of a ‘LogicGraph’ component, which then has a chain of nodes in it to simplify and refine the curve, then extrude a mesh along the curve. The LogicGraph component then fires off a UnityEvent in the end with the generated mesh, which will then add the mesh to a MeshFilter to display in the scene.

I was going to implement a lot of functionality to then thread these nodes as well.

BUT it seems like all of this could be replaced by DOTS, and this visual scripting system. Is that a correct intuition? Could I just re-implement all my procedural modelling nodes as nodes to work in DOTS visual scripting.

I have been looking around the package so far and what seems to be missing is a method to input and output data into a graph from the scene. So I can input a curve component, then have it output back out a mesh onto a static mesh filter. I was looking at the ‘Macros’ which seem to let you define inputs and outputs, but that seems to not be what I seek.

Is there a way to do what I describe with DOTS and this visual scripting system? Is what a describe an appropriate use of this system? Or does it make more sense to keep going on my GTLogicGraph?

[theor-unity]

@techmage

This is a related but somewhat unrelated question, I am wanting to get clearer understanding on this visual scripting system, but also some insight into it’s roadmap, and how that relates to my own efforts.

I was working on this, GTLogicGraph, which is a mutation of the ShaderGraph, but for more generic logic.
https://github.com/rygo6/GTLogicGraph

More specifically what it does is, you chain together a series of nodes, and each node does an operation on a piece of data. I have set it up so you add your graph on a component in your scene, then you can feed the graph inputs with things from the scene, such a transform or curve in the scene. Then that same component will output the results of the graph through firing UnityEvents on the component, which can be hooked up to anything.

I have been using this to build out a node based procedural modelling system. So for example, to make a race track. I have a curve component for you draw a curve in the scene. Then you input this curve component into the input slot of a ‘LogicGraph’ component, which then has a chain of nodes in it to simplify and refine the curve, then extrude a mesh along the curve. The LogicGraph component then fires off a UnityEvent in the end with the generated mesh, which will then add the mesh to a MeshFilter to display in the scene.

I was going to implement a lot of functionality to then thread these nodes as well.

BUT it seems like all of this could be replaced by DOTS, and this visual scripting system. Is that a correct intuition? Could I just re-implement all my procedural modelling nodes as nodes to work in DOTS visual scripting.

I have been looking around the package so far and what seems to be missing is a method to input and output data into a graph from the scene. So I can input a curve component, then have it output back out a mesh onto a static mesh filter. I was looking at the ‘Macros’ which seem to let you define inputs and outputs, but that seems to not be what I seek.

Is there a way to do what I describe with DOTS and this visual scripting system? Is what a describe an appropriate use of this system? Or does it make more sense to keep going on my GTLogicGraph?

I think it would fit. in terms of inputs/outputs: DOTS components are what you’re looking for, the whole project is based on reading/writing components on entities, as they are the data actually living in the scene. by the way, we support hybrid mode too, so you should be able to just work on your existing components. The mesh generation part is unclear, but worst case it would be a matter of exposing that API with a few custom nodes (eg. a create mesh node with vertices/normals/… inputs)

[techmage]

@theor-unity

I think it would fit. in terms of inputs/outputs: DOTS components are what you’re looking for, the whole project is based on reading/writing components on entities, as they are the data actually living in the scene. by the way, we support hybrid mode too, so you should be able to just work on your existing components. The mesh generation part is unclear, but worst case it would be a matter of exposing that API with a few custom nodes (eg. a create mesh node with vertices/normals/… inputs)

Is there any issue with using DOTS code for editor tools? The system I am creating is intended to be primarily used in the editor as a modelling tool, not necessarily at runtime by the end user.

Also, I have some of my procedural mesh operations as C++ code in a DLL. Will that work with this? Can I call a C++ method within a system running on DOTS?

[createtheimaginable]

Bug report here…

Using Drop 2 of Visual Scripting I got a spinning cube working in 2019.3.0a5!

But in 2019.3.0a6 I get a Burst Compiler error when I load in the com.unity.visualscripting-release-drop-2 package before I even create a Visual Script.

Library/PackageCache/com.unity.burst@1.0.4/Editor/BurstAotCompiler.cs(638,32): error CS7036: There is no argument given that corresponds to the required formal parameter ‘exceptionType’ of ‘BuildReport.AddMessage(LogType, string, string)’

[theor-unity]

@createtheimaginable

Bug report here…

Using Drop 2 of Visual Scripting I got a spinning cube working in 2019.3.0a5!

But in 2019.3.0a6 I get a Burst Compiler error when I load in the com.unity.visualscripting-release-drop-2 package before I even create a Visual Script.

Library/PackageCache/com.unity.burst@1.0.4/Editor/BurstAotCompiler.cs(638,32): error CS7036: There is no argument given that corresponds to the required formal parameter ‘exceptionType’ of ‘BuildReport.AddMessage(LogType, string, string)’

Quick fix: go in Packages/com.unity.visualscripting.entities/package.json and update the “com.unity.burst” version to “1.1.0-preview.2”. We’ll fix it in the next drop.

@techmage

Is there any issue with using DOTS code for editor tools? The system I am creating is intended to be primarily used in the editor as a modelling tool, not necessarily at runtime by the end user.

Also, I have some of my procedural mesh operations as C++ code in a DLL. Will that work with this? Can I call a C++ method within a system running on DOTS?

it could work, but right now the generated code only references runtime assemblies. if you have a clear data contract, you could manually run the generated system on your components.

I don’t think Burst supports C++ in external DLLs at the moment and I never tested it on our side, but you could disable the job system and create custom nodes for your calls, but that’s kind of going against the grain. In the future, it might be worth reimplementing these using burst compiled jobs…

[createtheimaginable]

I am trying to do something really simple using the Visual Scripting like click a button and have it start and stop my cube’s rotation.

I created a function node in my Visual Script.

But when I create a Canvas / Button and try to connect it using the Unity inspector to a function created in a Visual Script the function method does not show up to select.

The only selections I get are: ( see attached image )

string name
Dispose()
ShowInInspector()

[theor-unity]

@createtheimaginable

I am trying to do something really simple using the Visual Scripting like click a button and have it start and stop my cube’s rotation.

I created a function node in my Visual Script.

But when I create a Canvas / Button and try to connect it using the Unity inspector to a function created in a Visual Script the function method does not show up to select.

The only selections I get are: ( see attached image )

string name
Dispose()
ShowInInspector()

The visual script asset doesn’t exist at runtime, so you’d need to dump the code and actually reference the monoscript.

In game UI integration with DOTS in general and especially Visual Scripting is not there yet.
The way to do it will probably be the other way around - find the button from VS, wire the event. Stay tuned

[cecarlsen]

Is “DOTS Visual Scripting” the same solution as “Visual Scripting” introduced at Unite 2018 as part of the road map presentation? It looks radically different. I am very interested in this topic as I am also, like @techmage , developing a visual scripting tool. Naturally I am wondering about the overlap it will have with Unity’s native solution(s). I can’t find any sub forum on the topic. Anyone knows where can I find more information?

[elbows]

@cecarlsen

Is “DOTS Visual Scripting” the same solution as “Visual Scripting” introduced at Unite 2018 as part of the read map presentation? It looks radically different. I am very interested in this topic as I am also, like @techmage , developing a visual scripting tool. Naturally I am wondering about the overlap it will have with Unity’s native solution(s). I can’t find any sub forum on the topic. Anyone knows where can I find more information?

Well the following is a link to the post where they revealed that plans had changed and their solution would be DOTS-related.

[#89]( https://discussions.unity.com/t/720085 page-2#post-4146832)

[unity_ENboRzggqhioOA]

Will you eventually be able to move between both graph and script?
For example, create a graph, look at its C# code edit the C# code and it updates the graph?

[theor-unity]

@unity_ENboRzggqhioOA

Will you eventually be able to move between both graph and script?
For example, create a graph, look at its C# code edit the C# code and it updates the graph?

No. once you move to script, it’s done. However, you can extract part of the graph to a separate graph, then move that sub part to c# and optimize it.

[theor-unity]

@cecarlsen

Is “DOTS Visual Scripting” the same solution as “Visual Scripting” introduced at Unite 2018 as part of the read map presentation? It looks radically different. I am very interested in this topic as I am also, like @techmage , developing a visual scripting tool. Naturally I am wondering about the overlap it will have with Unity’s native solution(s). I can’t find any sub forum on the topic. Anyone knows where can I find more information?

Unity’s VS is dots only.

[Kolyasisan]

It’s impossible to use at all. Tested on 2019.3.a8 by using the project. There are no options to launch the VS window or to create a graph.

[thierry_unity]

@Kolyasisan

It’s impossible to use at all. Tested on 2019.3.a8 by using the project. There are no options to launch the VS window or to create a graph.

it’s not working anymore unfortunately past 19.0a5 , We are working with the editor team to resolve the different issues. sorry about that

[lucianvartolomei]

Some people at Unity seem to have forgotten the name of the product they’re working at: Unity. ShaderGraph is not uniting shader development for all pipelines supported by Unity (built-in pipeline support is missing) under a single Shader Editor, while other 3rd party asset store developers support development of shaders using visual editors for both built-in and scriptable render pipelines.
Now, the same thing seems to happen all over again: Unity’s official Visual Scripting tool will not support the standard way of working with Unity, the MonoBehaviour way, but only the newer, experimental ECS/DOTS way.
The same message that Unity broadcasted to its developer community when deciding to support only SRP’s in ShaderGraph will be sent once again, when all 3rd party Visual Scripting asset store developers will add support to their sollutions for the DOTS/ECS features, on top of the classic MonoBehaviour support, while Unity will offer support only for ECS Visual Scripting: That Unity’s official product does less than a 3rd party product, in case of Shader Editors and Visual Scripting…

[frarf]

@lucianvartolomei

Some people at Unity seem to have forgotten the name of the product they’re working at: Unity. ShaderGraph is not uniting shader development for all pipelines supported by Unity (built-in pipeline support is missing) under a single Shader Editor, while other 3rd party asset store developers support development of shaders using visual editors for both built-in and scriptable render pipelines.
Now, the same thing seems to happen all over again: Unity’s official Visual Scripting tool will not support the standard way of working with Unity, the MonoBehaviour way, but only the newer, experimental ECS/DOTS way.
The same message that Unity broadcasted to its developer community when deciding to support only SRP’s in ShaderGraph will be sent once again, when all 3rd party Visual Scripting asset store developers will add support to their sollutions for the DOTS/ECS features, on top of the classic MonoBehaviour support, while Unity will offer support only for ECS Visual Scripting: That Unity’s official product does less than a 3rd party product, in case of Shader Editors and Visual Scripting…

DOTS and SRP aren’t experimental, they’re the future of Unity. Anywho - Unity has priorities, they can’t just maintain MonoBehaviour visual scripting and ECS visual scripting very well at the same time, especially for a paradigm that won’t exist in the future. Unity Technologies has spread itself very very thin for many years, and they’ve realized it’s better to make a great feature and commit rather than just add it even though they know it won’t be well supported. Regardless, MonoBehaviour’s are the most documented thing in the entirety of Unity, ECS is not. There’s actual demand for a tool to move non-programmers (and even programmers, honestly) to the fairly new and uncharted ECS paradigm.

[Shinyclef]

@lucianvartolomei

Some people at Unity seem to have forgotten the name of the product they’re working at: Unity.

That’s a little dramatic. Maybe it’s better to ‘unite’ their effort on their future vision? Heh. Word play aside, I agree with the choices they are making for the most part. They don’t have infinite resources, and the battles they are choosing make sense for the future.

[Joachim_Ante_1]

Now, the same thing seems to happen all over again: Unity’s official Visual Scripting tool will not support the standard way of working with Unity, the MonoBehaviour way, but only the newer, experimental ECS/DOTS way.

In this particular case we realised that there are quite a few mature solutions that most of the community is using successfully for visual scripting. We didn’t think that what we can build on top of MonoBehaviours in terms of visual scripting would have been a massive improvement over solutions in the asset store.

On the other hand we saw an opportunity to focus VisualScripting on DOTS. Specifically enabling artists & level designers to write incredibly efficient multithreaded game code, by expressing their intent simply and the code being generated taking advantage of DOTS. The data centric nature of DOTS opens many new opportunities for visual scripting and interop with other code based systems.

We think a combination:

• Generating high performance visual scripting code out of the box (C# job + Burst + great memory layout)
• A UX language that reduces noodle graph-ness, by supporting stacking and other dedicated UX paradigm
• A straightforward path to transition from Visual Scripting → well organized DOTS C# code
• Amazing debugging tools deeply integrated into DOTS & Visual scripting

Provides something quite unique & powerful. Solving many of the long standing issues with visual scripting languages in general. That is worth putting our focus on and brings more value in the long term than splitting our focus and competing with asset store visual scripting solutions that our community is already quite happy with.

[TechnicalArtist]

I totally agree with you & unity, it makes more sense for a better future in Game performance.