DOTS Visual Scripting 6th experimental drop

I’m not a fan of visual scripting as such mainly because I’ve seen what a mess you can make with blueprints but damn as a learning tool on how to code for dots this is awesome, well done!

 

It kept giving me the error even after removing the DOTS Editor package, I just can't figure out what other package(s) might be causing this so I went for your solution to move the package local to the project and edit it accordingly to @Guedez .
Works like a charm PLUS i can use the DOTS Editor package, just a bit more work when the VS package updates.

 

not working?

 

Hey awesome stuff. When is new drop scheduled, because I want to try it out, but if its only a few days I might wait. I know it's every six weeks. So should be very early February right?

 

I see Visual Scripting as being the thing the majority of Unity's users use, me included. Really I should only be doing actual code that can't reliably be expressed with nodes or is too much for nodes - pretty much same as Unity's shadergraph. So I'm really happy about the latest drop.

I do have some issues with it but these the staff have said are just basically going to be fixed with sugar nodes later, quality of life stuff.

 

wood be nice if we can see some node docs. cant understand most nodes.

 

Get Property, as seen in following graph, seems to produce duplicated code per component that is output from it
it seems very inecfficient and hard to read, is that by design?
I'd expect each already computed struct result (float2, float3, ...) that is being split by Get Property node to be stored into temporary variable and reused instead of computed from scratch per component. As computing it from scratch just keeps duplicating code exponentially with every nested use of the Get Property

generated code, containing duplicate math

expected code could look something like this (untested, may contain mistakes):

 

When using roslyn package (com.unity.code-analysis) and Memory Profiler, it throws ReflectionTypeLoadException at every script recompilation. Of course, Visual Scripting packages too (because it depend on roslyn).

Reported as Case 1214728.
https://forum.unity.com/threads/cas...es-throws-reflectiontypeloadexception.816714/

 

Thanks, that gave me a bit of a kick up the backside to give this a fair crack of the whip so I'm trying to dedicate a few hours a week to exploring this. It seems like a great way to get in to DOTS.

Also thanks to @CodeMonkeyYT & @wilson_p for the great tutorials.

So far one thing I'm not sure about is the way in which you get & set properties. At first it seemed great, drag the component on then add a get property node etc, but it takes up a lot of screen space for a single action.
Would combining the get/set propery node with the component be an option?
You could drag on the GetProperty node then drag the component on top and choose the property you wanted to get.

EDIT: Meh. Scrap that thought. I have a small screen and I was just looking for ways to reduce the node count but you could say the same for multiply & add nodes and then you probably end up with something less readable.

 

I am curious about this lack of code reuse as well...
I hope it's just lack of polish, but I've been burned making that assumption before... So how about this:


@Joachim_Ante , @ans_unity , or @jeanedouard_unity:

Why not (during code generation) traverse the nodes backwards to look for cases like these and optimize them? In addition to this, cache the results of the generation, to be used as a single pre-generated block. This cached block would be used until some part of the cached node hierarchy changes or is broken by changes to one of the precached nodes, that way the node (or the code generation) isn't always having to run through these optimizations each time the graph is added to (only when the existing hierarchy or nodes are changed). The full optimization loop would only occur once, after a code generation command is issued by the user. Finally, a partial optimization loop would be performed for non-cached nodes (or any optimization-relevant nodes in the hierarchy) for a faster code-execution.

"Performance by default", remember?

 

i am getting this error,how to fix it?

 

I was getting ready to test this drop. I noticed you are using "2019.3.0f6" did the issue also occur in "2019.3.0f3"? Curious what work arounds have been found as others seem to be able to play with it. Have you been able to work around the issue by using a different preview version of Memory Profiler / Code Anal...often in these preview packs I try dropping back one by one and many times it all syncs up and I can hit play even when using an older preview than what is listed.

Anyone else run into this or find a work around? I was going to test on Windows 10...also I have seen in the past even though the req./recommends says "2019.3.0f3" at start of this thread for this drop...that part isn't a hard lock all the time and can be manually rolled back to previous versions till everything is groovy gravy.

 

@CommunityUS I tested it in 2019.2.17, 2019.3.0f5 and it throws exception too. (Code Analysis packages can be available in 2019.2) So I think that this is a package issue, not Unity editor. I received response from Unity that it is successfully reproduced.

 

