high+resolution+skin


 * João “Muas” Martins**


 * Part I -Making High Resolution Fighters for European Air War.**

This tutorial is intended to assist with the process of converting single 3dz aircraft to multiple 3dz aircraft with multiple pcx files, and may also be of some use if thinking about converting twin 3dz aircraft to hi-res. It represents my ideas on how I went about creating the Hi-res P-51D using Moggy’s paste on technique. There may be other better ways, but since this is un-chartered territory I thought write down a few pointers to help people out. If you look at the files for my P-51D in conjunction with this document, you should be able to see what I’ve done, how, and why. Please read through it all before making a start on your own aircraft! It may seem long and confusing at first, but I’ve added in every issue and detail that I could think of, in order to make you aware of what is involved, and what to watch out for.

What you will need. A good graphics program such as Paint Shop Pro 7, 3DZ Studio http://www.sandbagger.uk.com/Gurney/3DZStudio.zip and Converter http://www.sandbagger.uk.com/crashinjack/converter18a.zip Some basic knowledge of 3dz’s – I recommended Cord’s 3DZ CAM tutorial at http://www.sandbagger.uk.com/CORD/frames.html The CDFRW extractor – also available at Cord’s site. SaggingB’s tpc to pcx Batchfile tools – available at his page http://www.sandbagger.uk.com/RAFDum/PicPacFull.zip The 3DZ and PCX files you intend to convert. The Picpac converter – every skinner will have this anyway :) Some good reference pictures for the skinning detail. A lot of spare time.

Palette problems It has come to my attention that you may experience problems if you use customized palettes in the paste on 3dz’s. I have used modified palettes on the HR P-51D with complete success, however Steve Day and Geo have had hassles with the modified palettes not displaying correctly on the paste on 3dz’s, but only in D3D – in glide they appear fine. Keep this in mind when you are thinking of an aircraft you would like to skin. I can only suggest that you stick to the default palettes for your slot.

Glide or D3D? Note that there are differences in the 3dz joins when viewed in Glide compared to D3D. The pixel alignment may be slightly out if you swap from one 3d mode to another. If you make a 3dz set that looks perfect in D3D, when it is viewed in Glide it will not join up the same, and vice-versa. This is a real bitch, but I can see no other option but to make your model specifically for Glide OR D3D. Once you have your preferred model made, you can then adjust the PCX files to suit the other mode if you want to. In your readme.txt, be sure to specify which display mode your model is optimised for.

Also, Glide is a lot more sensitive to rendering sequence problems. You can have a model looking perfect in D3D, but if a Glide user loads it up they might see a lot of show through elements and problems that you may not have been aware of. However if your model looks good in Glide, it will also look good in D3D (with the exception of the palette thing above!).

Getting started Firstly, pick the aircraft that you want to convert. Your starting point should use the best P*F.3dz shape that you can find. You will be totally re-mapping the textures, so how they look isn’t that important – the main thing is to have a good wire frame with no Rendering Sequence problems (you will add them later on – heh, heh!). Things like added antennae, sliding canopies, air intakes etc. are important. Non-mirror patches probably won’t be needed if you can get the pcx files right. You can add all these things later, but it’s easier to use someone else’s work as your base, and blank out what you don’t need as you go.

Have a look at the wire frame of the F.3dz in 3DZ Studio, and start deciding how to split up the model. Look for defined lines that bisect the entire wire frame, because these are ideal places to make a split. There are six 3dz’s that we can use for this aircraft, but you may not have to use all of them depending on how you split up your pcx files. I went all the way and split the Mustang into six 3dz’s – Left wing, Right wing, Front fuselage, Rear fuselage + tail LEFT, Rear fuselage + tail RIGHT, and Cockpit. If you can fit the cockpit onto the front fuselage 3dz, it should eliminate the RS problems that bug the mustang in that area.

Obtain all the 3dz and pcx files you will need to edit. If they aren’t included in the zip of the aircraft you are editing, you may be able to extract them from the 3D.CDF file in your EAW folder using the CDFRW tool. Use SagginB’s batchfiles to convert them to PCX.

