Download

Quaternion in blueprint

The SetAngularOrientationTarget blueprint node takes a Quaternion as the
position target but there seems to be no user friendly way to create such
data. It would be great if there were conversion nodes from a rotator or
Euler angles.

If you know c++ you can do it yourself

Here is a RotatorToQuat blueprint macro for those of us who do not know c++:
http://zspline.net/files/RotatorToQuat.uasset

That is just an oversight, we have tried to hide quaternions from Blueprints to try and reduce complexity, and they are not much fun to work with element-by-element. I’ll deprecate the version of that function that takes a quat and add a new one that takes a rotator. Thanks for bringing it up!

I’d appreciate it if you guys stopped doing this kind of thing - I’m finding blueprints increasingly difficult to work with since the earlier UE4 versions, because you guys are abstracting away and removing core functionality under the guise of ‘reducing complexity’. Blueprint should mirror it’s C++ API counterpart as much as possible, not have everything hidden away in ‘helper’ functions whose functionality renders them pointless outside of very specific use cases. Quaternion math exists to solve specific problems, and people have historically used them for various ends in Unreal gameplay scripting, the classical example being objects that require the full three degrees of rotational freedom and the issues that would otherwise occur with Euler angles.

Just doing things like projecting from camera space, or working with actors based on their screen space coordinates has become a complete and utter nightmare, whereas it was trivial before. It would also help if functions stopped getting ‘friendly’ names - I get that you’re trying to cater for the non-programming crowd, but is isn’t helping anyone when functionality stops using naming conventions that have been widely used since the 1970s, since if you’re following any kind of documentation external to Unreal, it becomes a pain in the **** to translate. As a person used to said conventions, I frequently have a really hard time even finding the functions I’m looking for without going into the source code to find what they’re now called.

I have to say I agree with Ambershee on this one.

Before I begin I want to please note I am not directly this at JamesG, but all of Epic who is involved in this policy of weakening the power of what Blueprints were, even in the Beta!

It’s a strange day when you have to admit that Blueprints are weaker now then they were in the Beta!

Someone as experienced in the Unreal Engine as Ambershee should not have to be quoted as saying this:

If even one of your core community members says that, something is very wrong.

This message should not be ignored!

**Blueprints should be growing! It’s such a young language with so much potential!
**

I urge you all to consider this deeply!

People dont need weaker tools, just organize the tools and maintain their power!

Everyone learns and grows, and as they learn and grow, I dont think it’s a logical progression that advanced BP -> now I will learn C++ !

Beginner BP should lead to powerful advanced BP user, who has the tools they need!

If you think my comments are coming out of nowhere, then consider me as responding to the very IDEA that blueprints should be less powerful just to cater to a wider audience. You dont have to think of specific things that you might have done (or not done yet), just please make sure that this does not happen!

I am responding to the general software trend of lowering the power of a tool just so it is more accessible, when you do not need to!

Blueprints are a young language that can grow to be very powerful if you are not thinking of blueprints as simply a way to cater to those who dont want to use C++

Why not see what Blueprints can become on their own if you allow them to be powerful?!

At least leave the functionality in there that people who only have Blueprints as a programming language will need!

FRotator is not enough, even for my project which does not involve a 6DOF flying space shooter.

I’ve had to transition most of my custom game mechanics to Quaternion to get proper results :slight_smile:


**Organizing the Complexity**

Blueprints should not have reduced complexity, 

**Blueprints have so many tools to organize the complexity**, that you can simply organize everything appropriately and leave it in!



Why are you limiting what blueprints can become before they've had a chance to blossom into a truly powerful programming language?



People want and need the Power to be in Blueprints as a standalone programming language!

Rama

PS: again I am not needing you to think of specific cases as the focus of my response, I just want you to deeply consider this:

Blueprints can become a very powerful visual programming language, **why not work on maximizing the power of blueprints**, instead of thinking of how they can be made to cater to beginners?

No one stays a beginner, we all learn and grow, but advanced BP users will not necessarily then jump to c++, they should have advanced BP Power that you allow and encourage to be there!

I can appreciate where you are coming from but I think you are worried too much about public opinion rather than the people who will actually use your system daily. If the occasional user says "wow this is a lot of options, too much for me" that's not you're fault. They are just the occasional user anyway.

The people who use blueprints **daily** need the power to stay in blueprints and even grow!

**It's a young language, don't stifle it for the sake of "beginners"**

I think as designers we can all see the need to reduce complexity.

