I’m just curious if there’s any particular things we should avoid doing in blueprint, limitations or known issues that can slow the system down significantly. Any areas where its weak and that we should put the focus on those areas in c++ instead.
Hi Daniel,
That is a very good question. It is not easy to pinpoint exactly what will cause an issue with Blueprints. It is currently under heavy development and most known issues are being rectified. Since this is the case, any given issue may stop occurring by the next release. So “weak” areas may become fixed. Right now, we are relying on our in-house testers and the Beta testers to let us know if there is any thing that should not be attempted in blueprints. Is there a particular problem that brought up this question?
-Alexander
Nothing in particular for me personally, I am curious if anyone else here has come up with anything significant. I mean Ive hit blueprints with everything I got for character physics so alot of in tick complex computations, Ive filled a good 1/4 of the graph including using functions and collapsing so there is quite abit of code in that one blueprint (803KB).
So far its very fast and any dramatic FPS hits come from gpu particles and dynamic lights which is totally expected. Even the debugging lines, coord systems, the text render components are all very snappy.
Only issue Ive had majorly is the fact there isnt a way to make structures but that really goes to usability and not the actual performance. I’ll keep throwing everything I got at it and see if I can actually get it to fall over lol
The second it falls over, you let us know and we will hop right on fixing it. Thank you.
Well since you brought it up I had a think about it and so far I have not crashed blueprint in umm, about 3 months. Ive crashed and busted alot of the other parts of the editor though 