Making the new PCX files. Now that you have a rough idea, start making some rough PCX files and see just what is feasible, and at what resolution. Start with a nice, blank skin that has minimal markings on it, so that you can use this as a base for other skins later on. Take your standard 256 x 256 pcx file and resize it to 512 x 512. Ideally, you should now start drawing in the extra detail, but that can be done later. Create some new 256 x 256 images, and start selecting, copying and pasting from the 512 to the 256’s in a way that will suit your aims. The wings may have to be resized a bit to fit them onto a 256 x 256 pcx – make sure you write down the resizing factor for later on. Most other things can be pasted straight on. Try to minimize wasted space as much as you can.

One important thing to remember, is that all textures that require transparency information MUST be on the PTEX.pcx, otherwise they cannot access the Ptra.pcx.

You may have to make changes to your plan if you can’t fit all the textures into the required pcx’s - This may require more 3dz’s, less wasted space, or a change in resolution. Try to keep the resolution the same for all different parts of the aircraft, as it makes it easier to eliminate “seams” where 3dz’s join.

Note that it is easier to do your fuselage skinning on the 512x512 (if the fuselage is split into two pcx’s), and then carefully copy and paste the required area to the 256x256’s. By doing things this way, you are able to get the fuselage markings to line up perfectly every time. Create one 512x512 fuselage texture for the right hand side, and one for the left hand side of the aircraft.

Splitting up the 3dz. Load up your starting PF.3dz in 3DZ Studio. Click through each element of the 3dz, and write down a list of - 1. The element’s number 2. Where the element will be located on the new 3dz’s 3. A brief description of what the element is, and where it is located.

Do this for all of the elements in the 3dz. This is a time consuming job, but it helps you familiarize yourself with the model, and provides invaluable reference material for later on. A typical line might read something like - E83/0 Front RHS inner gear door inside.

Now that you’ve decided where to put all the elements we can start splitting them up. Use Converter to make a text dump of your starting PF.3dz. For starters let’s make the left wing 3dz. Scroll down to the elements section and using your list, type 255  in front of all the elements that you don’t want to appear – i.e., the elements that make up the left wing should be the only ones that don’t have a 255 in front of them. The 255 is the Endcode that tells the EAW graphics engine that it has come to the end of that line of data, so anything after the 255 will not show up. If you don’t need non-mirror panels to show up, make sure you disable them too – but remember that they are usually sub elements.

Scroll up to the top and change the texture identifier from PTEX.pcx to PLEX.pcx or whatever takes your fancy to identify the left wing pcx. Only use three characters in your ID. Now save the document as PG.txt and use converter to convert it back to 3dz (always keep a backup of your starting 3dz). Rename a PTEX.pcx file to PLEX.pcx, and put it into your Studio folder, then run Studio and take a look at the changes. You should see just a left wing. If it is missing elements, or there are other unwanted elements, go back into the text dump and enable / disable the elements as required.


 * Note – when making the front 3dz, try leaving the cockpit elements on the front 3dz for starters instead of creating a separate cockpit 3dz, as this will create less RS problems. If you need to put them on a separate 3dz, you can easily split them off the front 3dz later, and check the RS consequences it may bring.

Congratulations! You’ve just completed stage one! Now you do the other 3dz’s in the same way, just substituting names as required. If you have a different layout, make changes as necessary. The names I’ve used are -

Table 1. – Suggested names and codes. Left wing 3dz = PG.3dz - texture id = PLEX.pcx attaching code = 29 Right wing 3dz = PE.3dz – texture id = PREX.pcx attaching code = 28 Tail Left 3dz = PA.3dz - texture id = PTLL.pcx attaching code = 25 Tail Right 3dz = PB.3dz - texture id = PTLR.pcx attaching code = 26 Front Fuselage 3dz = PF.3dz – texture id = PFRT.pcx (put the attaching codes in this .3dz) Cockpit/Transparency 3dz = PC.3dz - texture id = PTEX.pcx attaching code = 27

Joining them all together Once you have all the textures where you want them, the next job is to join them all together with the hard-point codes. Because the new PF.3dz now has many disabled elements, we can attach the new 3dz’s onto some of these, hopefully in a way that will minimize Rendering Sequence problems. Have a look at your original PF.3dz and look for the best place to attach the new 3dz’s. In my experience, the best place is at the furthermost extremity of the element you are attaching. To illustrate what I mean, I’d attach the left wing 3dz onto the extreme wingtip element of the left wing, and I’d attach the left tail 3dz onto the left elevator element. By doing it this way it seems to preserve the Rendering Sequence. Check your element notes (and studio) to find out which element numbers these are.

First we must create a node point to which all the new 3dz’s are assigned. Open up a text dump of your new PF.3dz, and look at the Points section in the header. Hopefully there will be a spare point (maximum is 255). Add one point to this value, and then scroll down to the Points section. Here you make a new point with zero co-ordinates, for example, P249= 0 0 0 0

Let’s assume that we’re attaching the left wing. Scroll down to the element that you want to attach the new 3dz to - this element should have a 255 in front of it. In front of the 255, we type the attaching code for the left wing, so it would look something like this: - E070= 2 29 249 255 with a heap of disabled data behind it. 2 signifies that this element is a hardpoint, 29 signifies that we are attaching the PG.3dz to the hardpoint (see table 1) 249 is the node point where the PG.3dz will be attached. 255 is the endcode.

Continue on attaching the other 3dz’s at the required spots using the same method, substituting the attaching codes (25 to 29) as indicated in Table 1 above. Attach all the 3dz’s onto the same point (249 in the example).

Adjusting the normals Now that the Paste-on 3dz’s are all in the right spots, we have to change the normals to make the 3dz’s show up properly. In the PF.3dz text dump, scroll to the Normals section. Using the left wing as an example again, find the corresponding normal for it – it should look something like this: - N070= 0 16384 0 49152 0

The first 3 values determine the vector at which the element is visible, but by changing the last value, we can make the element visible all the time, regardless of the viewing angle, so change the value to –32768, so it looks like this. N070= 0 16384 0 49152 –32768

Repeat this process for all of the newly attached 3dz’s., then convert back to 3dz

Taking a look at the changes. What we have now is a multiple 3dz aircraft, with multiple pcx’s, but it is still mapped to the old pcx files. To further illustrate what bits are going where, I chose some contrasting coloured paint schemes of the required PTEX.pcx’s, and renamed them as required (See Table 1. above), so that I could get a visual demonstration that I was actually using multiple pcx’s. Picpac all the pcx files, then copy them and all the 3dz files into your EAW folder and go for a spin. If you’ve done things right, it may look something like this.



This Mustang is using four pcx files and four 3dz’s, with the cockpit on the front of the aircraft (Pp51dF.3dz, using Pp51dtex.pcx)

If you have problems, check that the spacing in the 3dz text dumps is consistent. 3dz’s are quite sensitive to different spacings (although anything after the 255 endcode is not important.) Take a good look at your model, and see if there are any rendering sequence problems. You may be able to minimize these by attaching the paste on 3dz’s to different elements, using a trial and error method. Also you could try altering the 3 normal vectors, or the “D” value in the normal section. I’m not exactly sure what this does, but it can make a difference. Check to see that the normal value is correct, as this is usually the root of the problem!

Re-mapping to High Resolution.
 * Use a version of 3DZ Studio that doesn’t automatically re-calculate the normals, because if they are re-calculated, some elements that use sub-elements may not appear as they used to. *

If you must re-calculate the normals, always have a backup file so that you can copy and paste the old normals section back in, should things go wrong (I had elements disappear, and assumed that the normals were OK, using a –32768 on the end of the normals line to make the elements visible again. Do NOT do this, as it causes problems when using glide. First, look to see if the three normal vectors for the element have changed, as this is most likely your problem.). Now that you have a working model, it’s time to start work on the Hi-res skin. Add as much detail as you can to the bare skin, and then start re-mapping the 3dz’s to the new texture files. Use 3dz Studio to make the changes, taking care to avoid warping at all costs. This is the time consuming part. Getting it roughly mapped out is easy enough, but eliminating all warping is the tricky bit. Take particular care when joining up 3dz’s (for example, the front fuselage and rear fuselage in the picture above), so that everything lines up perfectly. . The more detail you have in your skin, the easier it is to get things lined up properly.

