Announcement

Collapse
No announcement yet.

UE4 Editor Terminology: We need your feedback!

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

    #76
    Actually changing some of terminology after almost 1 year the engine released, is a bad idea imho. Because community tutorials or answerhub has tons of solutions about some problems or tutorials with those names. For example after you change persona or cascade to something different, beginners will have a lot trouble to find old tutorials or questions about them and they will need to find they had old names too.

    Yea names are a little bit confusing when you just start to unreal engine but it's not that hard to learn them with the documentation or from tutorials. I came from unity too, and people comes from unity, wants names like they see in unity engine. But most of them not familiar to unreal workflow or classes. (like the ones say "pawn" should be "character"). I think it's better to learn the engine how epic uses it because they have the most experience both with editor and unreal API. It's like when you try to learn another 3d software, if you try to imitate or bend your new software (especially shortcuts), like in your old software is always the worst idea. Please just don't change the engine for english speakers understand easily (like animation editor) because engine is not for every english speaker, it's for game developers and radicalizing game developing for any english speakers will make current developers to learn things again (like changing actor to something different will make trouble for API too) or finding old tutorials and answers harder.
    Last edited by theknoppix; 02-28-2015, 07:04 AM.

    Comment


      #77
      Originally posted by theknoppix View Post
      Actually changing some of terminology after almost 1 year the engine released, is a bad idea imho. ...
      That and don't forget that some of us worked with UDK a long time actually have been used to Cascade, Matinee etc already for a long time.
      - Martin

      A Simple Prototype

      https://www.martinegger.org/

      Technical Producer

      Comment


        #78
        Originally posted by Martin Egger View Post
        That and don't forget that some of us worked with UDK a long time actually have been used to Cascade, Matinee etc already for a long time.
        Yeah plus that I tried udk couple of times and even i remember those names, the only new thing is for me persona actually. I don't think any community tutorial video will be updated to terminology change, or even answerhub. So some of those tutorials and answers will be gone to under dust. This is whole bad idea maybe except couple of things. But i disagree almost every word in this thread like TheJamsh.

        Comment


          #79
          Originally posted by TheJamsh View Post
          I just want to throw this in based on what I saw in the original post:

          Please for the love of all that is holy, do not switch to a Y-Up axis.
          If the idea of Y-up bothers some people so much then they should be able to understand how much having Z-up bothers others of us coming over from Unity and Y-up apps. Outside of the arch-viz world there are more apps that use Y-up than Z-up. Best of all would be to have it be configurable then everyone can work comfortably.

          Comment


            #80
            Originally posted by Regularry View Post
            If the idea of Y-up bothers some people so much then they should be able to understand how much having Z-up bothers others of us coming over from Unity and Y-up apps. Outside of the arch-viz world there are more apps that use Y-up than Z-up. Best of all would be to have it be configurable then everyone can work comfortably.
            Configure this in code:
            object.position.z or object.position.y ? How do you see the configuring of this, swapping dlls? recompiling whole editor for one axys? Im sure devs acknowledge the fact its really hard to live with such
            "huge" cause of cognitive dissonance but the problem is far beyond just changing the way axis are displayed.
            tldr: it is big and tedious process of gathering and processing information on which parts of engine will be affected by this change, and i assume almost every part will be affected.

            Comment


              #81
              Originally posted by samb View Post
              Configure this in code:
              object.position.z or object.position.y ? How do you see the configuring of this, swapping dlls? recompiling whole editor for one axys? Im sure devs acknowledge the fact its really hard to live with such
              "huge" cause of cognitive dissonance but the problem is far beyond just changing the way axis are displayed.
              tldr: it is big and tedious process of gathering and processing information on which parts of engine will be affected by this change, and i assume almost every part will be affected.
              I don't know what the solution might be from a technical standpoint but the question of Y-up vs. Z-up was one of the things mentioned in the examples in the original post. We were asked for feedback on user experience and I would rank lack of support for Y-up operation as the biggest negative thing for me in my user experience with Unreal.

              Comment


                #82
                Initially this was something that bugged me a lot but now I am using UE4 a lot, I find I can switch between Z-Up and Y-Up apps quite easily, C4D and Unity (Y-Up), UE4 and Blender (Z-Up)

                Comment


                  #83
                  I REALLY want Y up or at least the option of changing it as a preference. I know its not an easy problem to solve. I guess the biggest problem would be if someone has written code blueprint with a certain axis in mind. My solution would be to tag each UObject/Actor or whatever with some metadata that would specify what mapping it has. so when things get compiled, the axis get properly sorted under the hood. Being able to override what mapping you want from an Actor as well. So when you request a value, you tell it what axis mapping you want.
                  Visual Effects Artist, Weta Digital, Wellington New Zealand
                  BLOG www.danielelliott.co.uk
                  @danielelliott3d https://twitter.com/danielelliott3d
                  Unreal Engine and VFX Tutorials https://www.youtube.com/user/DokipenTechTutorials
                  2015 Showreel: https://vimeo.com/116917817

                  Comment


                    #84
                    Just a quick question:

                    Is it okay if we could have staff opinions on the past naming schemes? I feel this is relevant, and would like to see a different side of this, instead of a one-way feedback.

                    Comment


                      #85
                      Originally posted by Martin Egger View Post
                      That and don't forget that some of us worked with UDK a long time actually have been used to Cascade, Matinee etc already for a long time.
                      Sure, but I don't think you would be bothered if they decide to rename Cascade by "Particule editor". Because even if you are used to the name Cascade, you would still understand if someone talks about the Particule editor. Now, the other way around, if you hear about Cascade, you have no way to guess what it is. Unreal Engine 4 is nos free for everyone and the goal is probably to democratize the engine and make it easy to use for new guys. Now, it does not bother me too much to be honest, and yes, you can learn this new vocabulary, it's not too bad. But having names like Particule editor or Animation editor would be straightforward and understood by all type of users. And I think that this proposition of renaming is all about that: make it clear to everyone.

                      About Y vs Z up axis debate. I never understood why 3D modelling software are using Y as the up axis. In my opinion you add axes with dimensions. As long as you are working in 1D, one axis is fine (x), if you work in 2D you need 2 axes (x and y for the added dimension) and if you work in 3D you need 3 axes (add the z for the newly added dimension). When you create your UI for instance, you need to position your elements on the screen, the screen is 2D, so you use x and y. It does not come to anyone to use x and z for this for instance. So why when we work in a 3D world you want to use x and z for the plane and y for the third dimension? When you place a point on a map (2D) you give coordinates in 2D: X and Y. And you can see the map as a 2D map, so the coordinates to place an actor should be X and Y. If you need an additional vertical dimension, you add one (Z). I have no 3D background, I'm an engineer and physicist with a C++ background. And anywhere in physics courses, the z axis is the vertical one. And in the order of things, why a left-hand convention? That's the first time I see that. Since then I have learned that's a convention often used in the 3D world. But again, makes no sense when you come with a classic physics training where everything uses right-handed frames. I'd actually be curious to understand why all 3D softwares had chosen different conventions (like Y-axis and left-handed frames). All the math and physics litterature are built on over conventions... So I don't understand it. However, it's only conventions and everyone can learn to live with it. Of course, if Epic could find a way to make it configurable (Y or Z axis and left vs right handed frames) that would be awesome. But I don't think it's easy to do internally.

                      I also agree on the "location" name used by Transform instead of "position". But it's quite a detail.

                      On the top of my head, the big issue I have is with units. I know that the only thing that matters is consistency. But it took me a while to figure it out and I still have some issues with it. The gravity field does not mention any unit for instance. It's only by seing -980 that I knew about it. I'm attempting to use UE4 for a serious game. I want to be able to simulate physics in a realistic way. So my modelling needs consistent units between the size of my model, its weight to compute forces in Newtons. And then when I add the force to my object, nothing moved. It took me a while to figure that everything was in centimeters. If it's to make things easier on the user, why not. However, in my opition the engine should use consistent SI units internally. Forces should be Newtons, weights in kg (which is actually correct) and distances in meters. Now, it's mixed, which make it difficult to compute any real physics at all to be honest. And if you want to make it easy to the user, there could be a small dropbox to change the units (like if you want to enter a particular distance in cm) and the conversion would occur internally automatically. At the minimum, units should be written. It is clear for the weight for instance, but the gravity, the forces, the distance, I have no way to know into which units I should be entering my numbers.

                      Comment

                      Working...
                      X