Questions on scripting, performance and exposed mesh manipulation functions

Hello there.

I’m looking for an alternative to Unity, I miss some features like LOD generation, decals, and advanced physics like fracture and mesh deformation. I see that it’s not easy to get the LOD generator working though (due licensing), and I’m not sure if UE4 has mesh deformation like CryEngine. I know it has terrain deformation, but that’s different.

I don’t like the idea of using a visual scripting language also, nor the idea of coding in C++ which I find extremely cumbersome. It seems Blueprint is not very fast too, being around 10 times slower than C++. I know that’s enough for most cases but I wonder why they didn’t chose something like C# (Mono) which is a good compromise between speed and ease of use imho, or even Lua, which I guess is easy to integrate, although it has some things I really dislike like implicit globals and addresses starting at 1. Is there any chance a scripting language like the ones mentioned is going to be implemented in the future?

Also, I know UE4 is a high-performance engine, but I fear that it may be an overkill for projects that are simpler on graphics. I mean, I fear it will do too much stuff under the hood the game won’t take advantage of. Any thoughts on this?

I would also like if UE4 exposes functions to manipulate meshes (get vertexes, create meshes procedurally, etc.).

Sorry the noob questions. Thank you in advance.

Its the native language of the engine. I have to learn it too. We all have if we want to use the engine more intensively.

Absolutely unlikely. There is a C# plugin floating around, but its not something that would be actively developed by Epic.

Not really. A blank project has no real impact. That comes with the assets you put in.
So for mobile you just have to restrain yourself in terms of shader complexity and polycount.

You can fracture meshes.

Thereis a decal actor

You can do some of that with blueprints.

This same question seems to be coming up a lot.

Blueprint is just as fast as any other scripting language. If you implemented C# or Lua it would have the same overheads. The fact it’s a visual scripting language has no effect on runtime performance, it’s still compiled to bytecode like anything else.

C# in Unity is also compiled to bytecode, it’s impossible to test its performance against blueprint since we’d have to implement both of them in the other engine but it’s certainly not as fast as native C++.

I think what people keep confusing here is the difference between a language, a language implementation and an API.

A language is a standard set of grammar, or as programmers call it syntax, eg C# is an ISO language standard. That standard can then be implemented by various vendors for different platforms, Microsoft of course have their implementation, there’s also the Mono implementation and Unity have one too. Each implementation will have different performance and trade offs, there’s nothing implicitly fast or slow about the standard.

More importantly than all that is the API’s which is what programmers use to actually use the language. A well designed API is what will have the biggest impact on performance and usability. For example the C++11 std library almost eliminates the need for ‘raw’ pointers except for in very low level programming. If you’ve found C++ cumbersome it’s probably because you were using a poorly designed API.

The UE4 API is really good, you don’t have to worry about a lot of the low level features of C++.

Really you should aim to be language agnostic. A language is just a tool and you’ve got to use the best tool for the job, not your favorite one. I’d give UE4 a go, you’ll probably be surprised how nice it is to program in.

To actually answer your question, no there are no plans to implement something like C# or LUA although you could do so your self if you really wanted. I think there are already others trying.

Thank you guys.

I’m targeting desktops at the moment. I’ve tried the mobile market but failed miserably :). Also, I don’t think UE4 is very suitable for mobiles because the build size is too big imho. It may be okay if your game has a lot of contents, but a 40MB flappy bird clone is too much.

To tell the truth, I’ve used QT previously and I really enjoyed working with it. So, I think you’re right in part. When you use a nice API things are different, but still, I’d rather use C# or something else… I’ve used lots of different languages, but there are the ones I enjoy like Python and C# and the ones I really would like to avoid like C++. That’s not only a matter of productivity but also preference, so it’s a little subjective, I for instance can’t stand Java, although I admit it’s a modern and high productive language.

Also, I know Mono is slower than Microsoft’s implementation but it’s not THAT slower. It seems MS don’t allow you to publish benchmarks, but I believe both are much faster compared to pure C++ than the ‘10 times slower’ speed of blueprint. I have no idea why blueprint is so slow because afaik the ‘blocks’ are just code being ‘linked’, so I don’t see why it’s not faster than that but that’s part of why I’ve asked the question. Also, it seems you can create blueprint ‘blocks’ in C++ and link them visually, in this case aren’t you simply passing data from one to another, just like if you were doing that in code? In this case I have no idea why there’s so much overhead.

I’m going to give C++ a try. Do you have to deal with memory allocation and that kind of stuff?

UE4 has garbage collection but it’s a mistake to think that means you don’t need to worry about memory allocation.

I don’t quite understand what you mean about performance? Are you saying that C# is faster than C++? Cause that’s not the case.

I think you missed my point about scripting languages. 10 times slower is fairly standard for any scripting language. The reason being it’s compiled to bytecode and run on a virtual machine that runs on top of the C++ API. Unity works the same way. The bottleneck is the communication between the virtual machine and the native code not anything to do with the language itself. C# or Lua would still have to do this, there’s no reason to think they would run any substantially faster.