Thanks for the reply. Curious - do we have a git repo for Memory Profiler / Code Analysis yet?

RE: above
ok, that saves me a download. I wonder if when they did the drop they were working from a earlier CodeAnalysis commit. And the "preview branch" for those has moved on, without a preview version bump. (Or are there earlier previews to try if it is a package issue? like a preview.1 if they are using preview.2)

*forgive the lack of not knowing exact packages I am trying to figure out a good place to start. Did you try "2019.3.0f3" though? I see you tried 2019.2 but see below for my partial understanding on all this preview goodness.

I get what you are sayin about "it isn't an editor thing." But the packages can be somewhat smart. And you may be getting a bug that was fixed exactly for the "2019.3.0f3" package or didn't show up in the commits with everyone working off different branches.

Example from SRP - what I have seen and worked around in previews:
Like in SRP HD pipeline, they are working on SpeedTree...I am following it closely.
https://github.com/Unity-Technologi...render-pipelines.high-definition/package.json
In the JSON the "smart" package manager part is...
```
"version": "7.2.0",
"unity": "2019.3",
"unityRelease": "0b4",
```
- so in the case above if those packages are "unityRelease":"0f3" but the commits kept going without a new branch/package version number, perhaps it is possible to download the same package version name but get two different results based on the editor.
Above was only as a example, I know we are talking codeAnalysis. But I don't know if we have those repos on GitHub yet or internal some place we can grab at the commit level. My guess from above is that we may yet be able to get it at the commit level if the "unityRelease" acts as a sort of "tag" for us.
The package manager sometimes can be a tad slop in these preview releases. Where maybe it says downloading the right preview package, but if the "unityRelease" (here the editor you are using matches) you may get the commit is higher than you wanted.

Any thoughts on this wall of text lol.

 

Edit TracingRcordingSystem throws error from the line var frame = Time.framecount. Uninstalled to continue beating my head against the wall until morale improves.
------------
Edit..missed the comma..seems to be doing it's thing properly now.
--------
Did this. Ended up with a console full of errors. Things like UnityEngine.UI and other core packages were said to not be found. Took that line out and it reimported everything.

 

is it possible to create custom nodes using C# at this point? If so how would you go about that? I hit some roadblocks during testing by not being able to find some math nodes so I want to just fill the gaps until they get officially added

 

how to fix this error ?
Unity 2019.3.0f6

 

Hi!

I am totally new to this visual scripting stuff, but I mostly want to use it because you can create some lightning fast code with it (dots). ..Writing dots directly seems a little bit too complicated for me, so my hope is that this visual scripting is developing fast.
I want to use the normal unity workflow but mix it with visual scripting (dots) for faster calculations (enemy behavior, background calculation, path finding ..)
Anyway.. I have noticed a fundamental problem:
I downloaded and installed the visual scripting preview 0.2.3 (latest) and tried to make a test build for android (using unity version 2019.3.0f6).. but I got this error (the scene is totally empty, only the main camera is in it, no scripts attached):

Library/PackageCache/com.unity.visualscripting.entities@0.2.3-preview/Runtime/TracingRecorderSystem.cs(9,7): error CS0246: The type or namespace name 'UnityEditorInternal' could not be found (are you missing a using directive or an assembly reference?)

Seems it tries to build part of the code that is for editor use only.

How can this be solved?

Thanks!

 

its alpha stage. ofc there will be errors inside. this package not ment to be used in projects, but use it in personal education/overwiev.
im sure they know about errors and problems better that you and me. so just relax and wait when this feature came to version 0.9 atleast =)

 

Hey thanks for making this, I finally figured out how to get it to work after many hours of struggle with lots of different things mostly a trial version watermark bug in 2020, Among other things mostly because I used an old project from a new version to test it i think, but yea anyway.. Once I finally read the main post properly I realized what to do and Also that it says "NOT For Production use" lol I was just wondering if that's ever going to change at all?

And is it ok to still make free games without an abn/Registered Business or Full Unity Licence? as promotion etc?? I'm not sure if the Licencing link in the package manager is leading to a licence you actually agree with, could you possibly provide more info? Is it going to be paid content?