Of course we also want the most powerful tools possible.

The challenge Epic has is to introduce us to as much power as possible without making the engine into something un-intuitive like Cryengine. And of course they have a finite amount of man hours available.

I am sure they would love to give us quaternions in blueprint wrapped in a nice, polished package, but maybe it wasn’t high enough on the priority list so they removed what they felt was an unfinished, un-intuitive system?

Maybe the devs can put quaternions on the roadmap to properly flesh out?

Come on Epic…Why are you making moves like this? While BETA testing we all said how much we loved Blueprint system and how easy it is to do things. One of the main reason why other engine users shifted to UE4 was Blueprints. Now you are reducing their complexity for beginners? When we first got UE4 Beta we were beginners too in UE4 and we showed how easy it was to pick things up get everything running. If you are reducing the complexity for beginners they aint gonna say “Oh look, Epic reduced complexity for us. Its way easy now.”. Instead they’ll say “Oh look, its just another node editor that does nothing. We still have to do things in C++.”

Please Epic Please…Dont ruin this Engine for beginners.

I would like to quote what Hourences once said.

Me too…

Yeah, what they said.

I haven’t been around for very long, so I don’t know how the current state of Blueprints compares to the beta, but as a general observation there’s a limit to the degree of simplification and “friendlyfication” that any given system can take before it starts to lose its power and flexibility.

Blueprints are awesome, and the very best parts of the system are the bits that closely mirror the underlying C++ structure and classes. The more tightly entangled they are, the better, in my humble opinion. Please keep them in close parity going forward.

What, what do you put there that has 4 letters that makes sense?

Here to 2nd the comments in this thread. Not looking to bring any flames on, just want to provide some end user feedback.

I think there’s quite a few new to UE4 drawn into the system not only for the price but for blueprints in particular. When they realize that they may need to get into C++, I think there will be much more frustration and support tickets to deal with. So instead of speculating any further, let me give you the rundown of our situation and how blueprint limiting affects us.

So picture a small two person team looking to put together a modest mobile game. My partner is the artist and sees the blueprint system as a great way for him to tweak and modify the system when needed. I’m doing the coding. From time to time, our roles will merge and flip as needed. I’m coming from Unity and have not toyed with C++ since the mid 90’s. So, much relearning to do. Except while this learning is taking place, we prototype in blueprint and convert to C++ when able or when it just makes better sense for speed. Problem is when what we need isn’t in blueprint, or when the conversion from blueprint to C++ doesn’t work for reasons we can’t yet identify. So what we end up doing is spending a lot more time on trying to ascertain how the C++ functions work and how things tie together, instead of game development.

So in our case, what would help us out greatly (and many others I suspect) is a lot more documentation. I know this is planned and we need to be patient right :slight_smile: So, we’re being patient. Just that between now and then (when documentation really rocks), I suspect there will be much complaining with end users. Hey, maybe that’s what prompts to limit blueprints…which I think if so will just increase the # of support tickets. Anyway, while we all know that there is much still in the works and that there is only so much that can be accomplished on any given day, samples and copious amount of documentation for C++ functions would do wonders for those finding themselves diving into code when blueprints don’t cut it. I think this would be a wise foundation to develop until one day in the distant future blueprints perform and have all the capability that code provides.

Hope I don’t come off too negative, as my dev partner and I are quite thrilled with UE4 and very much look forward to the future with this platform. Just a bit of friendly feedback :slight_smile: Thanks!

b u t t? [adding more text to exceed minimum 10 char limit]

I think that Blueprints can have complex features without necessarily becoming user
unfriendly. The whole engine is supported by tutorials and the community and thats
a huge advantage. Staying with the quaternion example, a designer might create a
whole game without hearing about them, just by following tutorials. However if that
designer runs into a problem where rotators can’t do the task then he/she will end
up learning about quats. And that knowledge will help that designer down the line.

@Zeblote: That would be “****”.

Heh, didn’t think of what way to write it.

@Zeblote, ZoltanE and Xenome: Please stop trying to circumvent the word filter. :stuck_out_tongue: Seriously, it’s kind of obviously against the rules. This is your warning, I’m going to edit your posts as well.

As far as Quaternion rotation issues, we will make sure this gets addressed as soon as we can.

Thanks for the feedback, all! I can definitely understand the frustrations voiced in the thread. Balance between accessibility and power is always something we’re very cognizant of when making design decisions for the blueprint system.

