Unity is not behind UE4 when it comes to dynamic procedural content and may be ahead in some areas

http://procworld.blogspot.com/2017/06/unity-versus-unreal.html

A really interesting read by someone who knows his stuff.

The texture arrays part mostly.

 

Good points, but the dude once again calls Unreal "OpenSource". It is not.

 

At least for me I think Unity could do way better with procedural generation. What if it had a Povray style binary modelling system (CSG) with warp and extrude operations.

Or how many procedural developers are re-inventing the wheel over and over again e.g. Cube or Tetrahedra Marching Algorithms.

If Unity included these types of procedural api's would they be able to resist adding some basic extensible modelling features in the editor.

Would they even need to make a new Terrain system if they also add a dynamic distance based polygon system?

They could also do way better in fractal and noise functions for procedural generation of meshes and textures (they are in the particle system but do not seem to surface elsewhere).

 

First it was double precision, then it was (I think?) ai, and now it has come to this.

For CSG modeling in editor, use SabreCSG.

Marching cubes are a bit hard to generalize because polygonal output is dependent on underlying data. Unity provides you noise functions (perlin) and fractals do not exist in vacuum...

 

It is open source, but proprietary and not free. It seems that there is a mistake to make a synonym between open source and free software.

Free refers to the price, open source refers to the access to it's source code.
Unreal Engine 4 being open source, gets all the benefits from that source code mode: open collaboration, provides the rights to study and modify the code and give free access to these changes to others.
If I think a little bit more, the Engine is free, the game you make with it is bound to a revenue fee license.

 

Nope. "Free as in Freedom, not as in Free Beer".
OpenSource is typically associated with software licenses endorsed by free software foundation. Meaning copyleft, GPL, and the like, where recepients of the code get the right to redistribute it. However, OpenSource does not mean the software is free "as in \"free beer\"". GPLed programs can be sold for money.

Unreal is neither fully free (because you pay roaylties) nor opensource (because you get no right to redistribute the source code) in FSF interpretation of it.

https://en.wikipedia.org/wiki/Open-source_software

 

Like @neginfinity mentioned you can use SabreCSG. It's free open source under the MIT license.

https://github.com/sabresaurus/SabreCSG

Another option, one I preferred more after trying both of them, is Realtime CSG.

https://www.assetstore.unity3d.com/en/#!/content/69542

Both options are available now so you don't need to speculate about the benefits they bring to a project.

 

But then what is it? Because it's not closed source either (like Unity ).

 

The article is about the writers opinion on pros/cons between the engines how they implement proc gen content in their very specific use case.

This is still his opinion and the title here is basically click bait.

 

Proprietary engine with limited source code access they can revoke at any moment. Did you know that they have clauses in EULA that forbid posting more than 30 lines of code anywhere? That's not "Open".

Wouldn't call it a clickbait, because texture arrays are a very solid argument. Same applies to physx supposedly being unable to generate convex hulls.

 

Had a read and the author of the article is completely wrong about some things so I'm going to put it down as meaningless clickbait from someone who doesn't have his facts right.

 

Oh noes, but the OP said it's "by someone who knows his stuff.", what am I supposed to believe now? I was so looking forward to see my engine-choice being validated by an authority in the field.[/sarcasm]

Seriously though, I only briefly skimmed the article and also thought some of the PhysX statements were different from what I think is accurate.

 

@neginfinity "Proprietary engine with limited source code access they can revoke at any moment. Did you know that they have clauses in EULA that forbid posting more than 30 lines of code anywhere? That's not "Open".

Wouldn't call it a clickbait, because texture arrays are a very solid argument. Same applies to physx supposedly being unable to generate convex hulls."

---------------------------------------------------------------------------------------------------

The quote system is acting up :s.!

Nope, when I briefly came across the issue before I noticed you could use FTexture2DArrayResource.. Then I noticed someone had already made a GIT version (w/ mat ed support) , it just needed merging into master and Epic were taking their sweet time on it.. After looking at the GIT version, it didn't even seem overly complex to do..

As for Convex collision, that's a 10 second search.. Only reason I mention it is beyond the basics of "this engine has feature X and this engine costs X" I've never found a comparision / breakdown of both Unity / Unreal which isn't spattered with miss-information from top to bottom.

Unless you get to the end of a side / side project build I doubt you'd ever get the full picture and not many use multiple engines whilst keeping track of comparisons.. Even then it's only one game using a specific amount of functionality which might be useful to some, but not to others.

I'm doing a side / side build for a project, actually not with Unreal though.. It's Unity / Amazon LY.!

 

These days, it's a general consensus among developers that in order for a product to be recognized as an 'open source' product, it needs to be distributed under one of the approved OSI(Open Source Initiative) licenses:

• https://opensource.org/licenses

The difference between such open source projects, and proprietary softwares with provisional source code access is that the former also gives you the right to modify the source and distribute it as your own project. I haven't used Unreal yet, but I doubt you can just grab their source code and release it as your own with a different name.

The distinction between open source and free softwares is more problematic, though. But a 'free software' is something entirely different from a 'freeware', and in general, it means that it is distributed under one of those 'copyleft' licenses from GNU foundation, like GPL or LGPL.

 

I think the title of this thread is not accurate. The article was more about which engine was more out-of-the-box compatible with a voxel plugin, not which engine was more suitable for proc gen per se. There's a lot more stuff to get through to make a solid comparison of the raw capability of each engine in this area.

 

And lets face it, most procedural generation stuff isn't actually that engine dependent.

 

Which bits are wrong? Not that I don't believe you, I just don't know enough about the topic of the article to know

 

I second that.

 

Hadn't read the article prior to reading your post and my immediate thought was "Oh, I bet it's Voxel Farm again". Are there any commercial titles released with that asset? I know EverQuest Next was supposed to be built on it but it was cancelled.

 