I have to say I got very excited after seeing code monkeys video, I'm about to have a look at it now finally lol.. But yea i really like the way its been laid out and the way it functions.. its just what i've been looking for since I started trying to use unity/code even lol.. I have no "Real" experience.. and well I didn't want to pay for Bolt or uNode and now that I've seen this i totally don't want too lol.. I'am 100 % willing to pay for this at a decent price..

 

Really? But why? I mean, I love shadergraph, but, for example, just the subgraph for plugging in the bumpmap features of the standard shader into an URP shader is like 14 nodes... alternatively a custom node with 3 lines of shader code. So while I understand the idea of node-based systems I really don't see how they would be useful anywhere outside of the most trivial solutions. It feels like yet another layer of abstraction, this time without line numbers and with a massive amount of annoyance involved in writing comments.

 

I can understand the motivation behind it, I guess I'm not seeing the big advantages though. Probably just my personal perspective though

Oh well, as long as there's no plan to deprecate the C# API I'm okay with it

 

Big advantages:

• Immune to employee churn, don't need to learn a sensitive and risky codebase
• Easier to employ & cheaper: don't need rock star engine programmers
• Cheaper to maintain and easier to follow (good designed graphs are clear as day)
• Can make safe changes to a game like in DLC without touching core code
• More people understand the problem and solution at the same time
• No performance disadvantages when used correctly, and it's hard to use incorrectly
• Black boxing safeguards internals
• Share methodologies with animation, physics, effects, dialogues, AI, shaders etc
• Runtime code changes for debugging on the fly

I mean if you can't see them, that should worry you...

 

Perhaps. But I'd still say that visual scripting is not exactly the silver bullet.

• No need to learn a risky code base how? Any custom nodes will still be in the code base, any kind of external system will still be in the code base, just that now you'll need to use a visual scripting environment to bring that code to run.
• agreed, that is an advantage.
  
• cheaper to maintain and easier to follow - perhaps, while they are small and trivial. I've yet to see a node-based way of representing vector algebra that makes more sense than, say, x1 = (x0 + v) * Time.deltaTime; but also making a well designed graph is not as trivial as it would seem.
• I can't see how that's an exclusive advantage of visual scripting. Nor how it's easier to enforce with visual scripting.
• Yeah, that's true. More people will be able to follow along, at least to an extent.
• Agreed
• Agreed, but again I fail to see how black-boxing would be limited to visual scripting.
• Yup, good point.
• This is true, though to be fair, Unity seems really fast in compiling the code, particularly when compared to UE4.

Using the editor is, of course, a good point and a good example of visual setup, but I really don't think I'd call that visual scripting. Of course you can't avoid using it and why would you even want to? But again, for any kind of non-trivial mathematical operations, any kind of non standard setup, you cannot set this up via the editor nor via a node-based solution. At least not in a way that would ever make more sense. Even non-programmers will have less of a hard time reading a few lines of C# code that projects a parabola onto a plane than following edges through nodes. Sure, you can write comments on nodes... but again, not a solution exclusive to visual scripting.

 

Well, there's always a part to play for everyone. Your mindset right now seems to be on a sole developer rather than a team. Engines like UE4 and Snowdrop have programmers who develop custom nodes (if/when needed) for the designers and other programmers who work on the project.

Actually Snowdrop basically only uses nodes and that's for everything. UI (They don't have a standard UI editor, all the positions and such is determined by nodes), AI, and all the designing features for The Division are made with nodes. There's a lot of GDC talks showing this as well (Snowdrop Engine and it's Node-based tools. The one for the AI is something else).

It doesn't seem like you've looked into the successful games that use nodes. There are juggernaut games out there made with nodes like Fortnite, The Division, Rocket League (It might have changed now but the first release was all Blueprints)
It definitely proves capable. With that said it doesn't seem like Unity will just go solely node based for scripting so both will go hand in hand. Don't think you have anything to worry about scripting wise. Visual scripting and other graph-based tools will and have definitely been useful.

 

A team of two actually. And this is part of the problem. Commenting code and discussing it by lines is simple, with shader graph we tend to just do our own graphs because it's just faster. It's true that we both write and read code though.

