No announcement yet.

Need advice for UVW Mapping...3DSMax

  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    if it were me, i'd make the map how I want to make it, filesize be damned. afterwards, if you find admins refusing to put it into rotation, you can always release a LE edition or whatever that uses stock textures, optimizes more, etc....

    Leave a comment:

  • replied
    For me, using the stock textures is a MUST at this point. I am definately NOT a texture artist and if I were to create all my own textures my level would probably end up looking somewhat worse than the original Doom. I don't have the "vision" to be a texture artist. Right now, since I'm just beginning to learn modelling, and since this is my very first attempt at using the Unreal editor, I've got my hands full with that to the point of near insanity at times. I would surely give up completely if I had to create my own textures as well. PLUS, since I DO have a background in mapping for Half-life in the past, I know how people are about downloading large files from game servers. I made a couple of really good maps for HL, but the file sizes kept them out of servers for the most part. Only a couple of servers, other than our clan servers ran those maps. You could have a full server running Bootcamp, Crossfire, Datacore, or any of the standard maps, then a custom map would rotate in and the server would soon be nearly empty because people didn't want to wait for the dload. As a mapper, it was kinda like a slap in the face when people rejected your "masterpiece" because they didn't want to wait for a download to finish, and was even worse when all the people would return when the stock maps began rotating again. For this reason, since I'm already going to be increasing file size significantly with custom meshes, I feel it is paramount to use the stock texture assets to keep the file size within reason. I may never get my level released to the public, but I'm gonna give it a real good shot. Should I manage to get the task accomplished, I DO want it to have a fighting chance to get some play time. More experienced mappers may feel differently about this, but that is my 2 cents on the subject.

    Leave a comment:

  • replied
    Originally posted by Bitter-Pill View Post
    I don't really recommend anyone to use the standard textures if they have the means to make their own at the same quality or better, and it doesn't hamper performance. Download sizes don't matter all that much if your maps are fun to play.
    I recommend the opposite -- use the stock textures as much as possible to keep your map file size smaller.
    Sure, you can freely create custom textures and have large map file sizes and you may still get some downloads from the hosting sites if it is a decent map, but your chances of getting onto servers and server play will be considerably less or not at all.
    Most clans and server admins will not put up maps that are larger than 10 or 15MB in size, due to both the issues with server-push on large files and the resulting wait time -- the majority of gamers will not wait more than a minute or so, and if the file is not pushed they will disconnect.
    This issue is going to be even more of a problem when UT2007 ships.
    See this thread on BUF.

    Leave a comment:

  • replied
    Obviously, any mesh that is large and meant to replace BSP should be textured similarly to BSP. I don't really recommend anyone to use the standard textures if they have the means to make their own at the same quality or better, and it doesn't hamper performance. Download sizes don't matter all that much if your maps are fun to play.

    Leave a comment:

  • replied
    Not to knock your comment as it is valid...

    The down sides are the same as using skins though:
    - The average large baked texture will be 1024x1024, which is too small for anything other than small to medium meshes. On large meshes it will be a blurry blocky texture look up close.
    - It adds additional assets to your map file which increases download time and server-push file size.
    - It is difficult if not impossible to create meshes that are using varying types of materials for each sub-material type, ie: a mix of shader, panner, etc. You are stuck with a single texture that you have limited material combinations with.
    - Detail textures may not work properly or be visually pleasing as you are limited to one Detail for the entire baked texture material.

    Multi-texturing allows for superior tile capabilities and Mips, providing a better visual appearance than you can (usually) ever get with a skin or baked texture.

    However, the method that you choose (multi or skin or bake) should be decided appropriately for each mesh that you are creating and the target game engine.

    Leave a comment:

  • replied
    *Note: I didn't read every post in this thread.

    Here is one way to use the look of standard textures with a custom model:

    1. Edit the UVs so that each face has its own share of the map.
    2. Apply the UT textures to your model in max until they look the way you want them to.
    3. Add any other feature such as bump mapping, lighting, etc, to improve the appearance.
    4. Bake them all into a single texture for that mesh.

    The advantage of this technique is strongest when the total number of textures you would have used in your map before baking, is larger than the total number of textures in your map after baking.

    Leave a comment:

  • replied
    Tutorial for Modeling, Animating and unwrapping (3ds to UT2004)

    Here is all you need for modeling, unwrapping, texturing, animating and importing from 3ds Max to the Unreal editor.

    Leave a comment:

  • replied
    yes, and thank you again!
    The UV Map gizmo is the thing I was overlooking. I'll have to review that in detail when I get home. I'm still not used to the features of the program. I was looking for a simplistic tool to align things such as the alignment tool within the editor, so the gizmo went under the radar as I searched everywhere BUT there. I used it to apply the mapping modifier to the mesh and assumed that it had performed its intended function. I already understood the face detach thing from your previous posts, and figured out how to do that and to apply a given material to that face. I just didn't know how to align the texture the way I wanted it once I got it applied. The book I have is at times hard for me to understand, you know, it's not a book intended for "dummies" like me. You should write books being that you have the ability to explain things so well and in such detail. Heck, I'd buy one. You've already answered several questions that my book just seemed to leave wide open. Thanks for all the time you take to help us beginners get started! I'd have already given up had it not been for the help I find here.

    Leave a comment:

  • replied
    Originally posted by spectre68 View Post
    These consist of one large texture broken down into smaller "strips".
    As a simple example, let's assume that the "trim" texture is 1024x1024 and contains eight different trim textures of equal height stacked in it.
    That would be the equivalent of 1024x128 for each piece of trim.

    So, if I had a building face that was in its entirety 1024x1024 units in total size, and the top ledge portion of the building that I wanted to trim was 128 units tall, then I would:

    - Apply the texture to those faces (set their Material ID appropriately to match the number in the Multi/Sub-Object Material)
    Note that these faces would have to be detached from the rest of the building so that I can apply a unique UVW coordinate to them...
    - Apply a Planar or Box UVMap modifier to that ledge object, set its properties to 1024x1024x1024 so that it is equivalent to the width and height of the ledge (ledge is 128 high and so is each trim strip).
    - On the UVMap modifier go into sub-object editing and move the UVW Gizmo up or down so that the appropriate portion of the texture is applied where I want it.
    Think of it like a big sheet of wallpaper that you are adjusting up or down until you get the proper pattern lined up where you want it -- moving the UVMap Gizmo does exactly this.

    Now in real mesh designs, I tend to create the entire model, then detach groups of faces where required, and UVMap those resulting objects as required. Then collapse, attach, weld and export.

    So in this example, I would probably detach the ledge front faces, bottom faces and top faces individually so that I could apply the desired Material ID and then set the UVMap coordinates as required on each piece.
    Sometimes you can get by with using Box mapping, and move it both up-down (Z) and closer-further (X or Y) in 3d space so that the ledge front (Z) and ledge top and bottom (X or Y) are mapped as required.

    This can be done with more than just trim textures. You can adjust the UVMap modifier to anything you want (within reason) to apply portions of textures to various mesh objects.
    I use this feature on things like Flag Stands and Vehicle Pads, where I will choose a texture that has a nice circular detail in the middle, then adjust the UVMap Gizmo accordingly in size/rotation/placement so that I get just the circle in the texture mapped to my mesh.

    The UVW Map Modifier Gizmo can be moved, rotated and scaled just like as if it were a mesh object. Many of the modifiers work this way.

    Hope you go that...

    Leave a comment:

  • replied
    Obviously both of you know far more about the workings of the engine than do I. Actually I'm just learning to do level design for UT2004, and have yet to put anything together. (Actually, I've put any further design on the back burner until I get proficient with 3DSMax as I've concluded that it's crucial to original level design.) Still, I can comment on what I feel is the way of "common sense". Common sense tells me that I wouldn't want a custom texture for every different mesh that I create for a couple of reasons.
    First, and the most important reason in my mind, is the file size issue. The files end up large enough the way it is, let alone if you were to create a custom texture per mesh. Any map with any kind of unique detail would have an enormous file size.
    Secondly, common sense also tells me that all those stock textures were meant to be used in their current form, without modification, otherwise you'd see texture files full of nothing but mesh skins and a few detail textures. Even as a beginner, the skinning method of flatten mapping / UVW Unwrap threw up flags to me telling me there had to be a way to skin the meshes with the textures in their stock form.
    I also, after reading DG's reply, opened several stock Epic created meshes in UnrealEd and looked into their properties to see how they had been textured. In ALL the meshes that I viewed they had used Sub/Multi Material and Material ID's to skin their meshes.
    Now I'm not saying that flatten mapping / UVW Unwrap doesn't have it's place. There are certain instances where flatten/unwrap would be ideal (and to me this would be mostly smallish, highly detailed, complicated meshes that would be used multiple times throughout the level, or meshes that would take several textures to get the desired results). At least in that scenario you would be making the custom textures worth the added file size. I just think that skinning a large simplistic mesh that would only be used once or twice throughout the level with the flatten/unwrap method would be plain silly. It would not justify the added file size. This is what lead me to question the flatten/unwrap method to begin with.
    But hey, everyone has their way of doing things. I'm not into arguing which is right and which is wrong, so I'll take the answers and comments posted here into consideration and use what I feel is my "common sense" to determine how to skin any given mesh. That being said, DG's approach more fits what my "common sense" was already telling me to begin with.

    SO.... I'm led to one last question on the subject, and once this one is answered I'll be set to skin my meshes the way I think is correct. OK, this concerns trim textures. These consist of one large texture broken down into smaller "strips". Each strip contains a different trim texture, but all strips are a part of the parent texture. My question is:
    How in the world do you tell the mesh exactly which horizontal "section" of the texture to use? I've not figured out how to move the texture once it is applied. I know I'm missing something simple here. I figure I'm missing a way to pan the material, but I'll leave it to someone who knows to point out to me where I'm missing it.

    Leave a comment:

  • replied
    I agree.

    It will be up to each game developer to make the decisions as to which way they wish to implement the game engine capabilities for their particular game design.
    Whether that be optimizing the render path by using medium resolution skins to get the best framerate possible, or provide higher visual quality with hi-res multi-texturing and hi-res skins at a cost of additional shader operations and fewer large textures per scene.
    Personally, I think a mixed approach to texture/skin/multi is the way to go, but requires considerably more pre-design work.

    I believe the complexity of the game design issues we state is also why more studios are moving towards hiring people for specific areas of the level designing process. It is becoming more involved and more difficult for one person to cover all of the bases from texture and material creation, to mesh modeling, to mapping -- and do them all equally well.

    I'm not knocking games like FEAR when I mentioned them in my previous post.
    I felt that even with the low-res texturing and skinning and the absence of Detail Textures, it was an awesome game that I found very absorbing.
    That one thing would be enough for me to give it a 9/10 instead of a 10/10 though.

    Unfortunately, not every gamer has hi-end gear, so on average I'm sure we are limited to P4-3GHz HT, 1GB RAM, 256MB T&L DX9 video. Which means that game developers will have to deliver UE3 content that is still playable on that platform.
    And the bad part of it is that over the next few years once multi-core processors and DX10 video cards become the standard rig hardware for gamers, UE4 will start to be used for game development and that level of hardware will again be no longer sufficient to run every feature at highest quality...

    We've really gone off-topic...

    (and I apologize for my long posts)

    Leave a comment:

  • replied
    i see your points, and they are all valid. i think our viewpoints illustrate the myriad of ways you can approach things in UE3 (or UE2), and how varied the development process can be. the only thing you REALLY need to know is how to adapt to changing methods and idealogies, if you can do that, you'll survive long in this industry.

    Leave a comment:

  • replied
    Originally posted by BIOS View Post
    so, like, there is my two cents.
    No problem, just a friendly discussion on the forums...

    I also do engine programming, and I am currently writing a new VS2005/DX9 3D graphics engine for my new Unreal Engine Licensee terrain tool, so I am quite familiar with what goes on under the hood.

    First off, in the average fps game you normally would not want to create the levels where every unique mesh used a unique skin, due to texture memory limits with the only "fix" being the use of lower resolution skins, which detracts from the visual quality -- unless every mesh you were creating in your map was only small to medium in size; you wouldn't want to create per-pixel lightmaps for every staticmesh, due to build time and texture memory limits, so many staticmeshes can still be lit per-vertex in the scene; nor would you want to have every single material used in-game be a complex shader with normal, specular, etc. as that requires additional texture memory and GPU power.

    This and some of the other things that we are mentioning in this thread are going to be part of the reason why community mappers are going to find UT2007 mapping considerably more work (and confusing).

    Originally posted by BIOS View Post
    each time you render a material on a mesh in UE3, you are in essence causing the engine to re-render the mesh.
    Kinda close...
    This is assuming that all textures applied to the mesh are in fact running shader effect materials.
    For example, in DX engines when you apply per-pixel specular highlights, the mesh in question will have to pass through a transform before the specular lighting calculations can be done.
    This is not the same as what most people might assume as "rendering the mesh to screen" -- this occurs in memory using a set of fast operations that calculate and store such things as the vertex transformations, texture coordinates, light direction, etc. It would also be pointless to return pixel color outputs for the faces that are not mapped to the specific sub-object material that is currently on its specific pass.
    So if you were to perform an in-game speed test between the same mesh model with one or three textures, the difference in rendering speed will be negligible if even noticeable (I've tried it and saw virtually no difference in framerate on a medium density scene).
    However, like UT2004/UE2.5, you should be careful to not overdo the number of texture in a Multi/Sub-Object mesh, preferably keeping the number between two and four textures.
    Also be aware that Pixel Shader 2.0 has additional optimization features over Pixel Shader 1.1, so newer shader operations can occur faster.

    Originally posted by BIOS View Post
    all of them have STRESSED using a traditional, single material skinning method.
    This I do not agree with (IMHO) and I feel that it can lead to a mistake in level design.

    Unlike simpler engines like UT2004/UE2.5, newer engines like UE3 require a considerably larger amount of pre-design and pre-thought on the construction end of things.
    With the nex-gen engines it is really easy to run out of system resources if a person attempts to run everything at maximum capabilities -- pixel shaders have limits, there is texture memory limits, etc., and (as I am sure you already know), you can quickly eat through all of these resources with complex shaders and many discrete textures (with normal maps and specular) and per-staticmesh lightmaps. Sure, you may luck out and get something that plays ok on the current cutting-edge systems, but most gamers aren't running that level of hardware.
    It is to the point where virtually every material and every mesh designed needs to be weighed as to its "importance" in the scene, and a decision as to the texturing (multi or skin, resolution, etc.), lighting (per-vertex, per-pixel), etc. has to be made in order to optimize the map for play.

    When a developer drops down to all medium resolution skins, IMHO the overall visual quality of the game suffers. Sure, Normal Maps and the cool new shaders help to some degree, but if you examine the actual "texture quality" of games like FEAR, RoboBlitz, etc., they IMHO don't come anywhere near what well designed UT2004 maps have with the use of 1024x1024 textures and Detail textures (sorry guys, not meaning to flame your games mentioned here, they are still great, just using them as examples of current nex-gen engines).
    Walk up to a wall in FEAR (even at highest quality which is what I run on my system) and it looks like Unreal 1 or DOOM 2 quality... (no offense intended).

    For retail games that are shipping everything on DVD they can be a bit more sloppy on this, but for downloadable custom content (ie. bonus or community maps) it is going to become a real concern as file size increases quickly.

    I do agree that anything smaller in the scene can (and should) be skinned.
    But any objects larger than the player model start to look crappy even with 1024x1024 skins, unless you are the equivalent of 20 feet or more away from it. Plus if the engine renders lower Mips for better performance on slower hardware, it only gets much worse looking.

    Originally posted by BIOS View Post
    using multi/sub obj materials on UE3 meshes is just apt to look bad
    I would have to see specific mesh examples of what you are referring to.
    I've not seen any Multi/Sub-Object textured UE3 meshes that looked bad or had these visual anomalies you mention.
    And in many cases, such as the facade in the screenshot I show below, the multi-texture method looks very good.

    Originally posted by BIOS View Post
    so, yes, it can be done, but if I were an art lead (which i'm not, but i've done assets for UE3 games) i would stray FAR AWAY from multi/sub materials unless my texel scale absolutely required it. (which, for the games i've worked on, wasn't necessary...128 pixels per foot is pretty standard and easy to do with one texture) large assets with tilable areas (buildlings, for instance) are a good exception to the rule since you'll be using a lot of them over the course of one level.
    It is a balance IMHO... going with all skins (assuming you want decent quality skins and not a bunch of 128x128 through 512x512 skins for everything), is going to eat up the texture memory on most video cards real fast. Many of the Epic UE3 assets that I have are using 1024x1024 skins with Normal map, which is a combined 3MB per pair.

    Originally posted by BIOS View Post
    oh, IMO the lack of detail textures in UE3 is more than made up for by specular maps, normal maps, emissive, specular power, etc....
    I disagree on this...
    Normal Maps in no way make up for Detail Textures.
    Normal Maps are fine for distance viewing, but are totally useless within five feet of the object.
    In UE3 you would have to get into Scalers and other messy stuff to approximate the proper effect.
    See the screenshot below.

    My apologies to Epic for showing one of their assets, hopefully they won't mind.

    Leave a comment:

  • replied
    as far as i know, each time you render a material on a mesh in UE3, you are in essence causing the engine to re-render the mesh. so, diffuse, spec and normal and you've already tripled your CPU hit. the memory footprint adds up QUICKLY. there is, or course, a balance to that, which needs to take into account material usage over the entire level, which could balance texture calls vs. mesh renders, and a host of other issues.

    i have worked on/am working on several UE3 titles (Mass Effect, Rogue Warrior, and a few unannounced titles) and all of them have STRESSED using a traditional, single material skinning method. i've discussed this at length with a couple creative directors, and followed the UDN emails and threads discussing this. multi/sub obj can be done, but it's good to save it for when you REALLY need it.

    besides, using multi/sub obj materials on UE3 meshes is just apt to look bad, because the seams between the materials will be that much harder to hide (unless you can work them into the design). add in UE3 automatically adding edges where UV seams are and you even highlight the problem. and don't get me started on how much a pain it can be to get multiple normal maps to work together fluently. (especially over seams....)

    so, yes, it can be done, but if I were an art lead (which i'm not, but i've done assets for UE3 games) i would stray FAR AWAY from multi/sub materials unless my texel scale absolutely required it. (which, for the games i've worked on, wasn't necessary...128 pixels per foot is pretty standard and easy to do with one texture) large assets with tilable areas (buildlings, for instance) are a good exception to the rule since you'll be using a lot of them over the course of one level.

    so, like, there is my two cents.

    oh, IMO the lack of detail textures in UE3 is more than made up for by specular maps, normal maps, emissive, specular power, etc....

    Leave a comment:

  • replied
    According to?
    I don't recall seeing anything regarding that on UDN 3.

    Many of the Epic UE3 meshes are using multiple materials.
    So if it is that bad, then why are they doing it?

    And DirectX itself on mesh functions (such as D3DXComputeTangentFrame etc.) also directly supports multiple textures/texture-coordinates per mesh.

    However, in both engines (UE2.x and UE3) you want to be careful how many textures you apply to one mesh as the renderer may render a mesh with multiple textures slower than a mesh with only one texture.

    Always skinning in UE3 can be a bad idea simply because of the number of unique textures that result from this.
    See this BUF thread post...
    Here is the full thread (long)...

    And due to no Detail Textures in UE3, it makes skinning look very poor IMHO, especially if the mesh detail (face count) is high, as that leaves less texture area per face, resulting in blocky blurry meshes.

    There are a number of differences in how the two engines render staticmeshes, so anyone moving across the engines must be aware of these. Including the differences of optimum face count per mesh, lighting, and culling.

    Leave a comment: