Hacker News Reader

Comment by bullen | Hacker News Reader

There are two main reasons to avoid Unity:

1) As your project grows, it becomes unmanageable because the resource pipeline is hidden and you want to be able to improve that.

2) Skin mesh animation, which is the main point of using Unity in the first place, uses a compute shader which means they send all meshes from the CPU to the GPU every frame!

On the other hand Unreal takes 5 hours to compile and even Godot takes the same time as Unity ~30 min.

The only option is to fold your shirt sleeves up and build your own engine. It's not that hard really.

View on HN

> Skin mesh animation, which is the main point of using Unity in the first place,

That's an odd thing to say. I've never used it personally. Even if it's used in the majority of games saying it's the "main point of using Unity" is overstating things. It's simply one feature out of many that Unity provides.

> The only option is to fold your shirt sleeves up and build your own engine. It's not that hard really.

Maybe for you. I wouldn't even know where to start. And I wouldn't want to - that's not the level that interests me.

The only thing that Unity provides that has any chance of saving you time is the skin mesh animation = FBX or Collada to Mech Anim pipeline.

If you don't need that you should _never_ even consider using Unity.

If you are not interested by the underlying tech of any category of computing, you are not a programmer.

> The only thing that Unity provides that has any chance of saving you time is the skin mesh animation

Unity has saved me a lot of time and I don't use the skin mesh animation system.

> If you are not interested by the underlying tech of any category of computing, you are not a programmer.

I don't know much about Unity, but this gatekeeping ruins your credibility. It might very well be that writing your own game engine is faster than using Unity, but I actually believe that _less_ now after reading your comment. Your argument seems more pride-based than fact-based.

Programmers specialize based on their interests, and that's a _good_ thing. If we didn't have specialization, nothing useful would ever get done. Mistakenly choosing not to leverage prior work in design space[1] can come at a very high cost.

[1] Borrowing a term from "Darwin's Dangerous Idea" by Daniel Dennett (https://en.wikipedia.org/wiki/Darwin%27s_Dangerous_Idea)

Why would using a compute shader mean mesh data is sent every frame? Compute skinning is mostly the same as doing it in the vertex shader but you don't have to skin again for the different passes, instead you store to some GPU memory (so up the tradeoff is extra memory bandwidth on the GPU). No extra CPU/GPU traffic should be used here.

Well if you analyze Unity you'll see they send all meshes every frame. It might be because they want to be able to apply the same shaders on characters as on objects, but still vertex GPU skinning is the way to go and Unity does not. So you can't build a MMO with Unity!

I suspect that you're analyzing the frame trace wrong and thinking that since pre-skinned data is showing up in the draw it's being sent from the CPU, but feel free to send me a renderdoc capture or something and I'll take a look. Compute skinning and vertex skinning are both competitive; for games with many passes, zpre, multiple shadow passes compute skinning can beat vertex. Compute skinning is used by Frostbite and most other large engines too.

> So you can't build a MMO with Unity!

This has nothing to do with the skinning method, and I agree with the other poster. It should retain the same vertex buffer in GPU RAM and simply deform it in the shader.

Skinned mesh performance isn't a big issue for many developers.

I guess it's a problem if you're making a zombie game with hundreds of skinned zombies active. But the bigger problem in that case is that there's no easy way to LOD the animation or GameObject hierarchy.

The problem with writing your own engine is cross platform support. The grunt work that goes into that is something only a big studio can afford.

That said It has been done, see Heaps[0].

[0]https://heaps.io

If you take a long-term perspective; console and mobile are going away, you can't have a computer that you cannot produce on.

That leaves Windows on Intel and Linux on ARM. That is two platforms to support, not that hard really!

And really long-term Windows on Intel is going to go away too because of energy prices.

Another thing to consider is that CPUs and GPUs are not improving that much, so the engine you build now will probably last very long, if it's made well probably forever!

That is an interesting and certainly very long term perspective.

I want a device I can also produce on but do most consumers really want that? I think they want something simple that does one thing. This is one of the reasons I think the switch has been so successful. I can't see my portable tablet / laptop / workstation incorporating joysticks. Also with GPUs stagnating as you mentioned high end games will still need to run on high power devices like consoles.

Unity offers so much beyond your narrow experience.

I’ve made tonnes of games in Unity and never experienced either of these concerns.

I compile Godot in ~3 minutes. -j 8 on a 4770k (? 2015 cpu)

Reply on news.ycombinator.com