| OPT Creation From Model to OPT After the previous you should have a nicely textured model in OPTech which will be something attractive for the Tech Library in XWA, but that is all until you define the workings of the OPT. Hardpoints The Hardpoints define the locations of the ships weaponry, any docking points, and the location of the hangar. Weapon Hardpoint types I have used consist of: As Starships can be given an entirely turbolaser based armament, since if they are given a disable order then those hardpoints will fire ion cannon bolts, I have never got into the habit of using TurboIonCannon (which would be main ion cannon armament on smaller starships and secondary on capital ships) or SuperIonCannon (which would be the main ion cannon armament on capital ships). With weapons something that has been noted is that the TG Starships seem to have weapons-hardpoints only defined for one side, which implies very strongly that the weapons are mirrored by XWA (or all the TG starships would only fire to one side). This is borne out by the fact that I have noticed that with my starships, where I have the hardpoints defined on both sides as in some ways it is easier to see how you have your guns distributed, that two turbolaser bolts get fired almost together. XWA does not seem fussy though about if you define them on both sides or just on one side so do whichever is most convenient. It can take quite a while to add a large number of guns to a starship and you should try to imagine how you would attack this ship and place the starships weapons accordingly. Put put more weapons around the bridge or the hangar entrances, for example, and try to avoid any blind spots where no weapons will bear. With fighters this is a lot simpler as they have a few clearly defined guns and so the location has been worked out already and the number of weapons is much lower. Something to remember though is that an exterior fighter OPT does not need the hardpoints defined as XWA takes this information (along with the explosion fragmentation) from the base OPT. However if you have added the hardpoints then it doesn't matter as it doesn't actually do any harm, just doesn't do any good. Having done the weapons it may be time to add the hangar hardpoints if needed. There are three types of hardpoint used for this, InsideHangar, OutsideHangar, and AIHangar. Your main hangar should have all three types while any other hangars should just have the AIHangar hardpoint (thanks go to Darksaber for this information). The flight path ships leaving the main hangar follow seems to be defined by the line from the InsideHangar hardpoint through the OutsideHangar hardpoint so you should bear this in mind if the ships design means there is a chance the fighters could ram their own ship (like on a ISD where the hangar is inside an underside well). This is a simple test mission I created
when the problem with ships landing on the XWAU MC-40 was
reported, it has 6 MC-40 Light Cruisers surrounding a
container field (above, below, left, right, ahead, and
behind) and a group of fighters launching from each
starship. The fighters attack and destroy the containers
and then return to the starships from this central
position, thus testing that fighters can find their
mothership hangar when approaching from each of those
angles. There are three settings that concern us, the other values of X/Y/Z centre/span/minimum/maximum and the location of where the targeting indicator will be shown to the player when that component is targeted are automatically calculated. The first setting is the mesh type. These are reasonably self-explanatory and by changing the mesh type you not only alter the label displayed to the player but you affect the characteristics of the mesh. If a mesh is set to be an engine then it will create engine wash, if it is set to be a shield generator then if all shield generators are destroyed the ships shields will drop or not regenerate, etc. Other mesh types will cause the mesh to rotate back and forth which is good if that is what you intended and not so good if it was not. The second setting is the explosion type. For fighters this defines how the mesh will behave when the fighter is shot down, whether it will remain attached to the fuselage or whether it will split off and explode separately. For starships this defines whether a mesh can be individually destroyed so that thing such as weapons or shield generators can be stripped from the hull. One thing to note is that not all mesh types are individually destroyable, with my first version of the MC-80a I wanted to have some containers in the hangar which could be blown up as an Easter-egg (hidden bonus feature) but I found that this would not work unless I gave them a mesh type which was incorrect and misleading. The third setting is target ID. When a player targets a starship and wants to locate a particular component in the target list it would be very awkward for them if they had to step through a few dozen meshes. By giving multiple meshes the same target ID you can group them together into a single entry in the target list and also hide better how the model was constructed (for example by having a single "hull" entry rather than one for each section of hull). As mentioned before by using level of detail settings you can have details that are not visible at longer distances vanish or be replaced by a lower detail version, and thus reduce the load on the players PC and hopefully avoid any jerkiness. There are four options for this: No Vanish. This is the simplest option as it is the default setting where a mesh is always visible and is never replaced by a simpler version. Vanish. This is the next simplest option where a mesh, normally a relatively small detail, simply vanishes at a set distance. Select the mesh and then replace 1000 (which means never vanish) with the value you require in the cloaking distance (km) box. Vanish and Replace. The next most complicated option is where a mesh, normally a part of the model that is larger enough to always be visible such as the main hull, vanishes at a set distance and is replaced by a simpler version that never vanishes. As stated in the OPTech helpfile you should first select the mesh you want to be the lower detail version and then holding down CTRL click on the mesh you want this to replace at the longer distance before clicking the Assign LOD button to assign it. The lower detail mesh will vanish from the High Level view but can be seen and edited if you switch to Low Level view. At some point you should select the mesh that will be vanishing and enter the required value in the cloaking distance (km) box. Vanish and Replace and Vanish. This is marginally the most complicated option as you will need to do the above to assign a lower detail version and define at what distance that replaces the higher detail version but you will also need to switch to the Low Level view and select the lower detail version of the mesh before changing the value in its cloaking distance (km) box from 1000 to something else. This option would be used for details which are large enough that they would be visible from quite a distance, and so need a low detail version rather than just vanishing, but which can be set to vanish completely at long range. You may wish to use deliberately low values to check that the meshes are vanishing and being replaced in the manner you want before changing the values to the proper ones. Remember to use settings appropriate to the size of the mesh and to the difference in the detail of the higher and lower detail meshes. Illustration of
Low Detail and Full Detail model. Zeroing Software vectors versus allowing blurring If Calculate..Software Vectors (resolution) is used then this zeros the software vectors and prevents the texture from being blurred as the distance between it and the player viewpoint increases. This can sometimes look better and can sometimes look worse. A complex texture (such as a starship hull) can look rather grainy at longer distances if it is not blurred but the blurring in XWA is not perfect. You can have noticeable joins between areas of texture being blurred and those not being blurred and you can also have textures being blurred when they should not be. This second problem is particularly noticeable with cockpit OPTs as the pilots eyes would need to be pretty bad for anything within the cockpit to blur from some angles rather than being razor sharp at all times. I would use Calculate..Software Vectors (resolution) on all cockpit OPTs to prevent inappropriate blurring and on most fighters as sometimes the blurring can cause a problem where spots the colour of the FG stripe can appear across the texture which, since it was originally a red stripe causing red dots, I called measling. This seems to be a problem with XWA choosing the wrong colour from the texture palette and so was probably more the fault of the art software anyway in not arranging the palette more logically. With starships though I would try it without having zeroed the software vector and then try it with zeroing to see which is best. Engine Glows If you have a ship with engines then you will probably want to add engine glows to represent the exhaust from these and this is reasonably simple. Select the engine mesh and then switch to face mode so you can select a face on the back of the engine which either goes across the middle or is one of the faces to either side. Next click on the engine glow button and then Add EG and Set to Face. This will create an engine glow and move it so that it's Y position is on the rear of the engine, if needed alter the X and Z values so that it is in the position you want horizontally and vertically. Now you can alter the size of the engine glow. Bear in mind that XWA can show engine glows through the side of nozzles if the rears of the engine is recessed and so you do not want to make the engine glow too large. It should comfortably cover the centre of the nozzle without overfilling the "bowl" of the nozzle. Also consider what short of ship you are making when deciding on the length of the engine glow as the faster the ship the longer this glow might be in proportion to its width and height. Most starships look good with an engine glow length of 2 but if it is a fast ship with high-power thrusters then the default setting of 3 may be more fitting and if it is a fat freighter then a value lower than 2 might be better. You can alter the colour of the engine glow as well. I normally do this by clicking on the coloured square which brings up the standard Windows colour dialog box and then either select one of the default colours or, more often, create a custom colour. You could also enter the colour values directly into the inner/outer R/G/B boxes. The inner colour should be the lighter "hotter" colour and the other colour the darker "cooler" colour that the glow fades to. Remember that to cover the width of a rectangular nozzle you may need to use several glows side by side. Remember also that with fighters a good effect can be achieved by using a larger more transparent glow to create a halo and a smaller denser glow for the actual exhaust. This is something that I haven't done much of, given my propensity towards starships, but if you look at the XWAU fighters you will see what I mean. Finally if you do not wish the engine glow to be pointing directly rearward then you can change this by fiddling about with the values in the lower set of nine boxes. This can be useful if you have a ship like the Mobquet Transport where some of the engine nozzles point in a strange direction. Transparency Transparency is usually used on Exterior fighter OPTs for their canopies but can be used for other purposes. The transparency editor can be accessed by clicking on the texture button (Y-wing on maroon background) and then the button with the blue fading to clear. Click on the area of the texture which you wish to become transparent and then select the colour value this creates and with luck the area you want transparent will fill with pink to show the area selected without overflowing or missing any pixels out. If the pink overflows then either adjust the colour tolerance downwards or click the remove selected button and then select a colour closer to the middle of the range of colours that you want rendered transparent. If the pink misses out pixels that you want to be rendered transparent then either adjust the colour tolerance upwards or select one of the pixels that have been missed out so that this colour is also marked. Once you have the area marked out then you can adjust the opacity value so that the area is transparent enough in XWA to be seen through to the extent you wish and is not so transparent as for it to appear that there is no window material there. Remember that a texture cannot be both illuminated and transparent, it is one or the other. Self-illumination This can be used to select part of a texture so that windows or lights on a texture can be lit or to select the entire textures so that an area such as the rear of an engine or inside of a hangar (where there are lights) is lit. In the first case you should be careful to ensure that
the area you wish to be illuminated is distinct from the
surrounding textures and you may find it better to makes
this a single flat colour. When I did my very early OPTs
how to make a texture self-illuminated had not been
discovered and I made the windows on the textures with a
variation of brightness across them (simple gradient from
darker to lighter) and this proved difficult to make
self-illuminated without this leaking to other parts of
the texture. In the second case you will need to select enough
colours and with a wide enough colour tolerance that the
entire texture turns pink to show the area selected is
the whole of the texture. This is simple enough in theory
but although nobody else seems to have any trouble it can
cause me problems. Remember that a texture cannot be both illuminated and transparent, it is one or the other. You may find that some OPTs are easier to create or problems can be avoided if you split the process across more than one OPTech project which are then combined together at some stage. Reasons I can think of to do this include if you have needed to make a correction to a mesh or meshes and want to bring in the corrected version (you could also import a DXF or OBJ for this purpose), if there are meshes which would work correctly with Tri2Quad and meshes which would not and you want to convert those that would work into quadrangles (useful for texturing in OPTech as the list of faces becomes shorter), if you want to have different meshes in different OPTech projects so you can calculate their vertex normals separately, or if you simply want to do different parts separately either because the model is a complex one that slows OPTech down too much or if you have decided to work on texturing the LOD separately and then combine it in. To Import an OPZ I think you will need to leave it in its own OPTech folder as in the past when I have copied the OPZ to be imported into the same folder as the one it was to be imported into OPTech has given me a error message. You will also need to make sure that all textures used by the OPZ being imported exist in the main project folder. One problem that may be encountered with combining OPZs is that this can cause duplicates in the list of textures for transparency or self-illumination as OPTech seems to list it once for each OPZ imported (I encountered this when importing the OPZ with the low-detail version of the Modified Action Transport and found that all the textures that were common to both high and low detail versions were listed twice, once for on high-detail and once for on low-detail). Section Links: OPTech |