Shapes is a real-time vector graphics library for Unity | Hacker News Reader

Shapes is a real-time vector graphics library for Unity

acegikmo.com

95 pointsImpossible27 comments

It's a shame that the conversation here is dominated by Unity's failings. This looks interesting, but the way the author seems to be hoping for support seems improbable to work imo.

I'm a hobbyist game dev who played in Unity for a few years and recently switched to Unreal. I'm not so well versed that I can speak the merits of this under the hood rendering pipeline or the other. A few general comments as an onlooker though on the engines themselves:

* Unity's interface is pretty simple. Mostly things stay on one screen, whereas Unreal has many nested submenus and its easy to get lost. The editor itself also requires a pretty decent computer to run, whereas Unity will run fine on most setups.

* Unreal has substantially better free content and pre-made stuff available than Unity. It's not even close.

* Unreal's blueprint system is easier to dive into and helps create a sense of one idiomatic way to do things, whereas Unity is more free form and has a lot of possible ways to do things which are, as you would eventually hopefully learn, bad.

* Unreal feels like its evolving into a better product. Unity feels like its falling apart.

It's the tragedy of Unity again. The built-in render pipeline is buggy, and to fix that you're supposed to switch to URP / HDRP. But then you lose access to all those cool 3rd-party plugins, such as this one.

could you expand on this? what is the problem with the defaults on Unity?

They are literally closing bugs as won't fix if you report them against the built-in render pipeline. The reason is that they've been working on the other render pipelines for years and they plan to deprecate the old one soon. But as long as the community of users doesn't switch, they cannot.

And the plugin linked here only works with the old render pipeline. The one with known bugs. So there's no way for me to directly use this. I would have to fix and port it first, to make it compatible with Unity's new pipeline.

And that beaviour of Unity stopping to support the working old stuff as soon as a new technology grabs their fancy has been going on for long enough that by now they're famous for it. Plus since they don't give source code access to the C++ part, you have no chance of fixing it yourself.

Add to that the fact that there's no easy upgrade path since shaders don't work between the old and new pipelines, and it doesn't appear to be possible to support both in the same app (enabling one while disabling the other, depending on the scene).

We're in an awkward position where we'd love to support the new features coming in URP/HDRP, but beyond plugin support we would also have to break compatibility with all of the asset bundles our users have contributed.

We managed to write scripts that fixed most (but not all) compatibility issues between Unity 2017 bundles running in 2019, but it's just not feasible to do the same for bundles between the old and new pipelines.

Really, it feels like Unity isn't supporting the developers who've been with them the longest and is instead chasing shiny new tech at our expense.

Following it from the outside looking in, it seems like the main issue is that Unity doesn't actually understand the work involved in maintaining an engine -- they're viewing it as a "the tech is better, so people will naturally switch" situation, versus a "the tech is better, but mountains of effort exists based on the previous tech, so changing tech requires an upgrade path, or no change at all" situation

akin to the MSDN Magazine camp of joel's portrayal of microsoft (Chen vs MSDN): https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

So they end up building parallel implementations, rewriting from scratch, not realizing that they'll eventually have to maintain both implementations or lose a large chunk of their userbase (unless they're so well-embedded that the userbase has no other option, which I don't think is the case). When they finally realize it, its too late... and probably even leads to a drop in assigned resources furthering the delay till release of the implementation

My guess it's more along the lines of the problem of marketing the new shiny to new users or new projects vs supporting the existing users. In a perfect world, they would build the new shiny and their existing users would switch (which it sounds like they keep pushing for) and their hopeful new users would be happy seeing the new shiny stuff.

The real world means you have to support both for some long period of time, because your existing users won't and many times can't switch because of myriad reasons you didn't think of, and if you can't both support the old and build the new, you have problems. Like this.

Not only did they decide write a new render rather than evolve their existing one, they wrote two. Now we have to choose to stick with the old render that we know, or evaluate two new ones and try and pick one.

Can confirm, you just need to look at the networking APIs to see the same pattern. The new API isn't ready yet but the HLAPI of UNet is already deprecated and even though LLAPI is getting deprecated later than originally anticipated there's no guarantee the replacement will be usable by that time. At the moment your best bet for networking is to look for third-party solutions (Photon, etc...). It's such a mess.

> And the plugin linked here only works with the old render pipeline.

Can you expand on what a plugin author has to do to port their plugin to the new pipeline and how much effort it is? Why don't plugin authors support both pipelines?

In the case of rendering special effects, it's akin to a full rewrite and maintaining two independent implementations afterwards.

When I did freelance shader work, I locked in the render pipeline of my customer first, because I know that my price estimate can vary 2x based on which pipeline is needed.

Absolutely spot on! It's the same case with the Unity UI system as well. They seem to have stopped adding features to the existing UI system for over a year now since it's deprecated. However the replacement UIElements (the runtime version) is not expected to be ready until later this year.

Their behaviour is puzzling IMO. They treat their developer base like an in-house team for which they can change tech direction at will. They seem to think that they can simply tell their huge developer base to switch to the new tech and everyone will just do it overnight. There are tons of reasons why that's simply not possible.

Does anyone have a book or library recommendation that would cover a canvas, and operations on it that draws vector primitives?

I made a hell of a lot of progress with Tkinter because it's so simple. Is there anything that simple and vector based?

It seems like the only options are "ugly" and "pretty but really complicated".

Maybe Raylib?

I've done a fair amount in the HTML Canvas. Seems OK. Don't have anything to compare it to.

Paper.js seems perfect, not too difficult to get started (although it is a bit more overhead than Tkinter).

For something simpler (although raster based), I would check out p5.js.

A friend wants to start developing a hobby multiplayer 2D game. He's gonna be the only developer. Would Unity be a good choice? Any other recommended alternatives?

For simple 2D games, I feel that Godot is often a far better choice than Unity. However, I've never used Godot's networking or multiplayer features, so I can't comment on those.

Godot or SDL, or Gamemaker... Depending on his current skills and preferences.

I'd recommend Godot.

Unity is also a valid choice, but networking is in a weird state right now with the official APIs, so he'd have to use third-party solutions that integrate with Unity (such as Photon, MLAPI or Mirror). It's not the biggest obstacle, but still an annoyance.

For 2D people generally prefer Godot. There's also https://coronalabs.com/

It would be better if that library was available outside of the Unity ecosystem.

It is heavily based on shaders, so it's kind of hard to decouple from the renderer, especially when considering the multiplatform-ness.

There are existing vector libraries for other environments, but none so far for Unity, so I think it is valid.

It should be relatively simple and portable shader code, and should not be too dependent on the rendering architecture, much like Dear Imgui can be ported to pretty much anything with vertex and fragment shaders...

It's relatively straightforward even for multi-platform: https://github.com/Const-me/Vrmac/blob/master/README.md#2d-g...

Kinda useless without official URP/HDRP support since Unity fully migrated to these pipelines.

Also useless without source.

Reply on news.ycombinator.com