The secret to warp free re-mapping is quite simple. If you are looking at an element on the wireframe from directly above, the area you map it to on the pcx must be the exact same shape. For example, if you have a triangular element with sides that are 4 cm, 3 cm and 1 cm, your pcx mapping area must have sides with the same ratio of 4:3:1. If it doesn’t, the texture will be stretched or squeezed to fit onto the wireframe.

It also pays to use some mathematics to work out just how big your elements must be. Because the elements are all joined together, if you make the first few too big, then the last few fill have to be too small to fit them in, and this will produce unevenness and warping. Here’s a technique that I use to get the elements the right size. It doesn’t eliminate guess work, but it helps you out a lot. Load up the required 3dz and use the + - and cursor keys to zoom to get it to a good size, pan until it is exactly side on (Pic 1) and leave it there. In this example I’m trying to get the right ratio for the front panel sizes.

Click through the elements and find out the 3dz X values of the points cirled in yellow. In the example A= 14, B= -18, C= -25, D= -56, E= -82, and F= -94, so there are 108 3dz points from one end of the wire-frame to the other. We can calculate that A-B=32 points, or 29.6% of the distance (32/108), B-C=7 points or 6.5%, C-D=31 points or 28.7%, D-E=26 points or 24% and E-F=12 points or 11%.

Now we have to find how many pixels we have to play with. Have a look at your PCX file (below) and work out where the points for F and A must go. Point 1 MUST be exactly behind the canopy, and point 6 MUST be at the end of the nose. In the example below, the flag above point 1 indicates where A is located, and the flag above point 6 indicates where point F must be located. The X value of point 1 in the pcx file is 244, and the X value of point 6 is 2. This means that the distance between points 1 and 6 is 242 pixels. Now we use the percentage values we calculated above to work out where the remaining points go.

A-B is 32%, so 32% of 242 pixels is 77 pixels (Round up/down any decimals). We know that point 1’s X value is 244, so point 2’s X value must me 244-77=167. B-C is 6.5% so 6.5% of 242 pixels is 15.7 pixels. We just worked out that point 2’s X value is 167, so point 3’s X value must be 167-16=151, and so on.

We also know that for this 3dz, 108 3dz points=242 pixels, so 1 3dz point = 2.24 pixels. You can use this factor to work out the co-ordinate points of all the re-mapped elements once you have a few “base” points to work with as in the example above. Because we are mapping a 2D texture onto a 3D wireframe the co-ordinates may need to be a little different from the calculated values, but it will be close – use your judgement and experience to get it perfect. Now that you have the correct spacing you can visually get the rest of the mapping pretty close. You may be able to do your re-mapping without using this technique on all the 3dz’s, but doing it right the first time saves you going back many times later on, when you discover a couple elements that aren’t quite right. When you shift one element’s mapping, you have to shift all the adjoining ones as well, and one simple change is never as easy as you may have first thought!

Once you have the pcx roughly mapped out, it pays to use a grid PCX file to see how your 3dz model goes in the warping stakes. Make up a 256x256 pcx file, and draw a series of lines across it, forming a grid with every square the same size. Rename this file as required and drop it into your 3dz Editing folder, and then you can have a good look at your 3dz with the grid as the skin. The squares should all line up, and be the same size all over the wireframe. If there is warping present the squares will be elongated or compressed, or the lines will be curved. Make the changes that are necessary to eliminate as much warping as is possible. You will have to alternate between your intended PCX file and the grid PCX to make sure that you have everything right. Try to keep a count of how many mouse clicks you used to do all the re-mapping (see if you make a million!), and remember to give your clicking finger a break from time to time! Oh, and you may need a spare mouse :)

