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++
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.
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.
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 ?
This probably would be good to put up for a feature request
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.
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.
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?
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
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.