There are a lot of useful functions in the C++ API that are not exposed to Blueprints. It would be really nice if most C++ functions were also available in pure Blueprint projects by default. Especially useful for e.g. pure Blueprint Marketplace products.
Some real world example: Today I need to compute a convex hull for a set of points on 2D plane. I could just use this function, but it’s not exposed to Blueprints: https://docs.unrealengine.com/latest/INT/API/Runtime/Core/Math/ConvexHull2D__ComputeConvexHull/index.html
… So I’ll implement some convex hull algorithm in Blueprints by myself, but it would be really nice if I could just use this function and move on to next tasks.
BTW, Is there a reason why many functions from API are not exposed to BPs?
Cheers!
Seriously though, once I tried to expose quaternions to BP, I found it dead simple and I’ve never coded in C++, just had to take a look at few "how to"s. They just said quats were too complicated… yeah, that was the reason for not exposing it to BP
I guess this is Epic’s way of saying “learn to code”
@Nicat Quaternions are also something that I miss from Unity. Would be nice to have them, especially since it’s easy and rather harmless, so if Epic fear that it’s too complicated for some reason, they could create some separate ‘Advanced’ section for these functions or something
Yes, that’s exactly the motivation here, as @franktech explained. For example, personally I come from a regular programming background and I can code in ‘traditional’ way (C++/C#/Java/whatever) without problems, but for me Blueprints offer much faster iteration times and I just prefer using them most of the time, especially after the nativization feature is ready.
… Fun fact: When you code too much (especially business apps and things like that), the coding itself can become boring and you just want to create stuff that works, not play with lower-level solutions and reinvent the wheel.
I understand that the Blueprint system still a relatively new thing, previous UDK Kismet was not that advanced, and most other visual tools were aimed more for easy ‘mechanics’ like opening doors or whatnot. So BPs are not fully fledged yet and still underpowered, but that’s what Im trying to change, e.g. with this thread.
@Slavq“**not play with lower-level solutions and reinwent the wheel”. I don’t think coding in C++ in UE4 means low level coding. You can certainly do low level stuff but don’t necessarily have to. Afaik C++ in UE4 is quite different than normal C++ due to it’s “boilerplate” or whatever it is called. Most of the functions are same as BP nodes, just in text and syntaxed form. Don’t get it as me defending Epic’s decision, I just wanted to point out what I saw from my experience. I too found so many useful functions which weren’t available in BP and had to find workarounds as well as abandon some ideas just because of those.
@franktech I didn’t mean to say no one knows C++ in UE4 community, just that UE team may want everyone to be using C++ in the long run… for some reason… after making the most advanced visual scripting of it’s time.
You’re right, that was only a random related fun fact, not neccesarily tied to UE4 and C++
I’m also curious what is the real reason behind hiding all these functions from BPs.
+1 to this. I also have a coding background and still prefer using Blueprints because iteration is so much faster! On my current project I’ve had to do so many workarounds because certain things aren’t exposed in Blueprint (quaternions are an example). I would love to have more feature parity between C++ and Blueprint - the more exposed the better IMO.
I say, if you want to use the stock Unreal engine from the launcher, dont limit what Blueprints can do, let us do the same thing as if we were using C++. If you want to extend a class or create additional low-level systems, then this is when you go to C++.
Blueprints are a nice representation of code logic, but does not support many programming paradigms that would require more advanced setups. If your blueprint require a lot of access to engine internals you are better to expose those methods by yourself, and while doing that you can wrap the funcionality into meaningful methods that specifically targets your requirements. It will result in very fast code execution, and good game performance as well. Don’t count on blueprint nativization will solve all your performance issues because it will likely won’t. Only well written programs can perform good, and the thing is blueprints are fall sort of such concepts.
I also believe there might be a few things missing from blueprints that would come handy once prototyping and experimenting with ideas, but you must realize the populating of the context search (right click menu) would take forever to run, and so it would literally defeat the sole purpose of working with blueprints once you have to wait minutes to show up the menu because of the overbloated lists.
Separating out functionality to plugins would be a nice idea however, and user can enable these plugins upon requirement to have access to certain exposed functions, but please show me a crazy nut who would keep these plugins updated with engine changes. No one will do that for you, it’s up to you!
The exposed methods in blueprints are for example purposes to demonstrate the underlying functionality of the engine, and epic have exposed them for this reason only. You want more? Follow the implementation and with a little bit of coding you can have access to the whole lot of classes!
I never waited for context menu to show up. There are already thousands of functions available and works instantly. So I don’t this a reason against exposing more method to blueprints.
I don’t know, maybe it feels slow without SSD… but working on game without SSD in 2017 is like slow suicide
That’s not entirely true, not for all of games.
I’ve seen some tests, it looks like nativization speed ups blueprints 50x in packaged build. It still slower than just good old C++, like even few times slower. Sure thing!
But it doesn’t matter that much if the game doesn’t perform shitload of updates every frame or some heavy actions. Of course the time should carefully decide if they write most of the their game without noticeable performance loss - not just going by “ignore C++, do everything in BP because we like it”. Still lot of code, scripting logic, UI, story can be simply done in blueprints and you wouldn’t notice a difference. Probably not some fancy rendering systems, destruction, physics simulation…
And you could always cherry pick expensive part of blueprints and move it to code later - after dust settled on features and you can safely rework it in C++
The funny thing is that blueprints in editor seems to be even 200-300x slower than C++ in packaged build. According to simple test: running thousands iterations of array + math operations.
Still, I would be guessing that should kill performance in editor. It doesn’t not.
Pretty sure they want to expose more, but it takes a lot of iteration and thus time. Here is why: The programmers write the code in C++ first, then they release it and then they see how most people use the functions and they also collect feedback (git pulls, editor crashes etc.). Then they refactor and expose all important stuff for the average Joe, so he can just plug in some variables and the function does its magic. Easy as that.
I don’t think you clearly understand the magnitude of the numbers, when talking about the available functions here. But to make a very rough estimate, let’s say blueprints have about 1% of the functions available in a form of a familirzed version of the ones that actually makes up the engine internal codebase. While this can be argued on which functions have any use in blueprints, it still is a very narrow accessibility to the underlying engine.
How many functions you wish to have the blueprints? Where’s the limit? You want something, Joe wants something else, but Edith is more interested in animations so let’s expose everything for everybody, right? So where do we get then? 10 times more functions perhaps? Or the entire codebase? You know the thing is, even a sophisticated intellisense of Visual Studio having a really hard time to dealing with the engine code, because it is very very large, and you can believe me on this.
The problem with nativization it will generate a code that is synthesised on the blueprint logic, and that generally fails to explore the programming principles. It just looks good and works ok in blueprints. But that is far away from what really is required once you set up a complicated operation. Here is an example. You can write a for loop by iterating from the begining to the end, but if you want it to be faster you will instead just iterate on the same values backwards. This way you can exclude one operation on each iteration that is comparing the index. While this sounds a bit trivial, the truth is millions of optimizations like that will make up a well running game. Blueprints have no support for such things, and the best you can have is maybe a reference to a value to avoid it’s being duplicated each time you access to it. You see, this falls far away from what is expected to be in a final product.
A recommendation from my part - which i mentioned in my previous post - is to use blueprints only to execute high level operations. Simple logic nodes that will run the underlying complex operations written in program code. Once you can reduce your logic flow to a few of these exposed functions only, this would not only keep your blueprints clean, but it will run your game incomparably faster.
This is a good idea, and usually is working very well, unless you find yourself in the situation that in code things are very different and you end up reinventing your logic. Fortunately the end result is usually faster than the expected which is what keeps me doing this way But of course many many things is better to be not attempted to be done in blueprints in the first place, because it would fall short very quickly.
Iterations are a good example where the problems start to arise. Even worse once you call functions in iterations.
It is quite simple - BP is supposed to be the fast development iteration tool so the more complex thing like quaternion (of which is subjective IMO) is purposely hidden - I remember this being written somewhere by Epic programmer. So again, it is subjective. And probably the best way is to simple list what functions are to supposed to be in UE4 and let Epic decide on it… or you can build yourself code from github. Again, it is subjective and depending on who compiles it. If it is Epic, then Epic is the one who decides which go to BP and which are not.
Imo everything should be exposed to BP (if possible of course!). The dev should decide if he wants to use Quats or Rotators (as an example).
The Problem I see with UE C++ simply is that that as an Indie/Casual programmer you correct too many compile errors because of Macros.
Writing code in C++ is juggling with the Macros’ compile errors. Only a small part of the programming is actual C++ code at least that’s my experience.
BP are so much faster and easier to work with and many people would be happy if they would have the same power (API-wise).
Thanks all for your input and interesting discussion!
@Konflict You can create custom loops in BPs too, decremental ones, custom iteration step ones, etc. Of course when you really have some performance critical part of logic you want to do this in pure C++, but if we’re talking about things like optimized for loop, in most real world cases the difference is unnoticeable these days c - Is it faster to count down than it is to count up? - Stack Overflow ] - especially when it comes to a typical video game mechanics.
About possible context menu lag after adding many API functions - I’m not sure about that, but for now everything shows up instantly even on my old HDD. (Will be buying an SSD soon, don’t worry ) One of the easiest solutions for a possible problem like that would be to group these functions into catagories, and load certain function list only if user searches for something within this category. Something like chunking on 3D world
… Or a simple switch like ‘Show All API functions’ somewhere in the blueprint/project settings. Then we can decide if we want to use simple ‘instant’ blueprint function set or have access to more advanced functions, even if it would cost some intellisense-style lag.
In my experience? Just few of them.
It’s just few convenient methods or concepts from standard programming we’re missing here. Lack of quats actually makes some blueprint operations really messy.
TSets and TMaps are perfect example where adding something new to blueprints give us performance boost.
Seriously, not too much is missing to script a lot of “simpler games” entirely in blueprints. Maybe not that easy if we’re talking about multiplayer, online systems, complex AI. But these areas should be usually covered by C++. For performance sake, but also blueprints wouldn’t be that useful here
Personally I’d love to see need improvements in blueprint editor. Less hassle when editing graphs. Proper support for local variables in UI, easier composing of looped operations, that kind of stuff.
I don’t consider Intellisense a “sophisticated thing”. I don’t understand why it’s still that slow and retarded after some many years of development. Why MS didn’t buy Visual Assist?
You know it’s still quite unfair to compare crappy Intellisense which scans every line of codebase and analyzes it to simply displaying pre-compiled list of functions in blueprints. I guess it’s somehow pre-compiled because I never waited for this list to show up.
This is all you need to know to expose anything from your classes. But even more, you can also modify the engine as well and expose everything for yourself. I wish you all good luck with your new learning experiences that will rocket you to the sky.
Exposing API functions manually is a solution, but not applicable to e.g. pure Blueprint Marketplace products or other for people who want to keep their projects 100% BP.
Anyway, more Blueprint power won’t hurt anyone… Quite the opposite, as far as I know.
they develop firstly in C++, i think they don’t have time and human to test, and guarantee all c++ code also work good when implement on Blueprint, and it rise up more Bugs.
) One of the easiest solutions for a possible problem like that would be to group these functions into catagories, and load certain function list only if user searches for something within this category. Something like chunking on 3D world