Some Additional Re-mapping and re-naming. - As well as the skin files, the Propeller 3dz (PP.3dz) will also have to be re-mapped to the PTEX.pcx - The Virtual cockpit prop-view (PY.3dz) will have to be given the same treatment. - You will have to make a PTRA.pcx file. Once you have finalised the look of your PTEX.pcx, save a copy as PTRA.pcx, and then paint all the areas you want transparent as Pink, and all the areas you want to show as Blue, using the shades in between as necessary. - Use the old PF.3dz (or the PM.3dz if you want a prop and spinner) as the new MDM – change the texture identifier to PMEX.pcx, and save it as PM.3dz. Take an “old” PTEX.pcx and re-name it as PMEX.pcx. - Change the texture identifier on the PS.3dz (Long Distance Model) to PMEX.pcx. - Change the texture identifiers on the PL.3dz and PR.3dz to point to PLEX.pcx and PREX.pcx respectively, and re-map them as necessary. (L=left Torn off wing, R=right TOW.) - You may want to create a new High-res wing view (PWNG.pcx) and re-map the PU.3dz to it. - Re-map the PH.3dz to the PTEX.pcx. Make the elements type 6, and map the textures all to a single point in the propeller “wedge” to give a transparent shadow. Some text editing may be necessary to avoid “overlaps”.

The Medium Distance Model question. As mentioned above, you can use the “old” PF.3dz as your MDM by renaming the texture identifier to point to the PMEX.pcx., and renaming an “old” PTEX.pcx to PMEX.pcx. The advantages are that your wire frame will be EXACTLY the same as your new HR 3dz’s, and they will have better resolution, non mirror panels etc. etc. Of course, at the distances the MDM kicks in at, you are unlikely to pick up any resolution change, but you can clearly see shape changes. The disadvantages are that it will take slightly more CPU to run (usually not a problem), and there will be no prop or spinner displayed, which kind of ruins the shape from side on.

If you don’t like that look, you can use the old MDM. Once again, change the texture identifier to PMEX.pcx and rename the old PTEX.pcx to PMEX.pcx. The advantages here are that this MDM already has a prop and spinner attached – the disadvantages are that the wire frame does not have the same detail, and of course you can’t use transparencies. You can get around this by making some 3dz changes. If you move the points to trim the “propeller blur” you can still have a spinner and prop blades that turn, without the windmill look. If you delete the prop blur elements altogether, you will still have a spinner, and lets face it, at the distances the MDM kicks in at, you are unlikely to see the prop blur anyway. I guess it’s your call as to what you think will look best.

Using extra points. Now that we have a nicely detailed aircraft, what else can we do? Well, if you used six 3dz’s, there are now 1536 possible points, and 1536 possible elements that you can use, so the sky is the limit! You can use some of these points quite effectively to fix up parts of the model that were “bodgey” before, but were left that way because of the 256 point / poly limit. If you are a more experienced 3dz editor, this will be quite easy. Here are a few examples.

Many of the curves on the aircraft are modelled poorly, and you can use extra points to smooth out these sharp corners

Some elements that contain many points can produce warping. By adding extra points, you can divide the large element into several 3 cornered sub elements, which will eliminate warping. (I’m thinking of the Mustang tail and nose here)

Landing gear can be more detailed.

If you can work out the Rendering Sequence, you can add more elements to do a multitude of things – thickness to elevators and tail, sliding canopies, smoother panels, better curves and less corners, the list goes on……

Good luck with your High-Resolution project, and if you run into any problems, I’m only too happy to help out if I can.



This document is produced as freeware and can be used, shared, distributed as you please. Please note that I am no 3dz expert, just a mug who is trying something new, so there may be errors or omissions. I am in no way responsible if your HR project consumes your life, fails after many hours of toil, or causes you to put your fist through your computer – of course I’m not responsible if it is a raging success either! Finally, it’s advice only, and you needn’t feel obliged to take it! If you have any suggestions or methods that could be included in this document, drop me a line.

John “Chompy” Masters, 23rd October, 2002 jdmasters@ozemail.com.au http://www.ozemail.com.au/~jdmasters/

II - Further development: High Res damage models. By João “Muas” Martins

Introduction. By using this file split on a 3D model, you can now expand this theory further on, and develop some advanced damage models for each particular aircraft. First, we must consider the detachable parts of the model, which are by default the left and right wings of the aircraft. These are defined in files PL.3dz for the left wing and PR.3dz for the right one. These parts become detachable, by means of a switch (flag) that is triggered from the main executable. This flag appears at the beginning of the dumped element text line like this:

E112 149 0 5 4 … E113 149 1 5 4 …

