Announcement

Collapse
No announcement yet.

Making holes in Landscapes

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

    Making holes in Landscapes

    Ok this is ridiculous! In order to make a hole in the landscape, you need to delete a specific component but when you use the default settings on a landscape, there aren't enough components to make hole without deleting the vast majority of your landscape. For example on a 509x509 landscape, there are only 4 components made. I don't want to delete 1/4 of my level, I want to put a hole in so I can make a cave! Am I missing something?

    #2
    A question: Is your cave a static mesh or are you planning to sculpt the cave from scratch?

    If it is a static mesh then unfortunately, yes, you will have to cut out the terrain to fit the static mesh. If you are planning a scratch sculpt, UDK has the tool to help you including negative paint, average, noise, and smooth.

    Comment


      #3
      Well the problem is that you can't make a true cave using only the landscape since a Landscape system can only be moved in the Z position. SO even if I was going to sculpt it into the landscape, its not like you can have one that goes entirely through a mountain (IE a cave with two mouths). What I really want to make is a tunnel not a cave.

      Comment


        #4
        I've done a scupted terrain cave when I was learning the terrain editor. Keep in mind that you can have more than one terrain canvus in a level, so sculpting a cave in terrain would entail digging your pit and then moving your second terrain canvus over the hole thus creating a cave.

        While it can be done, it's a lot of work and should be stated that just using a static mesh saves a time and effort.

        Comment


          #5
          Yeah and without a proper ability to stitch multiple landscapes together, its not really worth the effort. I know how to do this fairly easily in Source, but UDK's landscape system is terrible by comparison. In Source you have far more control over what you can do with the terrains and its from back in 2005!

          Thanks for the reply anyway Kronicshem.

          Comment


            #6
            All heightmap-based systems have limitations due to the inherent XY grid design, plus there are additional limitations on their Landscape actor design.
            If tunnels and caves are to be a large part of your game design, I would change to a Landscape resolution that has a larger set of smaller components, just keep them well below 1024 components total.
            Use additional landscape actors or custom staticmeshes to fill out the edges of the holes. There are a number of easy methods to hide the joins.
            Or if the landscapes are reasonably small, do it all with staticmeshes.
            It's always easier to learn how to get around the limitations of the engine tools than to try to bend the engine to your ideal.

            Comment


              #7
              Yeah, Ultimately I'm realizing that Landscape is better just for the ground and Static meshes are better for cliffs, rocks etc. that you can use to make caves and tunnels. Just a bit frustrating. Actually, with Source Engine's terrain, you can move in XYZ. If UDK's landscape had a stitch ability, then it would be a lot easier to use like Source's. In its current incarnation its a lot more limited. Anyway...

              Comment


                #8
                If you are referring to the Source Engine Displacement Surfaces, technically that is not a heightmap-based terrain system, it is a brush surface that you can sculpt as a deformable mesh.
                Similar results would be available in UDK by sculpting a mesh with Sculptris, Zbrush, Mudbox, etc. and importing it as a set of regular staticmeshes. Or you could try a standard square tesselated staticmesh and using displacement maps in the materials.

                I am not a Source expert but I believe Displacements are limited per surface for poly count, requiring many surfaces to create a large complex terrain, whereas one Landscape can (in design but not usually practical) create up to an 8192x8192 (67 million quad) terrain.

                There is (to come?) some support for using vector displacement maps to offset the heightmap XY, or use the Material WorldDisplacement (DX11) with Landscape. This would allow for such geometry as overhangs, etc.
                http://udn.epicgames.com/Three/Lands...d Displacement

                Comment


                  #9
                  Yes the system in Source isn't technically a heightmap system however you could make very large terrains using one or multiple meshes. The problem with using Mudbox or any other sculpting package to create a Static Mesh is that you don't get the complex collision of a landscape and you also run into rendering issues if you don't break the mesh into several smaller pieces. This method is fine for rocks and cliffs etc. But would be terrible as an alternative to a landscape.

                  Comment


                    #10
                    Originally posted by TorQueMoD View Post
                    The problem with using Mudbox or any other sculpting package to create a Static Mesh is that you don't get the complex collision of a landscape...
                    Disable simple line and simple box collision on the static mesh and you get per-poly collision resolution. I doubt it's as optimal as landscape but with reasonably sized meshes should be fine.

                    Comment


                      #11
                      Originally posted by Spoof View Post
                      Disable simple line and simple box collision on the static mesh and you get per-poly collision resolution. I doubt it's as optimal as landscape but with reasonably sized meshes should be fine.
                      Always nice to know. Thanks Spoof!

                      Comment


                        #12
                        Originally posted by TorQueMoD View Post
                        But would be terrible as an alternative to a landscape.
                        A number of retail games have been released that used staticmesh terrains since there are a number of advantages to doing so, but it does take some work to create the assets.

                        Comment


                          #13
                          Originally posted by DGUnreal View Post
                          A number of retail games have been released that used staticmesh terrains since there are a number of advantages to doing so, but it does take some work to create the assets.
                          Using UDK? Can't imagine it would be fun to do that. You'd have to break them into so many pieces its not funny. Not to mention the lack of detail if you want to keep them low poly.

                          Comment


                            #14
                            Originally posted by TorQueMoD View Post
                            Using UDK? Can't imagine it would be fun to do that. You'd have to break them into so many pieces its not funny. Not to mention the lack of detail if you want to keep them low poly.
                            No offense. Not true.

                            Many maps created by Epic in the UT series also used staticmesh terrain systems.

                            What do you think the UDK Terrain or Landscape actors actually are? They are simply dynamically creating batches of mesh polys from a 2D grayscale image.
                            In simple terms it is a grayscale paint program that results in a dynamic real-time mesh.

                            Regarding "lack of detail" most Landscapes are using quads that are 256 UU spaced (vertex-to-vertex of 256UU = 512cm = 5.12m = 16.8ft) which is not small by any means, quad spacing should not be less than 128 for landscapes of any significant size (if you are using considerably smaller quads you are asking for trouble).

                            StaticMeshes render significantly faster because there is no overhead required for the geo-mipmapping etc., they also have less engine asset and footprint overhead, etc., support instancing, etc.
                            Staticmeshes also have the ability to have optimized polygon surfaces, heightmap-based systems can not, this is a reason why most architectural viz rendering systems use mesh surfaces, TIN (triangulated irregular network), etc.

                            Landscape culling occurs per component, so if even one heightmap pixel (mesh vertex) of a component is in the lazy-frustum, the entire component is rendered. Typical Landscape resolutions used by many people are with 63 or 255 quad components in order to keep the component count down such as 511x511 4-component or 1021x1021 4-component etc., and in most cases since level design is usually centeric (the players are in the middle of the map area), then typically 3+ components of the 4 components will be rendered at all times. LOD mip transitioning on the components is in real time so it has processing overhead.

                            One of the main reasons Landscape (GPU-centric) was developed is because the Terrain actor (CPU-centric) would tank the engine on any terrain of any significant size due to processing overhead.

                            Small chunks of terrain even up to courtyard size should always be staticmeshes.
                            Terrains that are using complex designs of overhangs, caves, or other "non-flat-heightmap" designs should be staticmeshes if possible.
                            Distant backdrop terrain that you can never get to (ie. mountains in the distance) should be staticmeshes.

                            The only real advantage that the Terrain and Landscape actors have in UDK is that they are easily modifiable within the Editor.

                            If a project in question has good concept and predesign there is no reason why terrain can't be modelled in Zbrush, Mudbox, etc. and used in UDK as staticmeshes with little to no fixup or reimport.
                            Way in the future this type of capability is planned for my software: the ability to choose 2D heightmap or 3D mesh, to paint the surface and layers for either type, and to auto-split and auto-LOD the mesh into components for export.

                            Comment


                              #15
                              Interesting. You obviously know a lot more about this than I do. The reason I was saying that a static mesh wouldn't be as optimized was based on the fact that in mesh form, one "Component" of my landscape is about 135K tris. Then again, I had only broken it up into 16 components. Still I would imagine that rendering out 4 of these to the scene (as you say you're likely to have at least 4 in view at any time if not more) would be extremely taxing on the user's system. Not to mention that if you have to switch over to a per-poly collision you'd essentially be doubling the tri count of every component. Also in my case, our game consists of a considerable amount of flight so you're likely to be rendering at least half the landscape at once when flying so you'd need some really well made LODs in order for this to be manageable.

                              Comment

                              Working...
                              X