NFS Shift: Import/Export filter (Updated 27 Feburary 2010)
Posted: Thu Oct 15, 2009 8:43 am
NFS:Shift Import/Export filter in ZModeler v2.2.3.
This guide thread is for NFS Shift filter version 2.2.3 Build 259 and higher (supplied with ZModeler version 2.2.3 Build 970 and higher). ZModeler version is written in a caption of main window; filter version can be found in Options\Settings\Plugins\Manager window:
Prepare your Shift game
You need to unpack Shift\Pakfiles\*.bff files with QuickBMS tool
http://aluigi.org/papers.htm#quickbms
using a script for unpacking:
http://aluigi.org/papers/bms/nfsshift.bms
This tool have to be run from command prompt. You can search the web for batch file for unpacking, if you are not familiar with command prompt. I don't have the game and can't provide you any other solution.
By unpacking files, your Shift game folder will get lots of other folders with really huge amount of files. You can modify Shift game shortcut to add "-loose" argument. It will force game to use files as is, instead of reading them from packed BFF files. It will take much longer to load game or race, but that's the only option for modding the game at the moment.
Importing models.
The filter will deal with binary vehicle definition files *.VHF.BML even thought game contains edtiable text version of these files (*.VHF). Thes files are laid in unpacked vehicle\_car_name_ folder. This folder contains binary geometry objects (*.MEB files) and material definitions too (*.BMT files), so filter will load them. Unfortunally, this folder does not contain textures, so you need to adjust filter settings properly. Pick File\Import in ZModeler and change File Type to "NFS Shift (*.vhf.bml; *.meb) in drop list. Configuration dialog box for the filter will appear in a bottom:
You have to press button next to Unpacked Shift: and locate NFS:Shift game folder (folder with unpacked Shift files). Then you will see a folder location on the button (like on an image above). You need to specify folder only once.
Disable Bumpmap option will disable normal/bumpmap texture layer even thought according textures will be loaded and assigned to materials. It's preferable to tick this option ON.
Use Environment option will assign environment/reflection texture on materials, if they use it. Shift material definitions does not refer to specific environment texture, since real-time reflection maps are created. It's still preferable to use this option and load environment textures, since you might get improper shader configuration on export if you don't load environment textures. You can use the following texture as environment:
(Right-click and save target image on your drive in a folder with commonly used textures. For example, it could be "C:\My Documents\Textures").
Model Name is a name of base model. Usually, it matches the folder you are importing from, but it's not a must. For example, when you import cockpit model (bmw_135_cockpit.vhf.bml file, Model Name should be set to bmw_135.
You can leave it blank when importing model from game folder. Press Import button to import model. You will get an error in a log window flaming Failed to locate preferable environment texture "chrome.dds". Adjust filter preference in profile editor. Pick in main menu Options\Settings\Profile\Editor, Locate a Preferences\Filters\EA NFS Shift branch and change EnvMap key entry to NFSEnvMap.bmp:
Note, if you don't have these settings in profile editor, restart ZModeler.
Additionally, pick Services\Textures on a left side and add a path with your commonly used textures into a set of textures lookup paths:
In my case it's a C:\Documents\Dev\Textures folder - the folder with common textures and it contains NFSEnvMap.bmp texture too.
Restart ZModeler so changes take effect. Now you can import model again and you will get proper model loaded with no warnings or errors:
Scene model hierarchy and settings.
Scene root node matches model name: BMW_135. It's important that you give proper name to model on import, since it's used to truncate names of the rest of objects. For example, kit00_bonnet part actually was loaded from bmw_135_kit00_bonnet file. These part name are a grouping dummy node that contains dummies for "Level of Detail" (lod) models. In most of cases, there are two level of detail: high-quality and low-quality which have a _loda and _lodb indicators; some models could have very low detailed lod (_lodc). Finaly, under certain dummy nodes the phisical geometry mesh is located (kit00_bonnet_loda) which usually supplied with "damaged/deformed" version having _damage on a tail of name. Please, read Damaged Models paragraph below regarding damaged models;
Some objects that don't match common pattern "model name + part name" are imported as is and their name is given in square bracets. For example, you can see in a bottom of the list a part named [BMW_135I_MIRROR_L]. I don't know why it differs in name (BMW_135i), so I leave it as is. Object names in square braces are used as-is on export and not appended with model name in a begining.
Object Properties
NFS:Shift filter has it's own meaningful properties for an objects. It's important for cockpit models, while exterior models could be used as is. However, it's preferable to set Compatibility to NFS:Shift to see these properties. Pick in main menu Options\Settings\General and change Compatibility to NFS:Shift Compatibility:
Now, right-click on any object, pick "Properties...", expand Genral\External State\NFS:Shift Compatibility and you will see an options that you can toggle for parts:
Once again, these are meaninful for cockpit model only.
Flare Effects and Polygons ID
Flare Effects, as well as lighting-up headlights and taillight models are modelled as a single objects: one object for flare models, one object for the lights. It is remarkable, that you can smash fragments of lights ingame and certain flares should not light-up, as well as "shining" model of according head- or back-light should not be rendered. That is why, you have to assign proper ID on polygons of Flare effects and Light models. Each ID is meaningful for game engine and it will decide whether certain polygon should be rendered or not. Highlight a rear flare effect object (lightglows_r_loda), right-click and pick "Show Isolated". You will see it isolated from the rest of scene:
You see that all flares are the only object. Switch it to polygons level, highlight any flare quad model, right-click on it and pick "Properties..." Notice, that General\External State\ID value could be different for certain polygons - these are distinguishing ID for game engine.
These values and their meanings are:
1: Front Left Headlight
2: Front Right Headlight
3: Rear Left BrakeLight (bright, lights up when you hit brakes)
4: Rear Right BrakeLight (bright, lights up when you hit brakes)
5: Rear Left TailLight (not bright, lights constanly, when you drive in dusk)
6: Rear Right TailLight (not bright, lights constanly, when you drive in dusk)
7: Rear Left TailLight (same as 5, but very bright)
8: Rear Right TailLight (same as 6, but very bright)
9: Rear Left ReverseLight (bright reverse light)
10: Rear Right ReverseLight (bright reverse light)
11: Unknown
12: Middle/Center BrakeLight (bright, lights up when you hit brakes)
I have to notice here, that you should use these ID values on headlight and backlight models too, so game engine will brighten textures on according polygons when light effect is needed. In cooperation with flare effect it looks very realistic, while missing any of them will suffer realism.
Important note on Flare models: Flare model must use only QUAD polygons. The game will rotate this quad to the viewer. I can't say it works perfectly on exported model, but that's the best I could achieve so far.
Damaged Models
You can supply any visual part with Damaged version, but the game will use them where possible only. The most important thing on Damaged version is that you can deform only vertices of this mesh. Literally, you can only move them, but you can't modify geometry itself. To create proper damaged version, you should copy original model and move vertices as needed. Note, you can't even use Knife tools to make sharp edges, or weld or delete unused areas. I can't say it's quite easy to make accurate deformed model, but it's a question of practive.
Remark: Polygons of deformed/damaged part should have the same ID settings as original model, or you might get corrupt deformed model.
Wheel Tyre model
You might notice skeleton and some bones under each tire model. The tire model in Shift game does not spin when you drive, instead only uv-mapping rotates on model geometry. At the same time, bones could move a little to simulate tire deformation when you brake or make a hard turn. Unfortunally, UV rotation is not properly exported, so even thought proper bone-affected tyre model could be exported, it's appearence in game will be pretty odd. That is why you should backup original tyre model files and restore them after export. You should not use ZModeler-generated tyre models, but you can improve original tyres by changing textures if you like to.
Materials and Textures settings
NFS:Shift ending is shader-based and requires certain shader for any geometry before rendering; each shader requires explisit textures settings and quantity too. I strongly recommend to use original material and textures settings to get proper results. Even if certain material has several disabled texture layers, they are still meaningful for exporter.
Material name contains shader name to use and, if it differs, Shading Techinique in braces. For example, material bmw_135_rim wheels (Wheels_Opaque) will use shader wheels with technique Wheels_Opaque (no transparency), while material bmw_135_rim_blur Wheels will use the same shader Wheels with Technique Wheels. Shader name is written after material name and it's not case sencitive (e.g. "wheels" is the same as "Wheels"), since it's just a file name. Technique is written in braces and it's case sencitive.
There are lot of settings and Techniques combinations and they require proper texture settings. I can't describe all of them here, so I just supply Model Example Packs. Shader vehicle_basic with technique VehicleBasic is the most commonly used shader and it could suit your needs in most of cases.
You are allowed to specify additional settings for material in User-Defined options and in most of cases it's important to specify proper settings there. The list of keywords (and according values if required) follows:
VINYLS: Object support vinyls and require second UV channel for vinyls unwrap,
COCKPIT: Material is used in cockpit view: vinyls will be flipped if available,
SCRATCH: Scratches is supported by material. Usually appears with Bodywork shader.
CRACK: Cracks could appear on demaged models. Usually appears with Glass shader.
BLUR: Material has blurred textures to use on high speed ingame. Usually appears with Wheel shader.
DUST: Dust could appear on material ingame. Usually appears with Wheel shader.
LIGHT: A Condition-Light texture layer is available in material. This texture is applied as AddSmooth and requires game enging to decide whether it will shine or not. Usually appears with Wheel shader (disk glow effect) and vehicles_basic (VehicleBasic_AlphaTest) shader (for head/tail-light models).
BROKEN: Material has a texture with alpha-channel that will be enabled when model become deformed. Usually appears with (VehicleBasic_AlphaTest) shader for tail-light models.
ALCANTARA: I can't say it has certain effect in cockpit materials, but it appears on some of them.
Exporting Model
When you pick File\Export and specify File Type NFS:Shift (*.vhf.bml; *.meb), you can export entire scene (vehicle). The filter will generate all mesh files (MEB) and material files (MTX). Materials are exported in text format, so you can adjust them manually if required. It's important to specify model name on export, so files will be generated with proper names. For example, when exporting BMW_135 exterior model (bmw_135.vhf.bml file) or it's cockpit model to (bmw_135_cockpit.vhf.bml file), use bmw_135 as a model name. Scene root should contain bmw_135 dummy node in first case (vehicle) and cockpit dummy node in a second case. Note, if you export into new file (without overwrite), you should specify double extension as is: ".vhf.bml", since just ".bml" is not enough.
When you export entire vehicle model, you can add small comment, thumbnail image and (registered users only) could lock model. Locking will affect .vhf.bml file and all mesh geometry files (meb) that will be exported. Locked models can not be imported into ZModeler, so you should not lock your files unless you have a backup copy in .Z3D format!.
In most of cases, exported model is ready to use ingame (except tyre models as stated above), so you can launch the game and test results.
Example Model Pack
Since scene assembly and materials settings are quite complex in NFS:Shift, I supply Example Models Pack, that could be used as a reference material. It could be downloaded here:
http://www.zmodeler2.com/files/example/nfs/shift/ShiftModelsPack.rar
This guide thread is for NFS Shift filter version 2.2.3 Build 259 and higher (supplied with ZModeler version 2.2.3 Build 970 and higher). ZModeler version is written in a caption of main window; filter version can be found in Options\Settings\Plugins\Manager window:
Prepare your Shift game
You need to unpack Shift\Pakfiles\*.bff files with QuickBMS tool
http://aluigi.org/papers.htm#quickbms
using a script for unpacking:
http://aluigi.org/papers/bms/nfsshift.bms
This tool have to be run from command prompt. You can search the web for batch file for unpacking, if you are not familiar with command prompt. I don't have the game and can't provide you any other solution.
By unpacking files, your Shift game folder will get lots of other folders with really huge amount of files. You can modify Shift game shortcut to add "-loose" argument. It will force game to use files as is, instead of reading them from packed BFF files. It will take much longer to load game or race, but that's the only option for modding the game at the moment.
Importing models.
The filter will deal with binary vehicle definition files *.VHF.BML even thought game contains edtiable text version of these files (*.VHF). Thes files are laid in unpacked vehicle\_car_name_ folder. This folder contains binary geometry objects (*.MEB files) and material definitions too (*.BMT files), so filter will load them. Unfortunally, this folder does not contain textures, so you need to adjust filter settings properly. Pick File\Import in ZModeler and change File Type to "NFS Shift (*.vhf.bml; *.meb) in drop list. Configuration dialog box for the filter will appear in a bottom:
You have to press button next to Unpacked Shift: and locate NFS:Shift game folder (folder with unpacked Shift files). Then you will see a folder location on the button (like on an image above). You need to specify folder only once.
Disable Bumpmap option will disable normal/bumpmap texture layer even thought according textures will be loaded and assigned to materials. It's preferable to tick this option ON.
Use Environment option will assign environment/reflection texture on materials, if they use it. Shift material definitions does not refer to specific environment texture, since real-time reflection maps are created. It's still preferable to use this option and load environment textures, since you might get improper shader configuration on export if you don't load environment textures. You can use the following texture as environment:
(Right-click and save target image on your drive in a folder with commonly used textures. For example, it could be "C:\My Documents\Textures").
Model Name is a name of base model. Usually, it matches the folder you are importing from, but it's not a must. For example, when you import cockpit model (bmw_135_cockpit.vhf.bml file, Model Name should be set to bmw_135.
You can leave it blank when importing model from game folder. Press Import button to import model. You will get an error in a log window flaming Failed to locate preferable environment texture "chrome.dds". Adjust filter preference in profile editor. Pick in main menu Options\Settings\Profile\Editor, Locate a Preferences\Filters\EA NFS Shift branch and change EnvMap key entry to NFSEnvMap.bmp:
Note, if you don't have these settings in profile editor, restart ZModeler.
Additionally, pick Services\Textures on a left side and add a path with your commonly used textures into a set of textures lookup paths:
In my case it's a C:\Documents\Dev\Textures folder - the folder with common textures and it contains NFSEnvMap.bmp texture too.
Restart ZModeler so changes take effect. Now you can import model again and you will get proper model loaded with no warnings or errors:
Scene model hierarchy and settings.
Scene root node matches model name: BMW_135. It's important that you give proper name to model on import, since it's used to truncate names of the rest of objects. For example, kit00_bonnet part actually was loaded from bmw_135_kit00_bonnet file. These part name are a grouping dummy node that contains dummies for "Level of Detail" (lod) models. In most of cases, there are two level of detail: high-quality and low-quality which have a _loda and _lodb indicators; some models could have very low detailed lod (_lodc). Finaly, under certain dummy nodes the phisical geometry mesh is located (kit00_bonnet_loda) which usually supplied with "damaged/deformed" version having _damage on a tail of name. Please, read Damaged Models paragraph below regarding damaged models;
Some objects that don't match common pattern "model name + part name" are imported as is and their name is given in square bracets. For example, you can see in a bottom of the list a part named [BMW_135I_MIRROR_L]. I don't know why it differs in name (BMW_135i), so I leave it as is. Object names in square braces are used as-is on export and not appended with model name in a begining.
Object Properties
NFS:Shift filter has it's own meaningful properties for an objects. It's important for cockpit models, while exterior models could be used as is. However, it's preferable to set Compatibility to NFS:Shift to see these properties. Pick in main menu Options\Settings\General and change Compatibility to NFS:Shift Compatibility:
Now, right-click on any object, pick "Properties...", expand Genral\External State\NFS:Shift Compatibility and you will see an options that you can toggle for parts:
Once again, these are meaninful for cockpit model only.
Flare Effects and Polygons ID
Flare Effects, as well as lighting-up headlights and taillight models are modelled as a single objects: one object for flare models, one object for the lights. It is remarkable, that you can smash fragments of lights ingame and certain flares should not light-up, as well as "shining" model of according head- or back-light should not be rendered. That is why, you have to assign proper ID on polygons of Flare effects and Light models. Each ID is meaningful for game engine and it will decide whether certain polygon should be rendered or not. Highlight a rear flare effect object (lightglows_r_loda), right-click and pick "Show Isolated". You will see it isolated from the rest of scene:
You see that all flares are the only object. Switch it to polygons level, highlight any flare quad model, right-click on it and pick "Properties..." Notice, that General\External State\ID value could be different for certain polygons - these are distinguishing ID for game engine.
These values and their meanings are:
1: Front Left Headlight
2: Front Right Headlight
3: Rear Left BrakeLight (bright, lights up when you hit brakes)
4: Rear Right BrakeLight (bright, lights up when you hit brakes)
5: Rear Left TailLight (not bright, lights constanly, when you drive in dusk)
6: Rear Right TailLight (not bright, lights constanly, when you drive in dusk)
7: Rear Left TailLight (same as 5, but very bright)
8: Rear Right TailLight (same as 6, but very bright)
9: Rear Left ReverseLight (bright reverse light)
10: Rear Right ReverseLight (bright reverse light)
11: Unknown
12: Middle/Center BrakeLight (bright, lights up when you hit brakes)
I have to notice here, that you should use these ID values on headlight and backlight models too, so game engine will brighten textures on according polygons when light effect is needed. In cooperation with flare effect it looks very realistic, while missing any of them will suffer realism.
Important note on Flare models: Flare model must use only QUAD polygons. The game will rotate this quad to the viewer. I can't say it works perfectly on exported model, but that's the best I could achieve so far.
Damaged Models
You can supply any visual part with Damaged version, but the game will use them where possible only. The most important thing on Damaged version is that you can deform only vertices of this mesh. Literally, you can only move them, but you can't modify geometry itself. To create proper damaged version, you should copy original model and move vertices as needed. Note, you can't even use Knife tools to make sharp edges, or weld or delete unused areas. I can't say it's quite easy to make accurate deformed model, but it's a question of practive.
Remark: Polygons of deformed/damaged part should have the same ID settings as original model, or you might get corrupt deformed model.
Wheel Tyre model
You might notice skeleton and some bones under each tire model. The tire model in Shift game does not spin when you drive, instead only uv-mapping rotates on model geometry. At the same time, bones could move a little to simulate tire deformation when you brake or make a hard turn. Unfortunally, UV rotation is not properly exported, so even thought proper bone-affected tyre model could be exported, it's appearence in game will be pretty odd. That is why you should backup original tyre model files and restore them after export. You should not use ZModeler-generated tyre models, but you can improve original tyres by changing textures if you like to.
Materials and Textures settings
NFS:Shift ending is shader-based and requires certain shader for any geometry before rendering; each shader requires explisit textures settings and quantity too. I strongly recommend to use original material and textures settings to get proper results. Even if certain material has several disabled texture layers, they are still meaningful for exporter.
Material name contains shader name to use and, if it differs, Shading Techinique in braces. For example, material bmw_135_rim wheels (Wheels_Opaque) will use shader wheels with technique Wheels_Opaque (no transparency), while material bmw_135_rim_blur Wheels will use the same shader Wheels with Technique Wheels. Shader name is written after material name and it's not case sencitive (e.g. "wheels" is the same as "Wheels"), since it's just a file name. Technique is written in braces and it's case sencitive.
There are lot of settings and Techniques combinations and they require proper texture settings. I can't describe all of them here, so I just supply Model Example Packs. Shader vehicle_basic with technique VehicleBasic is the most commonly used shader and it could suit your needs in most of cases.
You are allowed to specify additional settings for material in User-Defined options and in most of cases it's important to specify proper settings there. The list of keywords (and according values if required) follows:
VINYLS: Object support vinyls and require second UV channel for vinyls unwrap,
COCKPIT: Material is used in cockpit view: vinyls will be flipped if available,
SCRATCH: Scratches is supported by material. Usually appears with Bodywork shader.
CRACK: Cracks could appear on demaged models. Usually appears with Glass shader.
BLUR: Material has blurred textures to use on high speed ingame. Usually appears with Wheel shader.
DUST: Dust could appear on material ingame. Usually appears with Wheel shader.
LIGHT: A Condition-Light texture layer is available in material. This texture is applied as AddSmooth and requires game enging to decide whether it will shine or not. Usually appears with Wheel shader (disk glow effect) and vehicles_basic (VehicleBasic_AlphaTest) shader (for head/tail-light models).
BROKEN: Material has a texture with alpha-channel that will be enabled when model become deformed. Usually appears with (VehicleBasic_AlphaTest) shader for tail-light models.
ALCANTARA: I can't say it has certain effect in cockpit materials, but it appears on some of them.
Exporting Model
When you pick File\Export and specify File Type NFS:Shift (*.vhf.bml; *.meb), you can export entire scene (vehicle). The filter will generate all mesh files (MEB) and material files (MTX). Materials are exported in text format, so you can adjust them manually if required. It's important to specify model name on export, so files will be generated with proper names. For example, when exporting BMW_135 exterior model (bmw_135.vhf.bml file) or it's cockpit model to (bmw_135_cockpit.vhf.bml file), use bmw_135 as a model name. Scene root should contain bmw_135 dummy node in first case (vehicle) and cockpit dummy node in a second case. Note, if you export into new file (without overwrite), you should specify double extension as is: ".vhf.bml", since just ".bml" is not enough.
When you export entire vehicle model, you can add small comment, thumbnail image and (registered users only) could lock model. Locking will affect .vhf.bml file and all mesh geometry files (meb) that will be exported. Locked models can not be imported into ZModeler, so you should not lock your files unless you have a backup copy in .Z3D format!.
In most of cases, exported model is ready to use ingame (except tyre models as stated above), so you can launch the game and test results.
Example Model Pack
Since scene assembly and materials settings are quite complex in NFS:Shift, I supply Example Models Pack, that could be used as a reference material. It could be downloaded here:
http://www.zmodeler2.com/files/example/nfs/shift/ShiftModelsPack.rar