Which mean the actual displayed element is the E112. The 149 is the code event for the detachable right wing, and 0 is the flag. So, every element of the right wing will have this very same prefix. When the right wing is hit in certain circumstances (probably defined in the bubble hit model) the flag switches to 1, and the E112 element disappears, giving place to E113. Meanwhile, the model of the PR.3dz file gets displayed, and moves itself after a certain flight model probably defined in the slot correspondent .flt file, which makes it bouncing and rotating in the air. Now as we´re splitting the models in several parts, it´s possible to adapt this principle to redefine what happens to the aircraft when it gets hit at a certain point. Let´s apply this technique to our HR P51D.

The goal. We now have the tail and a bit of fuselage defined in the A and B files. Let introduce the right wing detachable code event and flag to all elements of these two files. Then let´s attach them together using an insert point as

A-B is 32%, so 32% of 242 pixels is 77 pixels (Round up/down any decimals). We know that point 1’s X value is 244, so point 2’s X value must me 244-77=167. B-C is 6.5% so 6.5% of 242 pixels is 15.7 pixels. We just worked out that point 2’s X value is 167, so point 3’s X value must be 167-16=151, and so on.

We also know that for this 3dz, 108 3dz points=242 pixels, so 1 3dz point = 2.24 pixels. You can use this factor to work out the co-ordinate points of all the re-mapped elements once you have a few “base” points to work with as in the example above. Because we are mapping a 2D texture onto a 3D wireframe the co-ordinates may need to be a little different from the calculated values, but it will be close – use your judgement and experience to get it perfect. Now that you have the correct spacing you can visually get the rest of the mapping pretty close. You may be able to do your re-mapping without using this technique on all the 3dz’s, but doing it right the first time saves you going back many times later on, when you discover a couple elements that aren’t quite right. When you shift one element’s mapping, you have to shift all the adjoining ones as well, and one simple change is never as easy as you may have first thought!

Once you have the pcx roughly mapped out, it pays to use a grid PCX file to see how your 3dz model goes in the warping stakes. Make up a 256x256 pcx file, and draw a series of lines across it, forming a grid with every square the same size. Rename this file as required and drop it into your 3dz Editing folder, and then you can have a good look at your 3dz with the grid as the skin. The squares should all line up, and be the same size all over the wireframe. If there is warping present the squares will be elongated or compressed, or the lines will be curved. Make the changes that are necessary to eliminate as much warping as is possible. You will have to alternate between your intended PCX file and the grid PCX to make sure that you have everything right. Try to keep a count of how many mouse clicks you used to do all the re-mapping (see if you make a million!), and remember to give your clicking finger a break from time to time! Oh, and you may need a spare mouse :)

Some Additional Re-mapping and re-naming. - As well as the skin files, the Propeller 3dz (PP.3dz) will also have to be re-mapped to the PTEX.pcx - The Virtual cockpit prop-view (PY.3dz) will have to be given the same treatment. - You will have to make a PTRA.pcx file. Once you have finalised the look of your PTEX.pcx, save a copy as PTRA.pcx, and then paint all the areas you want transparent as Pink, and all the areas you want to show as Blue, using the shades in between as necessary. - Use the old PF.3dz (or the PM.3dz if you want a prop and spinner) as the new MDM – change the texture identifier to PMEX.pcx, and save it as PM.3dz. Take an “old” PTEX.pcx and re-name it as PMEX.pcx. - Change the texture identifier on the PS.3dz (Long Distance Model) to PMEX.pcx. - Change the texture identifiers on the PL.3dz and PR.3dz to point to PLEX.pcx and PREX.pcx respectively, and re-map them as necessary. (L=left Torn off wing, R=right TOW.) - You may want to create a new High-res wing view (PWNG.pcx) and re-map the PU.3dz to it. - Re-map the PH.3dz to the PTEX.pcx. Make the elements type 6, and map the textures all to a single point in the propeller “wedge” to give a transparent shadow. Some text editing may be necessary to avoid “overlaps”.