What struck me most when I started with C++ (coming from Delphi), is the poor native string handling in C++. I was used to have “string” as a standard native datatype which can be used with the standard operators to concatenate them, or iterate over them by treating them as an array of char…
Another thing is the use of braces over keywords. I know, it more compact and tech-looking to use {} instead of “begin” and “end”, but visually I like it better than a cluttered set of braces. Especially when it comes to nested statements. I dont like the use of = and ==… In Delphi an assignment is x := 42 and a comparison “if x=42”. This avoids the formally wrong statement x=x+5. X is not x+1. Its meant as an assignment, but mathematically, its an incorrect equation… The Delphi way is much more “beautiful”
So I can understand why people would avoid C++. :stuck_out_tongue:

But there is no way around it.
What I could use though would be a nice tutorial about it. There are many of them out there, but they all have one flaw:

  • They either explain C++ in the context of UE4 and assume that you are familliar with C++ in general (syntax and concept wise).
    or:
  • They explain C++ in a way that is not compatible with UE4.

I followed a tutorial about C++, using Dev-C++. Wuith what I learned, I tried the standard stuff. “Hello World”, Number guessing game, Hangman (where string handling drove me crazy), TicTacToe, etc.
When I then thought I was repared and started with a C++ tutorial for UE4, it seemned that this was a complete new language. So far removed from the C++ that I “learned” in the Dev-C tutorial, that I was more confused than before.

If there were a tutorial that would approach C++ from the UE4 perspective and at the same time recognizing any unfamiliarity with the language by the audience, that would be awesome :slight_smile:

I guess only when a programmer is willing to lean a language he does not like, he has the “right stuff” :wink:

Thank you guys

UE4 has garbage collection but it’s a mistake to think that means you don’t need to worry about memory allocation.

I don’t quite understand what you mean about performance? Are you saying that C# is faster than C++? Cause that’s not the case.

I think you missed my point about scripting languages. 10 times slower is fairly standard for any scripting language. The reason being it’s compiled to bytecode and run on a virtual machine that runs on top of the C++ API. Unity works the same way. The bottleneck is the communication between the virtual machine and the native code not anything to do with the language itself. C# or Lua would still have to do this, there’s no reason to think they would run any substantially faster.
[/QUOTE]

Oh Geez… memory management… not again! :(… :o

I think we had a communication issue :). I was saying that there’s no way C# is going to be 10x slower than C++ imo. At least not for a self-contained stress code. Obviously if you’re calling C++ code then the execution performance would be the C++'s but there’s an overhead (and there’s the execution performance of the C# code itself). In any case, I don’t understand the ‘10 times’ figure. There was a discussion in the past about the overhead of the Box2D wrapper used in libgdx, and the conclusion was the overhead is negligible.

I thought that ‘10 times slower’ number was for example for a benchmark like mandelbrot running contained on blueprint-only code. Then it would be okay imho because most/some of the time blueprint would be just calling C++ code, so the low-performance logic would be used only for linking the data in C++ functions, but it seems that ‘10 times slower’ number is from a real-life application, so I’m assuming that only to pass data between C++ functions blueprint takes so much time that in the end the whole shebang ends up 10 times slower.

Once I start using UE4 I’m going to do some serious benchmarks, because that’s not a discussion that will be settled with assumptions. We need real numbers.

What struck me most when I started with C++ (coming from Delphi), is the poor native string handling in C++. I was used to have “string” as a standard native datatype which can be used with the standard operators to concatenate them, or iterate over them by treating them as an array of char…
Another thing is the use of braces over keywords. I know, it more compact and tech-looking to use {} instead of “begin” and “end”, but visually I like it better than a cluttered set of braces. Especially when it comes to nested statements. I dont like the use of = and ==… In Delphi an assignment is x := 42 and a comparison “if x=42”. This avoids the formally wrong statement x=x+5. X is not x+1. Its meant as an assignment, but mathematically, its an incorrect equation… The Delphi way is much more “beautiful”
So I can understand why people would avoid C++. :stuck_out_tongue:

But there is no way around it.
What I could use though would be a nice tutorial about it. There are many of them out there, but they all have one flaw:

  • They either explain C++ in the context of UE4 and assume that you are familliar with C++ in general (syntax and concept wise).
    or:
  • They explain C++ in a way that is not compatible with UE4.

I followed a tutorial about C++, using Dev-C++. Wuith what I learned, I tried the standard stuff. “Hello World”, Number guessing game, Hangman (where string handling drove me crazy), TicTacToe, etc.
When I then thought I was repared and started with a C++ tutorial for UE4, it seemned that this was a complete new language. So far removed from the C++ that I “learned” in the Dev-C tutorial, that I was more confused than before.

If there were a tutorial that would approach C++ from the UE4 perspective and at the same time recognizing any unfamiliarity with the language by the audience, that would be awesome :slight_smile:

I guess only when a programmer is willing to lean a language he does not like, he has the “right stuff” :wink:
[/QUOTE]