To give some insight into our thought process, we never make conscious decisions to limit our users, and we always want to give people the ability to open up as much as they need. To this end, you’ve seen stuff like Blueprint communications, interfaces, user-defined enums, expanded delegate (event dispatcher) support, support for passing of interface parameters around in Blueprints, etc. All these are an attempt to make the Blueprint system more powerful, and let you do even more things without needing to touch code at all. Compared to where we were a year ago, our internal teams have been able to make many more Blueprint-only games now without touching code. My favorite example is the Couch Knights demo we did for Oculus at GDC. That was a multiplayer, VR-enabled standalone experience, and we didn’t touch a line of programming to do it. That wouldn’t be possible in the beta!

Some that i see from above:

  • Quat support
  • “projecting from camera space, or working with actors based on their screen space coordinates has become a complete and utter nightmare” (are the Project / Deproject functions that are BP exposed insuffiient for your case?)

What else can we take a look at?

That being said, I know the API changes can sometimes be frustrating. The quat thing is understandable! Those that understand quats should be able to use them. Thankfully, nothing prevents us from adding quats in as blueprint types (one keyword is all it takes!) and we can expose the same quat math and helper functions we have in native code. Or, if you don’t want to wait for us, you can do it yourselves for your own project.

So, we hear your feedback! What would be really useful now is to get some details of things that have changed that you perceive as limiting the usefulness of blueprints. I see a lot of mentioning of things being less powerful than in the beta, and that’s totally valid feedback, but it would be really helpful to us if you guys could give us some specifics that we can take a look at to better understand where you’re coming from! Quats are a great start, but what else causes you to think that BPs are being nerfed?

I checked our bad words filter and saw a few words that needed to be removed. I think “butt of my gun” and “cigarette butt” would be normal enough terms. I also found “bunny” as one funnily enough.

Thank you Nick and rest of Epic for hearing us out!

I was responding to my perception of the trend / thought process, rather than specifics, my only really tanigible contribution is to offer you a compliment:

Blueprints have amazing organizational tools!

I was shocked when I found out I could do a filter search for anything using the search results tool!

Blueprints have way more tools to organize complexity than c++ does!

So one thing I really dont think you awesome folks need to worry about is complexity!

My only real tangible helpful suggest is just use your already amazing tools to organize the complexity, and focus on organzing complexity wherever you previously might have felt the social pressure to actually reduce the complexity.

Organization is all it takes, and you have such amazingly already well developed tools to do it!

Great to hear from you Nick!

Hahah really?! the word bunny? :slight_smile:

Thank you, Rama!

Maybe it would help to clarify: we aren’t trying to hide complexity for complexity’s sake…we’re trying to hide unnecessary complexity! For instance, take something like the Math Expression node: this makes it much easier to hide the complexity of doing long chains of math, but a) it doesn’t limit you, and b) you should still be able to do it the “old” way if you choose! Hiding complexity isn’t about removing options, it’s about adding shortcuts to use if you need it, and providing a versatile API if you need fine grained control. Hopefully that’s in line with what you all want to do :slight_smile:

Dear Nick,

I sent you a PM but I guess I will say this publically as well:

I hope my feedback has not hurt any feelings over at Epic, I really care about all of your future, the future of the engine, Blueprints, and I appreciate all of you!

I’ve shared my thoughts/feelings only because I want you and UE4 to be as massively successful as possible!

I also have a feeling:

I really think blueprints will become far more powerful than unrealscript ever was!

I dont know why, but whenever I use Blueprints, I just have this sense that that they have so much power that is still yet to fully be revealed!

So please really pursue this idea:

How absolutely powerful can Blueprints become, way beyond anything that’s been seen before in the realm of visual scripting nodes and even Unrealscript?

I just feel like UE4 Blueprints have the community and devoted development team of people like you to really become something way beyond what anyone thought a visual scripting system could be!

Let’s all face it, Blueprints are the main scripting language for UE4 users, and always will be!

That fact needs to always be kept in view, and beginners will have their tutorials, while Blueprints becomes a mighty scripting engine!

So that is my ultimate point :slight_smile:


**Happy Feedback**

And yes math expressions is a perfect example of organizing complexity, not removing any functionality, great example! I really enjoy the math expressions system (many additional thanks to Michael Noland for this one)!

I also loooove that you can right click to merge any nodes you want into a function or a subgraph!

I get a  kick of merging groups of nodes just for fun, to satisfy my wishes for ultra-organization :)

Great to hear from you Nick!

[FONT=Comic Sans MS]♥

Rama