The Medium Distance Model question. As mentioned above, you can use the “old” PF.3dz as your MDM by renaming the texture identifier to point to the PMEX.pcx., and renaming an “old” PTEX.pcx to PMEX.pcx. The advantages are that your wire frame will be EXACTLY the same as your new HR 3dz’s, and they will have better resolution, non mirror panels etc. etc. Of course, at the distances the MDM kicks in at, you are unlikely to pick up any resolution change, but you can clearly see shape changes. The disadvantages are that it will take slightly more CPU to run (usually not a problem), and there will be no prop or spinner displayed, which kind of ruins the shape from side on.

If you don’t like that look, you can use the old MDM. Once again, change the texture identifier to PMEX.pcx and rename the old PTEX.pcx to PMEX.pcx. The advantages here are that this MDM already has a prop and spinner attached – the disadvantages are that the wire frame does not have the same detail, and of course you can’t use transparencies. You can get around this by making some 3dz changes. If you move the points to trim the “propeller blur” you can still have a spinner and prop blades that turn, without the windmill look. If you delete the prop blur elements altogether, you will still have a spinner, and lets face it, at the distances the MDM kicks in at, you are unlikely to see the prop blur anyway. I guess it’s your call as to what you think will look best.

Using extra points. Now that we have a nicely detailed aircraft, what else can we do? Well, if you used six 3dz’s, there are now 1536 possible points, and 1536 possible elements that you can use, so the sky is the limit! You can use some of these points quite effectively to fix up parts of the model that were “bodgey” before, but were left that way because of the 256 point / poly limit. If you are a more experienced 3dz editor, this will be quite easy. Here are a few examples.

Many of the curves on the aircraft are modelled poorly, and you can use extra points to smooth out these sharp corners

Some elements that contain many points can produce warping. By adding extra points, you can divide the large element into several 3 cornered sub elements, which will eliminate warping. (I’m thinking of the Mustang tail and nose here)

Landing gear can be more detailed.

If you can work out the Rendering Sequence, you can add more elements to do a multitude of things – thickness to elevators and tail, sliding canopies, smoother panels, better curves and less corners, the list goes on……

Good luck with your High-Resolution project, and if you run into any problems, I’m only too happy to help out if I can.



This document is produced as freeware and can be used, shared, distributed as you please. Please note that I am no 3dz expert, just a mug who is trying something new, so there may be errors or omissions. I am in no way responsible if your HR project consumes your life, fails after many hours of toil, or causes you to put your fist through your computer – of course I’m not responsible if it is a raging success either! Finally, it’s advice only, and you needn’t feel obliged to take it! If you have any suggestions or methods that could be included in this document, drop me a line.

John “Chompy” Masters, 23rd October, 2002 jdmasters@ozemail.com.au http://www.ozemail.com.au/~jdmasters/

II - Further development: High Res damage models. By João “Muas” Martins

Introduction. By using this file split on a 3D model, you can now expand this theory further on, and develop some advanced damage models for each particular aircraft. First, we must consider the detachable parts of the model, which are by default the left and right wings of the aircraft. These are defined in files PL.3dz for the left wing and PR.3dz for the right one. These parts become detachable, by means of a switch (flag) that is triggered from the main executable. This flag appears at the beginning of the dumped element text line like this:

E112 149 0 5 4 … E113 149 1 5 4 …

Which mean the actual displayed element is the E112. The 149 is the code event for the detachable right wing, and 0 is the flag. So, every element of the right wing will have this very same prefix. When the right wing is hit in certain circumstances (probably defined in the bubble hit model) the flag switches to 1, and the E112 element disappears, giving place to E113. Meanwhile, the model of the PR.3dz file gets displayed, and moves itself after a certain flight model probably defined in the slot correspondent .flt file, which makes it bouncing and rotating in the air. Now as we´re splitting the models in several parts, it´s possible to adapt this principle to redefine what happens to the aircraft when it gets hit at a certain point. Let´s apply this technique to our HR P51D.

The goal. We now have the tail and a bit of fuselage defined in the A and B files. Let introduce the right wing detachable code event and flag to all elements of these two files. Then let´s attach them together using an insert point as

