Announcement

Collapse
No announcement yet.

Please implement Short-Circuit evaluation for Blueprint

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

    #31
    Originally posted by jwatte View Post
    And the mantra has been: if performance really matters, write it in C++...
    That is true...
    Click image for larger version

Name:	7ac.jpg
Views:	1
Size:	16.3 KB
ID:	1087579

    Comment


      #32
      Originally posted by TheJamsh View Post
      That is true...
      [ATTACH=CONFIG]57120[/ATTACH]
      But soon we will see all the BP being converted to c++ and then this no longer applies
      Easy to use UMG Mini Map on the UE4 Marketplace.
      Forum thread: https://forums.unrealengine.com/show...-Plug-and-Play

      Comment


        #33
        Originally posted by jwatte View Post
        I think it's fine the way it is, where simplicity is more important than brevity.
        99.9% of the time, short-circuit evaluation would not change the running speed of a blueprint.
        If you have a profiler that shows that in some particular case, it actually matters, then you should probably make this explicit in the blueprint by using an explicit second Branch node.
        And the mantra has been: if performance really matters, write it in C++...
        There's always 2 extreme spectrum of doing things in unreal. Always have been. The editor guys and the programmer advocates.
        True that certain thing isn't feasible to be done in BP. But I don't believe this as one of it.

        So yes I'm a greedy cake-eater , I want like good performance , but I don't want to let go of the other benefits in BP.

        Yes, in short, i want the cake and eat it too , but I'm trying not to throw a tantrum in the cakeshop while knocking over the other pastries.
        Asking nicely is as far as I would go.

        Click image for larger version

