DOTS Visual Scripting 2nd experimental drop

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?

 

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?

 

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)'

 

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()

 

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?

 

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

#89

 

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?

 

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.

 

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.

 

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.

 

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

 

This version looks a lot simpler! First drop was quite confusing as a VS tool. I liked it but I guess there is no job and multithreading support exist now, right ? Because when I look to codeviewer it is derived from ComponentSystem. Will that be supported?

Feedback:

• Looks a lot simpler, but I recommend to have some color on node headers(sounds like bs I know but artists love it) I saw there are coloring options for overall but I'd rather this (at least artists&designers in my company liked it)
  

• Entity queries are kinda set from blackboard and it doesn't feel convenient. I recommend to have a separate window for it or may be a separate graph just to set those up. Yeah a entity query graph would simplify things!

• There are overlapping labels on UI like that;
• I liked the macro feature. I guess it works like a subgraph!

 

Which version of Unity works best ?

 

2019.3.0a4

 

For a graph, imagine having lots of entity groups, setting them from a tree view is a little complicated, may be having something like this will simplify stuff