explained in the previous chapter. Rename the attached file to PR.3dz and as means of realism, we must reajust the bubble hit, so to move the area of the right wing that when hit triggers the flag, to the center of the fuselage (although thinking it is possible, it’s a field I haven´t exploit). We should now delete the code and flags of the right wing elements of the actual right wing, now the PE.3dz file. So what´s gonna happen? You hit the 51 centre fuselage and the plane brakes in two right behind the cockpit, just like this FW190 example on the right.

But It isn´t over yet. A few important things remain: adjusting the original flight model of the aircraft when it originally looses the right wing, which was a spinning movement, to a more realistic fall down of the aircraft with its two wings on and no tail; next adust the original flight model of the loosen right wing to better suit the tail fall down (editing the .flt file I guess). Also, you need to add an extra element to fill the broken surface from the inside of the fuselage at both sides. A single black coloured element should look good enough. And finally, if the front fuselage part is addressed to the main texture file (PTEX.pcx), you can make use of transparent textures to emulate the broken structure bars coming from the inside of the fuselage. Wau! Here, on the right, you can see the same technique applied to the bouncing fuselage section.

Ok, this is the basic principle and can now be applied to get other effects. For example, we could now change the default left wing model split to a chopped off engine, spinner, canopy, aileron, stab, almost whatever you may think could happen in a real air combat damaged aircraft. Beware that the damaged model must be well defined prior the High Res mod, so to cope with the new detachable parts. And, for a extra real touch, the model sliptting should be assimetric.



Extra refinements. We shall give now a touch of surface damage look to our 51, using the new available elements and texture space in all these new .3dz and .pcx files. By means of this helpfull flags, we can display bullet holes and scratches over the surface of the aircraft. This can be easily done by the following method: First we shall “double” some elements on the wings and fuselage surface. Piece of cake. Using the very same points (nodes) of and existing element, we create another one exactly equal, and place it in the rendering sequence “right in front of” the original. What we get is a second element covering the first one. So far, this technic was already used by some fellow 3dz modders, to unmirror codes and nose art. Now we want to make our bullet marks appear after being shot at. So, the trick is to remap the first (the under element) to the addressed .pcx file area with a bit of surface of wing/fuselage with the painted bullet holes and scratches. Then we only have to include the code event and flag to the second element (the upper one). Suppose, we want to associate the bullet marks showing, with the pilot killed event: we then include the 146 code event in the “upper” element dumped text line with the the flag value 0, and the same code with flag value 1, to the “under element”. Shot at the 51´s canopy, and as the killed pilot gets displayed with all that blood spread, the “upper” elements disappear, showing the surface of the aircraft filled with holes. Neat.

Event codes list. (taken from Moggy´s notes at http://www.soft.net.uk/isis/tech/tech3dzcodes.htm) 136 - 139 (0-1) used to show changes in weapons stations during firing of ordnance (rockets in particular); 140 - 143 (0-2) used for propeller blades, still (single blades), software rendering PAW type lines, or full 3d turning (triangular sections); [144 appears to have been intended to be used for paste-on gun packs, but not actually used]; 145 (0-1) used for central fuselage undercarriage elements (wheels and doors) extended or retracted; 146 (0-1) used to show pilot uninjured or injured (used for both pilot and shattered glass in cockpit canopy); 147 (0-3) cycles through engine exhaust panels when engine on; only used in the V1 slot; 148 - 149 (0-1) used for the tear-off left and right wing elements undamaged or damaged and etched; [150 appears to have intended to be used in PAW for moveable elevators, but not actually used]; 151 - 152 (0-1) used for left and right wing undercarriage elements (wheels and doors) extended or retracted; 153 (0-17) used in the B17 and B24 slots for the random sequence nose art panels; 153-158 were used in the EAW demo to create gun flashes; unfortunately these were left out of the final build.

Finals. These ideas are yet to be tested. As I have little extra time to spare to develop them, I hope some fellow EAW contributors might give it a try, as I think these could benefit this sim everyday increasing quality grafics.

This document is produced as freeware and can be used, shared, distributed as you please. I´m in no way responsible to what might happen to your hardware/software system by trying its contents. These notes assume you are familiarized with the EAW file structure. Don´t try them, unless you know exactly what you are doing. If you have any doubts or suggestions, just drop me a line.

João “Muas” Martins, 14th August 2002 joaomartin@clix.pt http://fangsout.free.fr