I'm not saying node-based solutions don't have their place, of course they do. Animation controllers, shaders,... definitely show that there's a place for them. But I can't help but wonder, since with ECS it almost feels as though the engine is being redone from the ground up, what the documentation will look like, say, 2 years from now? How will examples be handled? I'm currently on a 1920x1080 screen, in order to look at the really trivial example up above that just takes input I need 1.5 screen in order to see it. How does that translate into stackoverflow? How does it translate into googling? How does it translate into meetings? And while I can see the advantage of people not needing to know C# in order to connect something up quickly, how do you bring in new people? What skill do they need? Would you say Blueprints is 1:1? Blueprints experience plus 1 week and you're set? 2 weeks?

And of course, I'm not saying there aren't solutions to these problems nor am I saying visual solutions are not needed or useful. Just that like any solution it comes with its own set of problems, that's all I'm saying.

 

See this:

Data-Oriented Visual Scripting -- The Structure of a Language


---

You're actually one part of the audience I was writing this for.
Perhaps it could give some insights.

Visual Scripting isn't new at all -- the Data-Oriented portion, however, IS. -- Semantics really do matter.


Unreal fails with Blueprints in many ways (not for lack of trying though!), but Visual Scripts can actually be (even more!) legible than code. Check it out:

https://forum.unity.com/threads/data-oriented-visual-scripting-the-structure-of-a-language.819939/

 

Those are some very good points, and I do agree.

The data-oriented paradigm, if we want to call it that (I kinda think paradigm is a slightly overly-pretentious word ) is a fairly new concept with a fairly old idea behind it - keeping data contiguous and as small as possible, and broken up into nicely sized and general chunks, in order to minimize cache misses, and, with a bit of luck, organize the data flow into nicely encapsulated readable pipes.

And while I do agree I'm still not too convinced it'd be easier for me to read a graph than code. Of course, having Blueprints to go by doesn't help too much, they are about as awful as the UE4 C++ API and I will admit that Unity's flavour of visual scripting does seem to look nicer.

 

Yea, that's what's happening. DOTS is the future of Unity, all the new tools are being made with it in mind. Monobehaviour will still be around for a long time as they've stated many times but moving forward the new will be DOTS.

I get these concerns for sure. Currently, Blueprints have a lot of third party sites for sharing code and such but that's because of how the engine deals with its file system. In Unity everything is an asset so you can easily share things around.

Visual scripting and Blueprints won't ever translate 1-1 since Blueprints is kind of its own scripting language/system and not even just translating C++ to a node based system. Visual scripting is a Visual representation of C# ECS code and that's why it generates C# code on the fly as well. For blueprints, you have to compile that to C++ when making a build, so they are completely different. The docs situation will be like any other package. Visual scripting will have it's own docs and C# ECS will have its own as well. The good part of this is whether it's the ECS C# docs or Visual Scripting docs both would be able to translate to the other just like shaders (node-based or HLSL). So Visual Scripting in Unity will be just like using nodes to write the code and that's the strength.

In the far future ECS will probably be the only way of scripting but for now and the foreseeable future there will be both ECS and Monobehaviour so everyone will have a chance to transition. People who want to code in ECS have already started using the Visual Scripting tool to learn the concept to then transition to code after so that's another benefit.

 

I can understand the desire to move away from MonoBehaviour and yeah, it's probably for the best. The C# code generation (on the fly or otherwise - though obviously on the fly is better) is definitely better than what Blueprints do in UE4 because with Unity visual scripting system it at least feels like a far more solid foundation - C# is a tried and tested language and at least from what I've seen so far the generated code is really pretty much as readable as something that an IDE would autogenerate for you, so that's definitely a huge plus.

My concern with sharing is more about sharing snippets etc. You know how any decent search engine drops you straight into Unity docs when you look for, say, Physics.Raycast. Then there's intellisense helping you out with function arguments (hitting the down key will let you browse through overloaded functions on the fly). Code examples, even spaghetti-ish, can be read through more easily than browsing through spaghetti Blueprints, I'd say. At least for me.

 

When is the next drop, or is there even another drop before 20.1 ?

 

holywar begans…

would love to hear about official samples.

 

Is it possible to create a custom node where you can add your own code, similar to how you can create custom nodes in shader graph?