No announcement yet.

Collision not visible yet works

  • Filter
  • Time
  • Show
Clear All
new posts

    Collision not visible yet works

    Hey there everyone.

    Just got the UDK package about 2 weeks ago and have viewed almost all the video tutorials. So I'm semi-familiar with a lot of the engine and how it works.

    I'm a Maya user, 2009. I've got a concept that I'd love to flush out using the Unreal Engine, and so far I'm liking it's capabilities.

    However, I've run into one of a few problems: custom collision detection (imported with in one .ase package from Maya). I downloaded ActorX and I've successfully exported multiple models, both static and skeletal mesh, including all their materials. Now I've looked through many forums (including Epic forums) and the UDK documentation looking for my answer regarding custom collision models.

    My problem: I've imported a simple door (picture below) with a collision model around it (just a rectangle). So I've followed the instructions of re-naming the collision model "UCX_LeftDoor" and the actual mesh "LeftDoor" (you'll be viewing this mesh). Both contain the same material in order to limit the amount of material slots created upon import.

    Here were the options I selected for the exporter. This is something I'm not really familiar with either. I've selected options and I haven't selected options before in order to test what they do. The only option I've found to change anything is the "Consolidate Geometry" option. I've found that if I turn that on, my "UCX_LeftDoor" is not converted to a collision model, but is presented as an actual mesh. So I leave that checked off.

    I get the status message that the export was successful:

    When I click on import in the Content Browser, it asks me to select the .ASE file and then to specify where the mesh should be placed within the Content Browser. I have to turn on "One Convex per UCXObject," otherwise the no collision seems to import in.

    Another warning I don't seem to understand is this next one:

    It explains that my ratio of verts exceed the tris or something like that. I don't understand it, but it doesn't seem to affect anything on my mesh or my importing process. Can anyone explain why that warning occurs?

    So finally, I get the mesh inside UDK and I open it up using the Static Mesh Editor and everything looks good (I applied the materials as well). I noticed that the "LeftDoor" seems to be by itself meaning that the collision must've been converted (which I thought was good), and then to confirm that, I clicked on "View collision" and it says that my collision mesh is now labeled as a collision primitive. However, I don't see any colored wireframe that's supposed to represent the collision model as well as surround the mesh.

    When I place the door in the editor, I have to scale it up by about 100 units (uniform scale) due to the use of Centimeters in Maya. And everything still looks good, however if I hit the hotkey 'c' to view all collisions in the game, the door seems to have no collision, even though it has 1 primitive assigned to it. When I re-build the level and play the game, my character walks right through it as if it had no collision, BUT EVERYTHING else in the game can collide with it. It can be picked up with the physics weapon, tossed into the vehicles I've set up, receive bullets, but will not collide with my character.

    ANY help would be wonderful! I'm really trying to make strides to get a game developed, and this is something that needs to be solved. Realistic collision detection is going to be my main focus. If there are any other methods besides building it in Maya, I'd love to know them.

    Thank you very much in advance!

    I can't comment really on the Maya issue, I use Max but as for building collision inside the editor, you can do it with 2 methods.

    One is to use the collision generator in the static mesh viewer. You have various options to deal with concave meshes or non angular meshes. It's good at creating straight forward collisions and you can sometimes get away with something more complex but it's kind of limited there since it's totally automatic.

    The other way is to place your model in the world and build collision around it using the builder brush and then convert that to a collision mesh for that model. This method is very much like building directly in Maya or whatever other program but more time consuming since you use the builder brush in stead of proper modelling tools. But you can essentially get the same end results. For something like this door you can quickly build out a collision shape for it.

    If you had a collision model and you still don't collide with it, it's probably because collision is not on. Not sure if you use this as interpActor but by default collisions are off for interpActors. Switch it to "block all".



      First off, thanks for replying. I figured I'd need some MAJOR help because this whole using another Engine business is really aggravating haha.

      I totally forgot to mention a few parameters in my situation.

      1). the Automatic collision doesn't work. I've tried the basic KDOP and even the default and custom settings for the auto-convex collision creator. Neither provided a result (not even a primitive in this case), HOWEVER, I did build collision automatically for the RightDoor mesh and it was a convex shaped model. From what I gathered, the autogenerator doesn't create Convex shapes when the model isn't convex. The LeftDoor mesh has a dip in the model, so maybe that's why it wasn't autogenerated.

      2). I've basically discovered and experimented with every single option there is for the Actor properties, including the collision defaults assigned and what they do (thank you UDK Video Tutorials). I've gotten the RightDoor (NOT the LeftDoor) to work wonderfully, collision and all (including as an InterpActor). I've animated it already, everything is wonderful. The LeftDoor is still without collision, which is why this doesn't seem to make sense. If it can't be autogenerated in the Static Mesh editor AND only my character walks through it and vehicles and bullets hit it, than there MUST be something wrong with the way it's modeled.

      *Phew* So maybe something wrong with the export or just the way this particular model is setup? I haven't tried creating custom collision for anything else yet. I'll try it on the right door and see if it comes in at all. As I said, I autogenerated the RightDoor's collision in the StaticMesh editor, so I didn't need to bother, but the LeftDoor is what gave me the trouble.

      Thanks again!


        Ok, that's pretty weird, I really have never come across that problem. The auto collision generator will work on anything, concave, convex, doesn't matter. It will just be better at some stuff than others as you can imagine. The more complex or specific collisions you need, the less useful auto collisions are.

        The one door model not being able to generate collisions at all, that's weird, I never saw that before. I don't know if that would be linked to how it was modeled or exported considering the other door works and if they were done the same way. But, I have no idea about Maya though, I never used it before for UDK stuff and I don't know if there's some rules to follow there. From within Max, I use ASE exports for static mesh and that never gave me problems.

        You could export an OBJ from Maya and upload it or mail to me although I really don't know if that would point out the problem. Unless for some really strange reason UDK does not like something about that mesh and it's something visible from an OBJ export, which I can't even take a guess what it could be.

        Maybe someone else has actually encountered and solved this type of problem. Maybe I'm just missing something from your explanations. But, you know, generally this stuff is pretty linear and not complex at all. What you describe is pretty much the procedure.

        Oh, the vertex ratio warning. Generally you can kind of ignore it. Unless you see it and you realize you're not being as efficient as you can be with your model, then of course you can go back and tweak it either to kill the warning or just be be more efficient even with the warning still there. As far as I know it's about UV's and Smoothing Groups. If you have many UV seams or smoothing variations then you have many duplicated verts. The more duplicated verts the less efficient. The warning is to tell you about this I think. That's what I could make of it, or that's what makes sense to me anyway.


          Actually I forgot to mention about the scale. You have mentioned that you need to scale the mesh up 100x original size. You could try have mesh export at 1:1 scale and see if it changes anything. Scale can have an affect on things although I'm not sure if scaling a static mesh inside the editor negates this and basically puts it at proper scale internally, for instance for stuff like physics or whatever.

          Example, if you scale the mesh up 100x and use another mesh of exact same but at 1:1 scale. Will physics be calculated exactly the same. That I'm not sure of and I'm not sure what else can go wrong if anything, if the scale is so far out.

          I would suggest to model things at scale. It can just make life harder not to do that, even if the engine can deal with it without problems.


            Yea, this whole process is a little strange to me. I've tried both "UCX_" tags and "MCDCX_" tags and both work, but carry no difference. Yea, I'd be glad to send it to you in .OBJ. I thought maybe history may have skewed the model, because these models were made about 3 years back. Ohhh, ok the ratio makes sense then. As I previously mentioned, 3 years ago, I wasn't very good at creating textures and mapping the UVs. I did a lot of hard work creating custom textures the hard way. That would easily explain why the ratio occurs. Thanks for that, I'll see if I can solve that next time. I definitely need to learn how to paint textures though, that's something a little dry currently.

            So I just re-imported the RightDoor WITH "UCX_RightDoor," the custom collision model, and it worked. So I believe we can eliminate UDK being the problem. This must be a Maya issue (surprise...). I've remodeled the door before and tried it like a week ago, I'll do it again to see results.

            And I was going to ask, how exactly does the scale system work? I know I'm working in Centimeters so I'm off. And I was also curious: Can I export a UDK model OUT of the Engine and into Maya? For instance, I'd love to use their robot pawn as a reference when I create new models. I've found that this helps the scaling process, especially in my days of working with SW: Battlefront 2.

            Thanks again!


              I just remodeled the LeftDoor and the collision is now showing! So the problem must have occurred during the modeling process, at least in Maya anyways.

              On to the next problem!

              Although the collision is coming in, my custom collision model is not importing exactly as I modeled it.

              Example: Here's the LeftDoor with the collision model split into 3 pieces (ultimately merged as one collision mesh).

              UDK apparently doesn't want to respect the boundaries I've given it as seen below.

              Any idea why THIS isn't cooperating now?


              Nevermind, I realized that the "One Convex per UCXObject" is creating the odd shape. Since all of my collisions are merged, it creates the parameter around all three, instead of respecting each model boundary. So my new question: How would you go about adding 3 collision pieces WITHOUT naming them the same name? EX: Three pieces cannot be named "UCX_LeftDoor."


                Glad it works..

                For scaling, again, I don't know Maya for a direct answer but in Max terms, you get various units to work with. As in the Max options you get Metric, US Standard and Generic. Only the Generic units is gonna go 1:1 with UDK. So, if I make a box 32,32,32 in Generic units it will also be 32,32,32 inside the UDK. But if I make a box 32 centimeters, it's in fact only about 12.6 units. I actually have no idea what's Maya's unit options so I can't tell what to do there, just give this reference.

                For exporting from the UDK, yeah I think you can only export static mesh. You can export if it's a default UDK model, you can drop it into your level, select it then go to File -> Export -> Selected Only and export it as OBJ. If it's a model you made and imported you can also export it from your content browser. You can't export skeletal meshes and I don't think you can export BSP. You can however convert BSP to static mesh and export that.


                  Oh ok. Here's the scaling options in Maya BTW:

                  I'll just have to fiddle with the scaling. I'll definitely pull out a reference static mesh though, that'll help significantly. Thanks again!

                  So I just re-read the Collision Reference Document and it does not explain how to name multiple Collision pieces for one mesh. They have that image of a Lolipop but it's composed of 2 mesh. I can't necessarily break my door into two pieces (I could, but that'd be disastrous).


                    Ok, I don't see from the Maya options any way to actually change things. Not sure if other Maya users here has any advice about the units setup. I can't think that Maya is not able to match units with the UDK, it doesn't make any sense.

                    For exporting multiple collision objects for one mesh, what I do is if my mesh is called "door_01" then my collisions are called "UCX_door_01_00", "UCX_door_01_01"... etc.


                      Yea, I'm just gonna have to fiddle with the units and use a reference. It's not may huge concern because I've been able to match scale decently. If the model is proportioned to itself, than it doesn't matter what the size, but thanks for the advice!

                      Ohhhh, ok, now that would make sense. I knew there had to be some tag, but I ended up naming it "UCX_LeftDoor_1" instead of "_00, _01" etc.

                      I'll try it out tomorrow and hopefully it works, because I was getting some funky results with my previous imports.


                        I'm not sure how important is the numbering for the collisions. The numbering I use is because that's how I always do things, I'm not sure if it's a collision model numbering convention as well or not. Maybe it does make a difference, I can't really say.

                        What I can say about collisions though is the models you export needs to be convex hull. I think ultimately the UDK will create it's own model from what you supply. I've had cases where collision models are merged or broken up or whatever, compared to what I have done in Max. What I do these days is I build them out of boxes and shape them into fitting a certain shape. So every model is a box next to another box to create a "non box" shape. If that makes any sense..

                        I have found this to be the safest way to make collisions and get expected results. As soon as you import the model, the UDK will interpret your supplied mesh to create a collision model and the less complex you make it on your end the better it will end up. I think if it sees room for optimizing, it will optimize the mesh.

                        It's very much like building collisions with the BSP builder brush for a static mesh. You may use many extrusion to shape it but when you convert it to a collision mesh it will ultimately end up with different verts than what you modeled since it will get optimized and collisions will be broken into convex hull so any concavity will be broken down. It can sometimes end up with weird shapes because of this auto optimizing. It should work, but it looks kind of broken and not very clean modelling sometimes.

                        I think with directly exporting them, it can be controlled more by doing separate boxes. You basically control the concavity of the collision and even though the UDK will still do what it wants, you can eliminate most weird looking tris and stuff this way. As long as you keep it 100% precisely modeled so if you shift one vert by a real tiny amount, it might look ok by eye but it will possibly convert into a small triangle collision. Since you model with quads mostly, this can sometimes have an affect. A quad side may look right bu if you break it down it might not be.

                        Anyway, I got a bit carried away but, yeah, that's what I've found with collisions exporting.. etc.


                          Ahh....excellent. I've been away from the computer for a few days, so I'll be testing stuff tomorrow in my spare time.

                          PLEASE continue to express using that amount of detail. You rambling on is considered passing on wisdom to a noob, so it's greatly appreciated.

                          I'll edit this post after I have results. The extra triangles and such make sense, I just wish for once the exporters would be completely fluid, no mistakes made. I know Maya's code isn't the greatest either, but nothing's perfect.

                          Thanks again for the response!


                          Ok, so I've run a few trials on this collision issue, and here are the results:

                          Here is the mesh and the collision models that are supposed to import into UDK as the collision model. Each piece is separate and is or considered to be convex shaped with no open faces (as previously mentioned).

                          Here is what imports:

                          Two out of the three collision models properly import in (wireframe and all). Their names are UCX_LeftDoor_00 and UCX_LeftDoor_02. UCX_LeftDoor_01 is NOT displayed (the rectangle that SHOULD be inbetween UCX_00 and UCX02). I've canceled out the possibility that the shape doesn't import at all by applying a different material to the shape (which, in turn, would create a new Material slot for the Smesh in UDK).

                          Turned out that I had issues importing a simple rectangle again. The material goes over, but the primitive count remains at 2.


                          APPARENTLY, the UBX_ extension was the main problem to begin with!!! Even though it's a rectangular mesh, the UBX_ naming convention reads it as a cube, not a convex mesh. Ultimately, that makes sense, but apparently I need to re-take geometry math class. I don't know the difference of my shapes!

                          Thanks for your help! I'll post if I have anything else to bug you with.


                            UCX_Mesh Collision

                            If you are using the "UCX_" technique, then you probably don't need three separate collider objects, since your door doesn't appear to the user as three separate pieces. Exporting the UCX mesh object with your door allows you to use a higher poly object as a collider, so you can actually implement more complex objects as collision data, even if your model seems "concave".

                            Just a suggestion, but unless your door has multiple segments, use only one complex UCX object (ie: a clone) for each simple door piece.

                            This wouldn't work in every situation, but you just have a door opening, so a single, large, more complex UCX should work.