Importing Levels Into Hammer: Difference between revisions
mNo edit summary |
((Spelling)) |
||
| Line 7: | Line 7: | ||
==Importing Unsupported Types== | ==Importing Unsupported Types== | ||
At its simplest you can't, whether the level existed for UT or whether it was made in AutoCad. Unless the file format matches up to what's mentioned above, it's not getting into Hammer. Applying converters to it in order to make the data conform to the right [[VMF_documentation|format]] is the only way; however, you'll be lucky to find one. Level design is meant to be done in a level design program, and to top it off level | At its simplest you can't, whether the level existed for UT or whether it was made in AutoCad. Unless the file format matches up to what's mentioned above, it's not getting into Hammer. Applying converters to it in order to make the data conform to the right [[VMF_documentation|format]] is the only way; however, you'll be lucky to find one. Level design is meant to be done in a level design program, and to top it off level design programs don't cross apply between games easily. Expecting to get a level design from another program into Hammer is wishful thinking that may cause a lot of issues. The core part of the argument is listed below. | ||
===Pros=== | ===Pros=== | ||
| Line 15: | Line 15: | ||
===Cons=== | ===Cons=== | ||
*[[Invalid Brushes]] much more likely | *[[Invalid Brushes]] much more likely | ||
* | *Likelihood of skewed, or misaligned textures causing [[Vrad]] compiling issues | ||
*No access to all textures | *No access to all textures | ||
*File conversion once finished with a program | *File conversion once finished with a program | ||
*Inability to create/modify entities | *Inability to create/modify entities | ||
*Testing becomes a long and | *Testing becomes a long and arduous process in order to fix the design before conversion | ||
*Poor alignment (grid locations being integer powers of 2) | *Poor alignment (grid locations being integer powers of 2) | ||
*Inability to place/align models | *Inability to place/align models | ||
*Displacement terrain functions not | *Displacement terrain functions not available | ||
*No way to paint alpha | *No way to paint alpha | ||
*Complicated back and forth | *Complicated back and forth debugging process | ||
*Hammer | *Hammer necessary for essential level components so multiple development tools in use | ||
==Summary== | ==Summary== | ||
If the level's file type is supported go ahead and import it in to Hammer and use that base. If its not, its probably not worth the effort to change the file format and then to alter the information so it doesn't cause issues. Not to mention then adding in the data the other programs couldn't create would take longer and require more effort than | If the level's file type is supported go ahead and import it in to Hammer and use that base. If its not, its probably not worth the effort to change the file format and then to alter the information so it doesn't cause issues. Not to mention then adding in the data the other programs couldn't create would take longer and require more effort than redesigning from scratch in Hammer would of anyway. Its possible, but its not advised. Hammer is not a difficult tool to learn and most of its limitations are due to technological limits of the objects being created. | ||
[[Category:Level_Design]] | [[Category:Level_Design]] | ||
Revision as of 12:47, 13 January 2007
For help, see the VDC Editing Help and Wikipedia cleanup process. Also, remember to check for any notes left by the tagger at this article's talk page.
What's supported
Hammer has built in support for more than just its native .vmf file format. It can also open .rmf and .map, not surprising as they were the precursors to the current .vmf and have many similarities. All that's needed is to change the file type being browsed for by the open file dialog. A key factor to note is that while all the information may get loaded a lot of entity information will not mean much without a proper .fgd.
Importing Unsupported Types
At its simplest you can't, whether the level existed for UT or whether it was made in AutoCad. Unless the file format matches up to what's mentioned above, it's not getting into Hammer. Applying converters to it in order to make the data conform to the right format is the only way; however, you'll be lucky to find one. Level design is meant to be done in a level design program, and to top it off level design programs don't cross apply between games easily. Expecting to get a level design from another program into Hammer is wishful thinking that may cause a lot of issues. The core part of the argument is listed below.
Pros
- Possibly more familiar with program speeding up early stages of development
- Some design suites may allow creation of obscure geometric forms more readily
Cons
- Invalid Brushes much more likely
- Likelihood of skewed, or misaligned textures causing Vrad compiling issues
- No access to all textures
- File conversion once finished with a program
- Inability to create/modify entities
- Testing becomes a long and arduous process in order to fix the design before conversion
- Poor alignment (grid locations being integer powers of 2)
- Inability to place/align models
- Displacement terrain functions not available
- No way to paint alpha
- Complicated back and forth debugging process
- Hammer necessary for essential level components so multiple development tools in use
Summary
If the level's file type is supported go ahead and import it in to Hammer and use that base. If its not, its probably not worth the effort to change the file format and then to alter the information so it doesn't cause issues. Not to mention then adding in the data the other programs couldn't create would take longer and require more effort than redesigning from scratch in Hammer would of anyway. Its possible, but its not advised. Hammer is not a difficult tool to learn and most of its limitations are due to technological limits of the objects being created.