No idea .. I've enjoyed reading articles on that site in the past though, plenty of fun stuff to read about. I think this one was a bit pointless though because it's just a comparison of how easy it is to get voxel farm running in either engine, and only covers a few pretty disparate issues that a reasonably experienced dev might be able to fix quite easily.

In any case, it's not a comparison of proc gen capability.

 

Colliders. They're in no way tied to your render geo in any way whatsoever. Utterly senseless. Unless of course you just started using Unity and clicked things while trying to get a dll working.

 

This all confirms my knowledge of Unity being the best ever and UE4 biting Unity's dust, so I will put it down as 100% facts!

didn't even click on it

 

The problems he faces trying to integrate the plugin are actually the exact same problems that anyone faces who is trying to write a procedurally generated terrain: lighting, physics, navigation, texturing, levels of detail...

 

There were a couple of points that were relevant in a general sense (didn't see anything about lighting or LOD?) but the point is that the judgements were made on the basis of whether the issue affected out-of-the-box use of the voxel plugin. Some of the issues were according to the author very easy to fix, but still presented a roadblock to having the plugin 'just work'.

Especially the last point, about how Unity's closed-sourcedness was a plus, sounded to me like it was made from the point of view of a developer of procedural plugins rather than a developer of procedural games as such.

Anyway, it was somewhat interesting, but not really a comprehensive analysis of all the problems faced when doing procedural generation and exactly how hard it would be to solve them in either engine. I dont think it was the author's intent anyway.

 

"Proprietary engine with limited source code access they can revoke at any moment. Did you know that they have clauses in EULA that forbid posting more than 30 lines of code anywhere? That's not "Open"."

..I guess they just don't want to see too much of the code they might have worked on while browsing.. nope that ain't my code never seen that before

 

I forgot to mention the occlusion culling. Mentioned or not, these are the problems to face when making a procedurally generated world. If an engine doesn't provide some scripting API to set up and control these things at runtime, you are in trouble.

Forget about the plugin. Imagine, you write your own procedurally generated world. The issues are easy to fix once in a local repository. But if you have to fix them again and again and again each time the engine updates, will you still use the word "easy"?

I don't see much difference between these two kinds of developers. The problems to solve are the same.

 

Sure, the problems are along the same lines, but like I said it's not a comprehensive comparison, it's just a few points regarding the plugin. Sure, texture arrays and nav meshes are key problems but it's only the beginning. What about lighting, compute shaders, garbage collection, quality of post effects such as SSAO/SSR, creating large meshes (>65k verts), etc etc.

Not saying that Unity isn't better, just that the title of this thread made the article sound like a complete comparison of engines for proc gen in general, which it isn't.

And yeah many of these problems are fairly engine agnostic. Thats why, if the article was about proc gen in general, I would expect more of a perspective of "how hard is it to solve problem X?" rather than "Is problem X already solved 100% or not?" - the latter being the perspective of the plugin developer who wants no errors with the demo.

Not quite. E.g. closed source being a benefit? It might just mean that as a plugin developer you don't have to deal with compatibility with anyone's custom bugfixes or implementations of crucial parts of the engine. Fair enough, but it's not necessarily a benefit for developers as such.

 

Now I'm not saying that closed source is good for developers
But I think the argument he was making was that open source promotes ignoring the brick walls since users can take them down themselves

 

Well, it's how I read the paragraph - he specifically mentions that closed source is "amicable for plugin development", and that forking the engine is great for application developers.

Anyway, if your reading is correct, some examples would have been great, because I can't say I see where that argument is coming from. Unity generally take a lot longer to implement a feature because it's closed-source - stuff has to be 100% checked out against all contingencies because people won't be able to fix problems.

As a game developer I pretty much consider open-source to be by definition better, because theoretically nothing is impossible to fix. I admire Unity's approach to creating a game development environment in general, but I don't ever see closed source as being better. 'Incentives' are great and all but I'd rather not depend on incentivizing anybody to get a game done.

 

Was on my phone then so didn't want to go and quote stuff then, but will happily now
This part in specific

Again, not saying I agree, but I think that's what he was trying to argue.

 

Of course what the author of the article may not realize is that there isn't anything stopping the middleware developers from peeking into the internals of the engine by buying a source license (if they don't get one for free). After all if people are able to work around problems they find without the source imagine how much easier it'd be with the source.

 

Practically, you might not have the time to fix it or resources to maintain the fix. Unreal engine based on my brief time with it, was very likely to introduce significant api changes between minor releases. Source code access is useful when you need to figure out how something works and possibly fix. Meaning when in the game development there are only two parties involved - you and the engine developer.

When community is encouraged to make their own engine forks, however, I think it is a bad idea, because there will be a mess - a ton of incompatible hacks and quick fixes.

 

Definitely agree, I don't see it as an ideal option at all. But I think that, especially for a fairly complex procedurally generated game, lack of source access is a bit risky. Even well-implemented features designed around non-runtime use might be completely useless, and having source access might enable you to modify them just enough to make them relevant again, rather than having to do your own from scratch.

 

IMO: Majority of procedural (aka "voxel terrain") games do not fall into "fairly complex" category. They revolve entirely around ONE problem which is displaying/streaming big chunk of land. This is not the kind of problem that'll require source code access.

Source code access will be required if you are dealing with levels that have non-euclidean geometry, seamless space warps, or maybe N dimensional space with N > 3. In this case, source code access may actually be useful, because you'll need different kind of scene graph. A number of games that attempt anything like that is very, very small. However, when you only want a voxel terrain, you should do fine without source code.

 

Didn't we just have a thread proclaiming that it was the asset store that allowed engine devs to be lazy and not implement features? Make up your mind internet land.