Announcement

Collapse
No announcement yet.

Serious Issues with March UDK Build

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

    Serious Issues with March UDK Build

    Hi guys,

    I've recently observed changes in the March revision of UDK that I personally find extremely frustrating and wondered if anyone could comment. They seem to largely stem from changes made to the StaticMesh class.

    1) Static meshes now have the option to change to 'dynamic' versions (aka kActors) in their properties in the static mesh editor. This is completely pointless and defies the point of having two discreet classes for static meshes and kActors. If I wanted a physics actor, I'd place a physics actor in the game world. If I want a static mesh, I'd place a static mesh. I don't know why this change has been made and wouldn't mind some sort of explanation. As far as I can tell, this is a completely redundant change that only causes pointless frustration due to unexpected or unwanted in game behaviour.

    2) As an apparent result of changes, preview lighting no longer works with static meshes in the editor window. Place a point light, then place a static mesh in an obvious blocking position and no shadow is cast. This is also very frustrating, since it defies the point of having preview lighting. Built lighting is fine and correct. However, because of my first point, static meshes that suddenly turn into dynamic versions of their former self screw this up horrifically; static meshes that can turn dynamic are taken into account when building lighting when they should alway be treated as dynamic. Now when they move in game, the lighting, for obvious reasons is not updated and the shadow it previously cast is still there. If the change in the first point was supposed to make things quicker and easier, it certainly hasn't, because now the user has to manually set up each meshes lighting properties correctly.


    I've been working with the engine for a few years now, and I've just encountered these changes. I can't personally fathom why they've been made, unless this is some sort of partially complete implementation (and in that case, why has it been passed into a distributed build?)

    Cheers,

    Luke

    #2
    UDK can create volume texture ?

    UDK can create volume texture ?

    Comment


      #3
      ^ What?

      Also, with some playing, I've noticed that preview lighting *does* work with standard light classes, but not subclasses. This is a wee bit peculiar.

      Also, right clicking on any light will crash the editor completely.

      Comment


        #4
        In response to (1): Static meshes flagged as bCanBecomeDynamic=true will temporarily turn into KActors and react using PhysX physics when shot or pushed, giving the environment a more interactive feel.

        The advantages of this implementation are:
        - Consistent behavior (all objects using that mesh will be interactive, instead of it depending on level designer set up).
        - Transparent to meshing (L.D.s don't have to do anything special, but they can prevent specific objects from being able to become dynamic by setting the bNeverBecomeDynamic property in the StaticMeshComponent's collision properties).
        - These meshes are lit like any other static meshes until they move, so there is no visual impact to using this system. StaticMeshActors added using a mesh that can become dynamic have bSelfShadowOnly set true by default (so no shadow is left behind when they move).
        - Except during the short period when a mesh is being physically simulated, there's no additional performance or memory cost to these meshes. This is a big advantage compared to using KActors.

        Comment


          #5
          and fix the issue with the material vector parameter, I can only get it to work by looping the animation in Matinee and pausing/playing when needed, but it's not a good way of doing it, plus Matinee will crash a lot using materialvectorparameters

          Comment


            #6
            i have a problem with march build, too...everytime i start "Game - Unreal Development Kit" it starts and after playing any map for some minutes, it crashes...again and again and again...i tried changing settings, maps, re-installing...nothing happened...

            Comment


              #7
              I really thinl that the problem 1 isn't really a problem. I do understand that you want to keep the way it works and you are use to but it's really a good thing to switch that way instead of using a whole other class.

              about the lightning issue maybe you should have a look at the contentblog page there is some info on the incoming features, among them editor lighting. maybe this problem will be fixed with that.

              Comment


                #8
                Originally posted by Steve Polge View Post
                The advantages of this implementation are:
                - Consistent behavior (all objects using that mesh will be interactive, instead of it depending on level designer set up).
                I can understand why this may be desireable, but personally I don't like having that control taken away from me by the editors default settings. It seems extremely counter intuitive that a placed 'static mesh' might not behave as expected of a static mesh in the game environment. Further more, there's no way to distinguish meshes that have this behaviour by default from within the editor unless you go into the static mesh editor for each mesh.

                From a level designer perspective, this is much more of a hindrance than it is a help.

                Originally posted by Steve Polge View Post
                - These meshes are lit like any other static meshes until they move, so there is no visual impact to using this system. StaticMeshActors added using a mesh that can become dynamic have bSelfShadowOnly set true by default (so no shadow is left behind when they move).
                - Except during the short period when a mesh is being physically simulated, there's no additional performance or memory cost to these meshes. This is a big advantage compared to using KActors.
                I don't see why this wasn't just implemented as an (optional) aspect of the kActor class?



                Also, do we know why lighting subclasses now appear to be broken in the editor?

                Comment


                  #9
                  Originally posted by ambershee View Post
                  I can understand why this may be desireable, but personally I don't like having that control taken away from me by the editors default settings. It seems extremely counter intuitive that a placed 'static mesh' might not behave as expected of a static mesh in the game environment. Further more, there's no way to distinguish meshes that have this behaviour by default from within the editor unless you go into the static mesh editor for each mesh.

                  From a level designer perspective, this is much more of a hindrance than it is a help.
                  I don't know if this helps, but maybe if you make a copy of the mesh and use 1 for static and 1 for physics?

                  Comment


                    #10
                    Man, all you people need to upgrade your PC or reinstall 'cause I have never had these problems....

                    Comment


                      #11
                      Well, maybe you need to tell us what all you're doing, because these bugs are present in recent UDK builds, and you should be experiencing them. (if I remember, right-clicking on -any- light in an earlier build was an insta crash, and from what i've heard right clicking on a subclass of light now is a crash .. i could be somewhat wrong on the exact specifics .. i only use the editor to create archetypes)

                      The whole StaticMesh->KActor thing I found to be utterly baffling, as well.

                      Comment

                      Working...
                      X