Name:	bigstock-Cake-Eater-1744895.jpg
Views:	1
Size:	61.8 KB
ID:	1087627

        yeap.. All the cake... every last bite of it....
        Attached Files
        Last edited by Frozenfire; 09-14-2015, 11:41 PM.
        Developer at AmmoboxStudios.



        Eximius ( An FPS/RTS Hybrid )

        Comment


          #34
          I just came across the same issue with the "OR" node, scratched my head for a while and realized that there is no "short-circuit" evaluation for the logical nodes in Blueprint. Had to chain two "Branch" nodes to achieve what I needed. Would be good if BP supported the SC evaluation. However, there might be a reason since a considerable nowadays BP users are not programmers, they might not understand or just not used to this concept as we true programmers do. (15 yrs C++ experience here). So chaining two "Branch" nodes seems more explicit on what's happening.

          Comment


            #35
            People arguing over performance and logspam are completely misguided.

            Yes if BP accesses a null pointer it will just warn you. But if your second statement is some call to a C++ pure function that relies on something not being null, if THAT accesses a null pointer because it didn't get short circuited, you'll crash. Yes, you can stagger the branches and that's how all of us did the workaround but the biggest problem here is consistency. It's being short circuited in most "grown up" programming languages, it makes sense to be short circuited in BP, as that's just programming too.

            Comment


              #36
              I agree with you for the most part. But when we write code in C++ (or other mature languages with SC), the ordering of execution is strictly following how we write it. However, in BP, the positioning of the nodes (top-down or left-right) doesn't signify the evaluation order, it is the order of the pins that determines the evaluation order. BUT (big BUT), since BP is visual, we have run into situations that sometimes we as users connect the "upper" evaluation node to the lower pin, and "lower" node to the upper pin (yes, two connectors cross each other) - sometimes it's just easier to rearrange connectors than repositioning nodes! So a careless viewer of the BP might assume that the upper node is the first condition to evaluate, and the lower node is the second condition, without ever noticing that the pins are connected in the reverse order. Confusion thus arises.

              I am not saying I am not voting to have SC for BP, but the above might be the case that BP is not exactly as obvious or semantically strict as code. Just my 2 cents, and not intending to start a flame war. :-)

              Comment


                #37
                I've programmed in C++ over 15 years, yet I can still see an argument for not shortcircuiting in blueprint. I don't think it's a no-brainer that it should do it "because most languages do". Most languages aren't visual scripts for one thing. The behavior of the select node on the other hand (evaluating all inputs), I don't think anyone could call that more intuitive.

                Anyway, the discussion of what people expect is kind of irrelevant - this is all a result of how blueprint pure functions are dealt with in general. See this discussion here.
                Essentially, when a node needs evaluating, it acts like a single function call in C++ would - it evaluates all the passed in arguments first, before executing its logic. If any inputs are wired from a pure node, the same thing happens recursively. As explained in the linked thread, not only will this mean every connected input will evaluate, but it can mean that some pure nodes get evaluated multiple times.

                I'm not exactly a fan of this, but I can see why it would work this way in a visual language. It would be pretty confusing if this evaluation behaviour was different just in the case of a few specific nodes. It would also likely break just about every blueprint written to date if it were changed now.

                Comment


                  #38
                  Coming back to this after god knows how long, I agree. Short circuit evaluation would be useful.

                  Comment


                    #39
                    Originally posted by John Alcatraz View Post
                    But soon we will see all the BP being converted to c++ and then this no longer applies
                    Hi John Alcatraz!


                    So you are saying that BP is a complete waste of time. I'm breaking my head trying to figure BP, instead of learning C ++? And in future UE4 will become something like Unity, full of plugins?

                    Do not take bad. I'm not disagreeing with you. You are a prophet John Alcatraz. I remember when you talked about Trello and Marketplace. You seem to be having a clear vision about future BP, with very fews intuitive nodes, and many features for non programmers. This looks wonderful! So I'm going to dedicate myself more time to my art, character modeling, rigging, texturing, and animation.


                    -luny
                    lunybunny.com
                    lunybunny.com

                    Comment


                      #40
                      Originally posted by lunyBunny View Post
                      text
                      No to all points. Learning C++ doesn't prevent you learning Blueprint (and if you know C++, you should know Blueprint pretty well at that stage anyway), any programmer should try to learn both as best as they can.

                      Additionally, the BP to C++ converter won't work as well as everybody seems to think it will. It literally does dumb copy-paste from the engine source files. In most cases it will still be just as slow if not slower. If you want the utmost in performance, learn C++ properly.

                      Comment


                        #41
                        Hi TheJamsh

                        Okay, but I still believe in the Blueprint Okudagram power.
                        Very few, almost none blueprint nodes and more small and intuitives boxes full of cool features.

                        I was seeing the Strategy Game method. Seems unreal 4 was made for C ++. In content browser there were very few BP programming elements, almost none, only a beautiful game Art. All very well polished. And the program seemed a very simple for a full game even for those who do not understand C++ like me.

                        Sorry, I'm venting, I have spent the whole night trying something realy very simple without any success in blueprint, so I'm still a little frustrated with the blueprint logic, but will not give up, I'm a Unreal Engine 4 Documentation fan. And still I have to texturing, rigging and animate two characters yet. Not mentioning the level design.


                        -luny
                        lunybunny.com
                        lunybunny.com

                        Comment


                          #42
                          Match 3 is a good example of a Blueprint & C++ Mix. I tend to go down the Shooter / vehicle game methods, write all my logic in C++ and plug in default properties with sub-classed blueprints.

                          People do tend to forget that being able to make full games with Blueprint was a happy accident, it was always primarily an artist tool.

                          Comment


                            #43
                            Originally posted by lunyBunny View Post
                            Hi John Alcatraz!


                            So you are saying that BP is a complete waste of time. I'm breaking my head trying to figure BP, instead of learning C ++? And in future UE4 will become something like Unity, full of plugins?

                            Do not take bad. I'm not disagreeing with you. You are a prophet John Alcatraz. I remember when you talked about Trello and Marketplace. You seem to be having a clear vision about future BP, with very fews intuitive nodes, and many features for non programmers. This looks wonderful! So I'm going to dedicate myself more time to my art, character modeling, rigging, texturing, and animation.


                            -luny
                            Haha

                            Thanks very much luny, but I think I'm not much of a prophet, Epic already announced quite a while ago that they work on a BP->C++ converter, so I don't predict anything, I just repeat what Epic said I think it's very³ experimental in 4.11 and should be usable in 4.12.

                            I am absolutely not saying that BP is a complete waste of time. Even with the BP->C++ converter, you will still write BP. It's just that once you package your project, the engine automatically converts your BP code into C++ code, so you no longer have the worse performance from Blueprints (like 10 times slower than C++).

                            So you should still learn Blueprint
                            Easy to use UMG Mini Map on the UE4 Marketplace.
                            Forum thread: https://forums.unrealengine.com/show...-Plug-and-Play

                            Comment


                              #44
                              Is wonderful John Alcatraz. But it does not make much sense to me
                              Anyway everything will become C++. At the end Blueprint was only a bridge!

                              Why Epic does not give a step further and transforms the WHOLE BLUEPRINT NOMENCLATURE to C++, Including the such short-circuit how the OP have mentioned in your posts. It could then be something bidirectional like BP_C++ => <= C++. Or only be a Fully Visual C++ very similar with the friendly Blueprint. And nicknamed BLUEPRINT++


                              luny
                              lunybunny.com
                              lunybunny.com

                              Comment


                                #45
                                I'm intentionally bumping this up in interest again , in hope that SOMEBODY would see this important enough to be in the roadmap.

                                I just wasted some time chasing a crash that was caused because of crashed caused by a C++ function, all because this function shouldn't be run if a prior condition at the top is false.
                                This is really bad.
                                Developer at AmmoboxStudios.



                                Eximius ( An FPS/RTS Hybrid )

                                Comment

                                Working...
                                X