Announcement

Collapse
No announcement yet.

converting blue print to c++

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

  • converting blue print to c++

    Lets say you code out a bunch of this with blueprint, but you then want to go into c++ is there anyway to convert the blueprints you spent hundreds of hour creating to c++

  • #2
    I'd like to know too, I know that similar to how kismet was you can select your nodes and copy them to your clipboard and then paste them into a text editor. Doing that in in Ue3 would give you some unreal script I believe, maybe in UE4 it gives you some c++?

    Edit: I just tried it and it looks like it gives you a text version of your blueprint nodes, which can be handy for sharing your network with other people quickly in an email or something, but it doesn't appear to give you c++ code.
    Last edited by AdamHetrick; 03-22-2014, 05:59 PM.

    Comment


    • #3
      As far as I know, there is no cross compatibility. However, creating a working prototype with blueprints is going to be hugely beneficial to you in creating the code with the same functionality. You've figured out how you want to accomplish something, so it's only a matter of transferring it over. This should be incentive to keep your blueprints efficient and clear.
      |Mitchell S Lucas
      |Technical Sound Design

      |Marketplace Items
      Adaptive Binaural Wind - Demo Video
      Living Audio: Forest Critters - Demo Video

      Comment


      • #4
        houdini vops

        Originally posted by Obsidiaguy View Post
        As far as I know, there is no cross compatibility. However, creating a working prototype with blueprints is going to be hugely beneficial to you in creating the code with the same functionality. You've figured out how you want to accomplish something, so it's only a matter of transferring it over. This should be incentive to keep your blueprints efficient and clear.
        Houdini is all procedural, and has these things called vops. Its just a different layer to their node system where you can do all sorts of things. At the end of the day you can actually convert it to code by just right clicking on the parent container and choosing to compile the code.

        Having something similar here would be amazing.

        Comment


        • #5
          I agree. Because of the runtime speed difference (Blueprint is about x10 slower that native C++) this can be a HUGE performance boost. Would this be at all possible ?

          Comment


          • #6
            This probably would be good to put up for a feature request

            Comment


            • #7
              VOP (VEX Operators) are actually just nodes that generate VEX (Vector EXpression language) code. That right click operation spews the code into an ASCII .vfl file, which is not the most user-friendly code available and you probably won't have a very nice time parsing it. VEX was originally designed as a shading language, but like everything else in Houdini, it works with anything Houdini can make.

              The point is, VOP-based VEX nodes and shaders are just as fast as coded ones (faster sometimes), but if you must have code, you can prototype your thing in VOPs, and make an equivalent .vfl file with your nice, commented, human-readable, version-controllable code.

              I could see doing something similar in Blueprint, but it would really be nice to have a document that maps each Blueprint node to its corresponding C++ class/struct/function, etc. Maybe there is one and I just haven't found it. Such is the lot of a UE4 noob.

              Originally posted by ambient-whisper View Post
              Houdini is all procedural, and has these things called vops. Its just a different layer to their node system where you can do all sorts of things. At the end of the day you can actually convert it to code by just right clicking on the parent container and choosing to compile the code.

              Having something similar here would be amazing.

              Comment


              • #8
                Originally posted by Ad3ViLl View Post
                I agree. Because of the runtime speed difference (Blueprint is about x10 slower that native C++) this can be a HUGE performance boost. Would this be at all possible ?
                Don't know enough of the particulars of the Blureprint case to completely rule it out, but in general this a hard problem to solve. If it was easy the Blueprint compiler would probably already be capable of this even if it was just used as a final optimization in the cooking process.

                Most likely any auto-generated c++ code that could handle all blueprints wouldn't see a big enough performance boost to be worth the trouble. Some of the overhead would probably have to carry over to the generated c++ code as well.

                Some semi automated process to make it easier to translate complicated graphs to c++ code should be more feasible though.

                Comment


                • #9
                  Originally posted by Ad3ViLl View Post
                  I agree. Because of the runtime speed difference (Blueprint is about x10 slower that native C++) this can be a HUGE performance boost. Would this be at all possible ?

                  I assumed blueprint would be slower than a well written C++ but it is 10X slower? how was this test ran and can I see the results or is this a randomly pulled number just for effect?

                  Thanks

                  Comment


                  • #10
                    Originally posted by Nepos View Post
                    I assumed blueprint would be slower than a well written C++ but it is 10X slower? how was this test ran and can I see the results or is this a randomly pulled number just for effect?

                    Thanks
                    That figure is direct from the devs and has been stated at least 2-3 times by them. The figure also depends on what you are doing which hasn't been specified. Think of it as up to 10x slower.

                    The thing is though, you only really need to put the most intensive things into C++. Heavy AI and things that do tons of operations in short periods of time. So you wouldn't be moving ALL your code to C++, just the most important bits like base classes and complex math that gets called repeatedly.

                    It really depends on the game and the system you are working on.
                    Map Generator 1.0
                    Map Generator 2.0
                    Map Generator 3.0

                    Comment


                    • #11
                      Originally posted by Zeustiak View Post
                      That figure is direct from the devs and has been stated at least 2-3 times by them. The figure also depends on what you are doing which hasn't been specified. Think of it as up to 10x slower.

                      The thing is though, you only really need to put the most intensive things into C++. Heavy AI and things that do tons of operations in short periods of time. So you wouldn't be moving ALL your code to C++, just the most important bits like base classes and complex math that gets called repeatedly.

                      It really depends on the game and the system you are working on.
                      Thanks for the info. it is good to know

                      Comment


                      • #12
                        10x is a ballpark figure, the actual number depends greatly on the specific code. The 'meatier' the function calls you make, the faster it is, since most of the time is spent in the interop layer. Calling a bunch of tiny functions in a tight loop (like a bunch of math nodes) is going to be much worse than calling meaty functions like traces / collision queries.

                        RE: Determining what functions correspond to nodes, 4.2 includes a 'go to definition' feature in the right click menu for nodes, but you can also copy a node and paste into Notepad to inspect it in 4.1 or earlier, see this post for details.

                        Cheers,
                        Michael Noland

                        Comment

                        Working...
                        X