I agree that strings sucks, but I like braces better than keywords… I like Python’s way even better though :P. I’m so used to using == and = that I couldn’t imagine myself using that language… It’s just part of my subconsciousness I think, just like 0-indexes…

The tutorials that explains C++ in the context of UE4 are enough for me. It’s the same thing with QT, you use only (or mostly) the QT types, so basically you feel like you’re using another language that’s based on C++ because you hardly if ever use the standard C++ stuff, I think it’s the same with UE4, so that’s a big plus.

I got a little uncomfortable with the thing about memory though… I still have nightmares from the days I had to manually deal with memory :(. It’s a modern kind of torture imho.

Not neccessarily :slight_smile:
Well, Delphi provides no automatic memory handling at all. If you allocate memory, you are responsible to free it.
I love that behavior. :smiley: It gives me total control over the lifetime of any object or data. I dont mind explicitly freeing the memory.
And its less tedious as one might think. Object destructors can handle that very well…
Stuff like local variables, etc, still get cleaned up automatically once they go out of scope…
I mistrust any garbage collection :slight_smile: . All that reference counting slows things down. If really needed, I can wrap a pointer in a class and implement it on a as-needed basis…

Can you recommend a good one?

Sure garbage collectors slow things down, but in modern languages like Java or C# the performance impact is very minor for a huge benefit imho. Cython for example uses CPython’s GC afaik, which is not considered high-performance, and there’s the problem of cyclic references, which you have to deal manually but will still overhead the GC (it will still track them and try to collect them), but even with that amount of overhead and limited functionality, a self-contained Cython program (stress test) is VERY close to C performance, even on memory-heavy code. It seems in terms of performance Java’s GC is the best, at least that’s what they say, but I think that’s only in theory because I’ve never used a Java application that wasn’t choppy and reclaimed all the RAM in my machine (both hotspot and openJDK’s JRE) :). C# (Mono) seems to be much better in practice. Of course I’m comparing apples and oranges.

Aren’t the official docs enough? I’ve read only a little of them so perhaps they’re lacking and I didn’t notice…

My point about memory management is that it’s a mistake to think that garbage collection means you don’t have to worry about memory management. This is the kinda thing you get taught in school that’s total wrong. Garbage collection means that unused memory gets reclaimed automatically but you still have to manage memory as a resource, make sure there are no dangling pointers stopping collection etc. You probably know of all of that it just makes me cringe a little when I see someone go ‘oh, GC, now I don’t have to worry about memory management!’

In regards to the 10 times, figure Box2D is a C++ library not a virtual machine. It’s not really comparable. To run C# in Unreal you would need a virtual machine which would have similar overheads to Blueprint.

There’s a good video series on Youtube with an intro to C++ programming in Unreal you might want to check out:

I agree about the memory stuff, however, I don’t think the point about Box2D is valid, because after all you’re calling in Java (from a VM) the C++ code through a wrapper, and one may complain about the Java’s raw performance as one may complain about Blueprint or C#'s raw performance, however, you can’t complain about the overhead to call C++ stuff from Java; that’s negligible. Comparing that to Blueprint, it seems the problem is exactly that overhead because almost no ‘logic’ actually runs in ‘blueprint’ code afaik, it’s basically just calling native stuff most of the time.

I’m pretty sure that running a virtual machine, either Mono or OpenJDK/hotspot and somehow exposing the C++ functions would result in much better performance than that number. Still, I’m going to use C++, but I don’t know what’s the appeal of a visual language, specially when it’s not very performant and imho visual languages are much harder to work with, at least when the logic get complex.

Also, I couldn’t find anything about mesh manipulation, like creating vertexes and triangles, any pointers to docs are appreciated.

What I, and I think most people, like to do is use blueprint for prototyping since you can iterate so quickly and then move to C++ once you have it right, if you need the performance boost. You can also extend your C++ classes with blueprints and override key functions allowing you to put the beefy code that won’t change in C++ and quickly iterate different behaviour types in Blueprint.

There’s a procedural mesh plugin that comes with the engine that might be what you want. I’m not sure if it’s enabled by default. It’s pretty basic but it gets the job done. I’m working on a more advanced mesh manipulation plugin at the moment but it won’t be ready for a couple more weeks probably.

Yeah, I agree 100% that it’s a good thing having an easily accessible language that you can simply connect some wires for prototyping and of course nothing keeps you from using it for actual game logic if it’s simple and you don’t need high performance, like checking if the player has a key to open a door and stuff like that. For more advanced stuff, like my next projects is gonna need, an on-the-fly infinite world generator that merges the distant chunks geometries and maps for an extremely far view distance, for that kind of logic (the chunk classes, the functions to load and unload them (and generate the data)), you need a high-performance execution.

I need mesh generation for my next personal project because I’m going to be generating terrain chunks at various lods (2 overlapped adjusted perlin maps) and also I need to generate things like train tracks procedurally, other objects will be pre-made and will only be scaled and have some subparts and vertex colours randomized.