Announcement

Collapse
No announcement yet.

Please expose more API functions to Blueprints

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [FEATURE REQUEST] Please expose more API functions to Blueprints

    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...ull/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!

    #2
    *cough* quaternions *cough*

    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"
    HeadsAndBrains
    MARKETPLACE | YouTube

    Comment


      #3
      "learn to code"

      Comment


        #4
        Learn to code??? Many devs on here are full-time programmers, but want to make games or focus on gameplay not learning internals. So the OP has a valid point. Plus, the more BP offers, the less argument there is for C# etc...

        Comment


          #5
          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.
          Last edited by Slavq; 09-05-2017, 02:17 PM.

          Comment


            #6
            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.
            HeadsAndBrains
            MARKETPLACE | YouTube

            Comment


              #7
              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.

              Comment


                #8
                The reason is probably very simple, noone at epic needed those functions from BP yet. They expose new stuff all the time.

                Comment


                  #9
                  +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++.

                  Just my 2cs
                  [WIP] Procedural City Generator | RPG AI
                  [MARKETPLACE] Animal Behavior Kit | Space Shooter Template | Procedural Foliage Tool | Procedural Park
                  [FREE] Modular Road Tool | Action Platformer Template | Radar BP | Free Birds | Procedural Buildings
                  Join our Discord

                  Comment


                    #10
                    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!
                    * Sharp and responsive Temporal Anti-Aliasing tips and tricks
                    * Pitch-shift source effect (DSP) over the network (VOIP)
                    * My Portfolio and Developer Blog

                    Comment


                      #11
                      Originally posted by Konflict View Post
                      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.
                      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

                      Originally posted by Konflict View Post
                      Don't count on blueprint nativization will solve all your performance issues because it will likely won't.
                      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.

                      Comment


                        #12
                        Originally posted by franktech View Post
                        Learn to code??? Many devs on here are full-time programmers, but want to make games or focus on gameplay not learning internals. So the OP has a valid point. Plus, the more BP offers, the less argument there is for C# etc...
                        Pay no attention to Joviex, he's not really the norm for the community... Best simply to ignore and not even reply / comment.

                        teak
                        "A little bit of nonsense now and then is cherished by the wisest men..."
                        -- Willy Wonka

                        Smooth Zoom Camera Plugin for 4.24 here.

                        Comment


                          #13
                          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.
                          Last edited by Ninjin; 09-05-2017, 06:50 PM.
                          https://twitter.com/Ninjin42

                          Comment


                            #14
                            Originally posted by kjustynski View Post
                            So I don't this a reason against exposing more method to blueprints.
                            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.

                            Originally posted by kjustynski View Post
                            That's not entirely true, not for all of games.
                            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.

                            Still lot of code, scripting logic, UI, story can be simply done in blueprints
                            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.

                            expensive part of blueprints and move it to code later
                            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.

                            running thousands iterations of array + math operations.
                            Iterations are a good example where the problems start to arise. Even worse once you call functions in iterations.

                            * Sharp and responsive Temporal Anti-Aliasing tips and tricks
                            * Pitch-shift source effect (DSP) over the network (VOIP)
                            * My Portfolio and Developer Blog

                            Comment


                              #15
                              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.

                              Comment

                              Working...
                              X