Rendering+sequence+tutorial

= Rendering Sequence Tutorial. =

= For 3dz’s from Microprose’s “European Air War”. By John “Chompy” Masters =

Submitted by RAF_Dumoulin.

1. Introduction 2. Normals 3. The RS and how it works 4. Reversing the drawing order 5. P51 example and drawing a RS tree. 6. The use of Branches in the RS tree. 7. Different RS tree structures. 8. Drawing up a new RS from a simple model. 9. How to fix RS problems in an existing 3dz. 10. Adding new elements to an existing 3dz. 11. Creating a new RS from scratch. 12. Bug Hunting your RS mods. 13. Credits.
 * Contents**

The Rendering Sequence (RS) is one of the least understood aspects of the 3DZ models used in EAW. Most modders have the enough understanding of the points, elements and normals involved with 3dz’s, but adding new Elements requires alterations to the RS, and this is where most people find that it is all too hard. I agree that it certainly isn’t easy, but this document will hopefully give an insight into how the RS works, and how you can go about making your own RS mods to fix problems that you have.
 * Introduction.**

This tutorial is made possible thanks to the knowledge that has been passed down by the EAW 3dz gods, such as Moggy, Alessandro Borges and Paulo Morais. I have only tried to package the information that I have gained from them over the years, into one document. There are still many areas of 3dz’s that are a mystery, but we are uncovering more information all the time.

I will try to give you an overview of how the RS works, using a few examples to point things out. This tutorial assumes that you already have some degree of knowledge about 3dz’s in general. If that is not the case, get your hands on Cord’s 3DZ CAM document, which will help immensely.

- Alessandro’s 3dz Studio! Or Gurney’s 3dz Studio - Converter 1.8 (contained in the tutorial zip) - Some example 3dz and .pcx files contained in the tutorial zip file. - Patience, grasshopper 
 * What will I need?**

The Sequence works hand in hand with the Normals section of the 3dz, so first I’ll try to bring you up to speed with the known info on the Normals. If you already know enough, feel free to skip ahead! Every type 3, 4, 5 and 6 element should be a flat polygon hanging in space. These polygons sit in a fixed position and have two faces. The graphics engine of EAW needs to know the elements normal value to know if the element is visible from the current viewing, which tells it which side of the element to draw the textures. Likewise, all other elements – type 1 (Single coloured lines), and 2 (Hardpoints), also have a similar normal value. Even though Hardpoints have the F value set at –32768 to be visible all the time, the RS still uses the Normal value to draw everything in the correct order.
 * First, an explanation of Normals.**

The normal of an element composes of two parts, angle and distance from centre. The Angle of a vector originates from the centre of the element, perpendicular to it's face, pointing out into space. This vector determines the viewing angle at which the particular element is EXACTLY face on to the viewer. This vector is split into 3 components, X, Y and Z. The maximum value of any of these components is +16384, and the minimum is -16384. As well as these three values there are also the D, C and F values, which relate to the distance from the center of the model. From an email from Gurney – “Now..the normals. I don't know if you know, but I found when I started the RS calculator, that the C and d values done by Alessandro's version are wrong, and should be combined. If you look up the plane equation on the internet (which is defined by the normal), you'll find that there are X, Y, Z values which define the direction of the plane, and a D value which is found by – D = X*(pointonplane.x) + Y*(pointonplane.y) + Z*(pointonplane.z). So thats the reason that its different..but correct” So the D and C values have a relation to the distance from the center of the model’s XYZ. They do affect the rendering of an element, and it almost appears as a ‘sensitivity’ adjustment. If a newly created element isn’t showing as it should (even though it’s normal vectors are correct) you can try adjusting these values. Try looking at another 3dz which has an element used in a similar situation, study it’s D and C values for clues, and try using those values in your new element. Sometimes the D and C values can be left as zero, and other times you may have to tweak them. Wolfman's vector calculator, or the ‘StudioM’ version of Alessandro’s 3dz Studio will work out the exact value of the Normals for you, so there is no need for guessing, but it helps if you can understand how the normals work it can help with troubleshooting problem elements. I am unsure of the triginometry calculations and formulae involved, but it's quite easy to follow if you first look at some normals that lie parallel with an axis.
 * Normals definition -**



Refer to the attached diagram. The normals YZX axis are exactly the same as the Points YZX axis. Take a look at the normal for Element B on the left wing. The Normal vector originates perpendicular to the face of the element,

and runs out into space. If you were at any point along that normal vector, the element would be 100% viewable, and your viewpoint would have an infinite +Z value, and no Y or X value.. That vector's Z component would be +16384, and because the element is square to the axis, there is no X and Y component, so they are both 0. If this element was on the bottom of the wing and the viewable face was pointing down, the Z component would be -16384.

Looking at element A, it lies on exactly the same plane as element B, so it's XYZ normal is exactly the same as B's normal. (the D and C values would change though)

Now look at element C on the tail. It's normal points out to the left side of the aircraft, and if you were at the end of that vector, your viewpoint would have an infinite -Y value, and no X or Z value, so that normal would have an Y component of -16384, and it's X and Z components would both be 0. Once again, if that element was facing the right hand side of the plane, the Y component would be +16384, and the X and Z would remain at 0.

The last example element is D - the radiator scoop which faces directly to the front. You can work out that the element would have a normal vector value of X -16384, while Y and Z would be 0. If that element was facing the rear of the aircraft the X value would be +16384 and Y and Z would still be 0.

These examples all lie parallel to an axis, and are easy to work out in your head. With a little practice you can roughly pick the values a normal should have, e.g. it should have a LOT of -y, a bit of +z, and a faint hint of -x. Rough enough isn't good enough, so use Wolfman's calculator or StudioM to get things right. I have noticed that sometimes these values can have the wrong + or -, so keep that in mind too, but mostly it will get things right. A wrong normal value is pretty easy to spot. It just means that an element will not be drawn when it should be drawn. For example, as you move your viewpoint to be exactly side on to an element, it will disappear – the Normal values tells the EAW graphics engine that the normal isn't visible, and so it doesn't bother drawing it. An incorrect normal value will mean that the element disappears at certain angles, when it should still be drawn. On the opposite viewing angle, the element will be still drawn, even though it is not visible. Remember that the Normal splits all viewing angles into two Hemispheres - one in which that element is drawn, and one in which it is not.

So here's what a normal line could look like in a text dump. N000= 0 16066 -3213 -28362 -9 0
 * N000= _y0 _z0 _x0 _d _c _f

The F value assigns the normal to an INSERT section, and can also be -32768 for hardpoints. When the value is set to –32768 it means “draw this element so that it is visible all the time”. If you are having rendering problems it can be tempting to use the –32768 trick to make an element appear all the time, but this is a very dodgy fix. It doesn’t correct the sequence at all, and will most likely give the model some serious rendering problems for Glide users. So, my tip is to only use the –32768 value on Hardpoints.

The RS is the data that gives the EAW graphics engine the order in which it must draw the individual Elements in the 3dz’s. The sequence is dynamic, so there is no set drawing order, just a set sequence. As our viewpoint around the model shifts, the drawing order of the individual elements changes as dictated by the sequence. This is why the sequence is such a tough nut to crack – if you change the viewpoint by just a few degrees, the drawing order will change, and all of these changes are tricky to keep track of.
 * What is the Rendering Sequence?**

If all is correct, things look fine, but if the sequence is wrong, you will end up with elements that show through other elements. Put simply, RS problems happen when an element is drawn on top of another element, when it should be drawn behind that element. In comparison, a Normals problem can be recognized by elements not being drawn at all when they should be.

This utility converts 3dz’s to .txt files and vice versa so that we can work on the RS. Alessndro’s Converter 1.8 is an essential tool for RS work. Previous versions of converter present the Sequence section in a different format to 1.8, and the latest format is the easiest to follow, so it is the one I will use in this tutorial.
 * Converter 1.8**

It is hard to describe one aspect of the RS without knowledge of the others, which makes it difficult to structure this tutorial in a way that you can read things from start to finish. Hopefully as you work your way through the document things will become a little clearer, but you will probably understand it better with a few more reads. The sequence is easiest to understand once you finally see it in a tree, but there are a few things to go through first.
 * How does the Rendering Sequence work?**

The Sequence works hand in hand with the Normals section. See the above chapter on Normals for a full explaination of how they work.

Every element has a corresponding Sequence line, and this line links it to all the other element’s sequence lines. This line tells us which elements appear in front of it (drawn later), and which elements appear behind it (drawn first). A text dump of a typical Sequence data line looks like this – S003= 1 5

• S003 – This signifies that we are about to draw E003. • 1 – This signifies that if E003 is visible, E001 and all elements branched below it, will be drawn on top of (drawn in front of, or drawn later) E003. Thus, 1 forms the LEFT branch of the tree. • 5 – This signifies that if E003 is visible, E005 and all elements branched below it will be drawn underneath (drawn behind, or drawn first) E003. Thus, 5 forms the RIGHT branch of the tree.

Here’s a little illustration to help you grasp the concept. Imagine that this is a very simple aircraft 3dz, with elements 1, 3, 5 on one side (for now ignore elements 2, 4, 6 on the opposite sides).



S(Element being drawn) = (Left branch Element) (Right branch Element) – but more on the trees later.

So we have established that if an element is visible the drawing order is – Right Branch – Element being drawn – Left branch. That’s fine when viewing from this side, but what about the other side? Won’t 5 still show over the top of 3 and 1? Well, EAW checks the normal of each element to see if the element is visible, and if it is NOT visible, it then reverses the drawing order (i.e. draws the ‘left branch element’ first, and draws the ‘right branch element’ later). So now the drawing order would be – Left Branch – Element being drawn (not actually drawn*) – Right branch
 * Reversing the drawing order, or reversing the Branches.**


 * The element is not drawn, because it isn’t visible, and this saves on processing power.

To help illustrate, here’s a picture of S003 1 5 drawn into two trees. The Red and Blue lines follow the RS drawing order with Blue ‘walking’ to the next element, and Red ‘drawing’ the element. The left tree follows the RS drawing order if 3 IS visible, and the right tree follows the RS drawing order if 3 IS NOT visible.



When viewed from the left where 3 is visible, the drawing order is 5, 3, 1. When viewing from the Right hand side (Right tree, where you would only see the back of E003) the drawing order would be 1, then 3 (which would not be drawn because it is not visible), then 5. Although 3 wouldn’t be visible, the drawing order is correct. Confused? This can be a bit complex to visualize, but you’ll be able to follow it easier when looking at a whole tree.

When all of these Sequence data lines are joined together visually, they fit into a sort of upside down tree, which has the ‘root’ at the top, leading down to the other branches, and the EAW graphics engine determines which branch to follow by looking at the element’s normals. More about RS trees later, but for now, here’s the crucial definition of how the RS works.

When drawing a 3dz, the graphics engine always starts at the Root element, but each element is processed in the same way.


 * //1. First by checking the element’s Normal value, and comparing it with your viewpoint, it determines if the element is visible.//**

//**2.1 If the element IS visible, it first draws the Right branch, secondly draws the element, and lastly draws the Left branch.**//

It then follows down the required branch, and repeats the same process for every line of the sequence.
 * //2.2 If the element is NOT visible, it first draws the Left branch, doesn’t worry about drawing the element, and lastly draws the Right branch//**.

The drawing of a single element only takes a split second. The graphics engine draws each 3dz one element at a time, and when all the elements and all the visible 3dz’s (+other graphics) have been drawn, a ‘frame’ has been completed, and it then goes on to draw the next frame. So when you have 20 aircraft in the sky, each with 250 elements, and you are getting 30 FPS, the EAW engine is drawing/processing 150,000 elements per second!

//**P51DS.3dz example to study.**// For starters, extract the Pp51dS.3dz and the pp51dmex.pcx files into your 3dz Studio folder, then start 3dz Studio and have a look at the Pp51dS.3dz. This is the Very Long Distance Model, and is as basic as aircraft 3dz’s get, and thus it is a very simple model to use as an example. Click through the elements in wireframe view (w) to see what they all are. Here is a list of each element.

E000 = Spinner LEFT E001 = Nose LEFT E002 = Air scoop LEFT E003 = Middle tail LEFT E004 = Tail front/top LEFT E005 = Canopy LEFT E006 = Nose middle LEFT E007 = Tail rear/bottom LEFT E008 = Fuselage LEFT

E009 = Spinner RIGHT E010 = Nose RIGHT E011 = Air scoop RIGHT E012 = Middle tail RIGHT E013 = Tail front/top RIGHT E014 = Canopy RIGHT E015 = Nose middle RIGHT E016 = Tail rear/bottom RIGHT E017 = Fuselage RIGHT

E018 = Inner wing Top LEFT E019 = Inner wing Bottom LEFT E020 = Outer wing Top LEFT E021 = Outer wing Bottom LEFT E022 = Wing tip Top LEFT E023 = Wing tip Bottom LEFT

E024 = Top elevator LEFT E025 = Bottom elevator LEFT

E026 = Inner wing Top RIGHT E027 = Inner wing Bottom RIGHT E028 = Outer wing Top RIGHT E029 = Outer wing Bottom RIGHT E030 = Wing tip Top RIGHT E031 = Wing tip Bottom RIGHT

E032 = Top elevator RIGHT E033 = Bottom elevator RIGHT

Note that some of the elements have sub elements attached to them. These are single line elements (to help with viewing flat elements from side on) and are not important in the context of this tutorial – but just remember that sub elements will all share the same RS location of their parent element.

Also note how the elements are grouped, starting with the LEFT fuselage from 0-8, the RIGHT fuselage from 9-17, the LEFT wing from 18-23, LEFT elevator 24 and 25, RIGHT wing 26-31, and RIGHT elevator 32 and 33. This is

very convenient for helping to understand how things work. Now that we have a good idea which element is which, we are better prepared to see just how the RS is constructed.

Use converter 1.8 to make a text dump of the pp51dS.3dz, and look at the SEQUENCE section. It looks like this : -

[SEQUENCE] S000= 0 0 S000= 1 26 S001= 2 255 S002= 3 255 S003= 4 255 S004= 5 255 S005= 6 255 S006= 7 255 S007= 8 255 S008= 9 255 S009= 10 18 S010= 11 255 S011= 12 255 S012= 13 255 S013= 14 255 S014= 15 255 S015= 16 255 S016= 17 255 S017= 255 255 S018= 19 255 S019= 255 20 S020= 25 255 S021= 22 255 S022= 23 255 S023= 255 255 S024= 255 21 S025= 24 255 S026= 27 255 S027= 255 28 S028= 33 255 S029= 30 255 S030= 31 255 S031= 255 255 S032= 255 29 S033= 32 255 [END]
 * S000= Back Front
 * the first line is the start point of rendering sequence

Making our RS Tree. The first S000 tells us which element is the root element, or the place to start. The root element is usually along the centerline of middle of the model, and will have many elements on either side. The other elements form the many different branches in the tree. In our example we have S000= 0 0, so the root element is E000 - this is the starting point for our RS tree. I think the second zero indicates the end of the sequence. The basic format for the Sequence section is quite simple. The first number forms the left branch (drawn later), and the second number forms the right branch (drawn first). For example :- S009= 10 18 means “If E009 is visible, before we draw it, we must first draw E018, then we can draw E009, and lastly we must draw E010.”

You will notice that there are many 255’s in the sequence. A 255 simply indicates that you have come to the end of the branch on the RS tree, and there is nothing else to draw here. In this example : - S027= 255 28, means “If E027 is visible, before we draw it, we must first draw E028), then we can draw E027, and lastly we must draw 255(nothing!)”

Another variation – S033= 32 255, means “If E033 is visible, before we draw it, we must first draw 255 (nothing!), then we can draw E033, and lastly we must draw E032.

The final variation – S023= 255 255, means “If E023 is visible, before we draw it, we must first draw 255 (=nothing), then draw E023, and lastly draw 255 (= nothing)

When graphics engine comes to the end of a branch (255), it works it’s way back that branch, and goes about following all the branches that were identified as ‘drawn later’. When we assemble the Sequence data line into a tree, just make sure you follow this format -
 * //S(Element being drawn) = (Left branch Element) (Right branch Element)//**

Now that we know the basic layout, we can start drawing our sequence into a tree, so that it is a bit easier to follow. Take a big piece of paper and start in the middle at the top. Start with the Root element (E000, the left hand side spinner) and draw in the two branches, with the ‘drawn later’ branch on the left and ‘drawn first’ branch on the right. So S000= 1 26 looks like,



From there go to S001 and fill in it’s branches, and do the same for S026



Things may get a little congested, but by following each line you should end up with a tree that looks something like this



The * symbol is used in place of the 255’s to save space, and represents the end of each particular branch. The EAW graphics engine makes it’s way through the sequence until it gets to the end of each branch, then makes it’s way back to where the previous branch began, and so on.

To put the tree into words, assuming that each element is visible - Before I can draw 0, I must first draw 26, then draw 0, and lastly draw 1, BUT - Before I can draw 26, I must first draw nothing, then draw 26, and lastly draw 27, BUT - Before I can draw 27, I must first draw 28, then draw 27, and lastly draw nothing, BUT - Before I can draw 28, I must first draw nothing, then draw 28, and lastly draw 33, BUT - Before I can draw 33, I must first draw nothing, then draw 33, and lastly draw 32, BUT - Before I can draw 32, I must first draw 29, then draw 32, and lastly draw nothing, BUT - Before I can draw 29, I must first draw nothing, then draw 29, and lastly draw 30, BUT - Before I can draw 30, I must first draw nothing, then draw 30, and lastly draw 31, BUT - Before I can draw 31, I must first draw nothing, then draw 31, and lastly nothing. Now we are at the end of the branch, it goes back down the branch drawing all the elements that were previously identified as jobs that had to be “Drawn Later”.

//**How to interpret the tree.**// For any element on the tree, providing that the element is visible, All the elements on it’s left branch will ALWAYS appear ON TOP of it, and All the elements on it’s right branch will ALWAYS appear UNDERNEATH it. The elements above the branches can appear on top OR underneath, depending on which way their branches go.

Because the EAW engine is constantly reversing the front/back branches depending on your viewing angle, it can be very complex following the actual drawing order for any given viewing angle. The next picture will try to illustrate this – one viewed from the left, and one viewed from the right. To help, I have coloured in the different elements so that you can see why and where the branches occur a little better. The red and blue lines follow the order in which
 * Following the drawing order.**

the elements are drawn. The blue lines are where the sequence ‘walks’ to the next bit to be drawn, and the red lines signify where the elements are being drawn.


 * Note that the second picture has the drawing order of the wings grossly simplified, to make it easier for you to follow.**



Lets assume that we are viewing the model from //**above and to the left**// (first picture). First we’ll follow the basic structure of the branches. Starting at the root element E000, we ask is it visible? Being on the left fuselage, the answer is yes, so the EAW engine will draw the RIGHT branch first. This leads on to E026 and the rest of the //**RIGHT WING**// elements. For the moment we’ll ignore their drawing order, knowing that when this branch is finished it will return to E000 to draw it, and continue with the LEFT branch at E001.

Is E001 visible? Yes, so again draw the right branch (nothing), draw E001, then draw E002 Is E002 visible? Yes, so draw the right branch (nothing), draw E002, then draw E003 and so on. You can see that this continues on until all the //**Left Fuselage**// elements are drawn, and we hit S009.

Now we go on with S009. Is it visible? Being a right fuselage element the answer is no, so we draw the LEFT branch (E010) first, we don’t bother drawing E009 cause it has it’s back to us, and then the right branch E018 Later. Is E010 visible? No, so draw the left branch (E011) first, don’t draw 10 and then draw the right branch * later. Is E011 visible? No, so draw the left branch (E012) first, don’t draw 11 and then draw the right branch * later. This continues on until we hit S017. It’s not visible so we draw * first, don’t draw 17, and draw * later. From here we work our way back up the tree drawing all the elements that were assigned as ‘drawn later’

While the //**Right fuselage**// hasn’t been drawn, it has been processed.

This brings us back to S009. We had to draw E010 first, and we’ve done that, so we don’t draw E009 (cause it has it’s back to us) and then go on with drawing E018. From here we follow through the //**Left wing**// elements until all the elements have been drawn.

This demonstrates that when viewed //**from the left**//, this sequence will draw in the following order – - The right wing. - Then the left fuselage - Then the right fuselage (sequence processed, but elements not actually drawn) - Lastly the Left wing.

Which will display correctly.

Now suppose we are viewing the model from the right? Lets follow through the sequence again – the drawing order is illustrated on the second picture above. Is E000 visible? No saw draw the left branch (1) first, and come back to not draw E000, and then E026 later. Is E001 visible? No saw draw the left branch (2) first, and come back to not draw E001, and then * later. And so on. When we get to S009 we are still yet to draw anything.

Is E009 visible? Yes, so draw the right branch (E018) first, then draw E009, and draw E010 later. Still yet to draw anything… Starting at S018 we begin the branch that draws the //**Left wing**//. By the time we return from this branch we have drawn all the Left wing elements, then we go back as instructed at S009 to draw E009 and then go on with E010

Is E010 visible? Yes, so draw the right branch (*) first, then draw E010, and draw the left branch E011 later. Is E011 visible? Yes, so draw the right branch (*) first, then draw E011, and draw the left branch E012 later. And so on drawing all of the Right fuselage elements. From S017 we return back to ‘draw’ E009 and work our way back to the root S000 – this processes (but doesn’t actually draw) the //**Left fuselage**// elements.

Now we come back to drawing E026 later, as instructed right at the start of the Sequence. This branch draws all the elements for the //**Right wing**//, and finishes the sequence.

This demonstrates that when viewed //**from the Right**//, this sequence will draw in the following order – - The left wing. - Then the right fuselage - Then the left fuselage (sequence processed, but elements not actually drawn) - Lastly the right wing.

Which will display correctly. Hopefully you can follow this on the drawings above. From these examples you can see that the actual drawing order changes as your viewing angle changes.

Following the wing drawing order. You will notice that while the fuselage elements are all drawn in a linear manner, the wing and elevator elements are drawn with several different branches. Why is this? These branches allow for the elevators to be drawn over the top or underneath the wings depending on the viewing angle. Check out the following two screenies.



From the top, the top elevators must be drawn over the top of the wing elements,



Likewise from the bottom, the bottom main wings must be drawn over the top of the bottom elevators, or in RS speak, the Bottom Elevator elements must be drawn first, and the bottom wing elements must be drawn later.

Both the wing/elevator branches have an identical structure, so let’s take a closer look at the right wing tree, and analyse it’s drawing order.



Refreshing what the elements are – E026 = Inner wing Top RIGHT (T=TOP) E027 = Inner wing Bottom RIGHT E028 = Outer wing Top RIGHT E029 = Outer wing Bottom RIGHT E030 = Wing tip Top RIGHT E031 = Wing tip Bottom RIGHT E032 = Top elevator RIGHT E033 = Bottom elevator RIGHT

This diagram traces the drawing order when viewing the aircraft from the LEFT and ABOVE as in the top screenie. Visualise that view, and let’s go through the rendering process. Is 0 visible? Yes, so draw 26 first, then 0, and 1 later. Is 26 visible? Yes so draw * first, then 26, and 27 later. Is 27 visible? No, so draw * first, then 27, and 28 later. Is 28 visible? Yes, so draw * first, then 28, and 33 later. Is 33 visible? No, so draw 32 first, then 33, and * later. Is 32 visible? Yes, so draw 29 first, then 32, and * later. Is 29 visible? No, so draw 30 first, then 29, and * later. Is 30 visible? Yes, so draw * first, then 30, and 31 later. Is 31 visible? No, so draw * first, then 31, and * later.

You should be able to follow that the drawing order is – 26, 27, 28, 30 on the way out the branches, and then 31, 29, 32, 33 on the return journey.

Now you can see that the top wing elements (26, 28 and 30) are all drawn before the top elevator (32), so the top elevator is ALWAYS drawn on top of the top wings.

What happens if we are viewing from the BELOW and to the LEFT as in the bottom screenie? (No RS tree with drawing order here – try to make one your self!) Is 0 visible? Yes, so draw 26 first, then 0, then 1 later. Is 26 visible, No, so draw 27 first, then 26, then * later. Is 27 visible, Yes, so draw 28 first, then 27, then * later.

Is 28 visible, No, so draw 33 first, then 28, then * later. Is 33 visible, Yes, so draw * first, then 33, then 32 later. Is 32 visible, No, so draw * first, then 32, then 29 later. Is 29 visible, Yes, so draw * first, then 29, then 30 later. Is 30 visible, No, so draw 31 first, then 30, then 8 later. Is 31 visible, Yes so draw * first, then 31, then * later.

Now the drawing order has been completely reversed. It is now – 33, 32, 29, 31 on the way out the branches, and then 30, 28, 27, 26 on the return journey.

Looking from the bottom, you can see that the bottom elevator (33) is always drawn before bottom wing elements (29, 31 and 27), so the bottom wings are //**ALWAYS**// drawn on top of the bottom elevator.

This can be clearly seen in the above screenshots.

//**Different tree structures you will encounter.**// If we have a number of elements that do not get in each other’s way (such as the fuselage elements 0-8 and 9-17 on the PP51dS.3dz), it does not matter how we arrange the tree for those particular elements, but if they can all be drawn in a linear manner this groups them together. Other parts of the aircraft are also grouped together in different branches. Imagine a 3dz for a square box or a soccer ball – none of the elements interfere with each other so the tree could be drawn in any order without regard to front/back branches. Although it would work, it would also be super untidy and hard to follow, making it very difficult to make further additions to the sequence, so it’s best to keep things linear if you can.



Assuming that we are viewing from this side : - The first method uses a linear tree with a right branch to draw 5 first then 3 then 1. The second method also uses the right branch to draw 5, 3, 1. The third method uses a linear tree with a left branch to draw 5, 3, 1.



Once again there are many other different ways to put a correct tree together. We could have started each of these trees with elements 2, 4, 6 using the same structures and it would work perfectly. Just keep your mind open when thinking of a way to fix any RS problems.

//**Drawing a new RS using a simple example.
 * //Even though the Pp51dS.3dz is about as simple as any you are likely to encounter in EAW, it can be hard to follow, so let’s downscale a bit and draw up a brand new RS for a real simple model we used earlier.





For the same reasons, we can add 6 onto the drawn before side of 5. As long as it is somewhere on the ‘drawn later’ side of 4, it will work fine.

Again it is interesting to note that for this simple six sided 3dz, there are 18 possible permutations of this RS tree that would all render perfectly, and hundreds of others that would not! This is the challenge with the RS – to identify things that will work, and other things that will not. When you get to a larger 3dz with 250 or so elements, it can get incredibly hard to visualize how the tree would work in game. If you can follow how the above examples are put together, your knowledge of the basics of RS is in place, and you are in a position to start tackling some RS problems in some existing models!

//**Solving RS problems in existing Models.**// When a 3dz wireframe shape gets altered, the normals get altered as well, but the RS remains unaltered, configured for the Normals as they used to be. Although most of the RS appears fine, some parts can give RS problems.

Naturally, this has to be done on a case by case basis, so I can only walk you through an example and try to show how it works in principle.

Firstly, check the normals of the problem element, to ensure that they are correct. The entire 3dz should have it’s final 3d shape and the correct Normal values before you attempt to fix any RS problems.

Secondly, take a good look at the model in question in game. Identify the element that is giving trouble as well as the elements that clash with it, and look around for some nearby elements that are not giving trouble, as these are likely to be good places to splice in the RS of the problem element.

I’m going to fix some problems with the tailwheel on the HR P47C (E175), and the tail (E186) which show through the top of the elevators (E174). The element below the tail (E185) renders correctly behind the elevators, so I’ll try to put E175 and E186’s RS somewhere around there.





Make a text dump of the 3dz with Converter 1.8 and start drawing up a tree around the problem area, and another tree around a good area. Ideally you would draw the entire tree, but this can be time consuming. It’s pretty easy to draw your way down the branches, but drawing up towards the root can be hard to find elements. It helps to use Notepad’s  function to find the S### upwards. Here’s a section of the RS from the problem area on the P47 tail.



Note the Element numbers that have been highlighted. They are – 175 – the problem tail wheel 186 – the problem tail element 185 – the correctly rendered element under the tail 119 – the bottom elevator element 174 – the top elevator element. For now, we’ll forget about 186 and work on 175, as it gets confusing trying to do too much at once! You can probably see that we need to move 175 to somewhere near 185, but exactly where? This is where we ask ourselves the same question, visualizing the model and the viewing angle and answering for each element as we move down the tree. Q1 - If 119 is visible do we want 175 drawn first or later? As these elements will never clash, it can be drawn first OR later, so we move on… Q2 - If 185 is visible do we want 175 drawn first or later? The answer is drawn First (visualize from up high)

Q3 - If 174 is visible do we want 175 drawn first or later? The answer is drawn first, as this is our problem element. From these questions we have two possible locations, so lets visualize and try them out running through the tree. If we put 175 on the drawn first side of S174, although it would comply with Q3, it would not comply with Q2 (as 185 would be drawn first and the RS would work down the branch to draw 175, then 174), so we try another location. If we put it on the drawn first side of 185, it complies with Q3 and Q2, so we have found our location! Update your tree to show the changes as you do them, as this makes it easier to re-enter the altered sequence lines into the text dump.

Before we can put 175 in the new sequence, we must first remove it from the old one. In doing this we try to keep the RS structure similar, and just shift the next S### back up the tree to take it’s place. It’s an easy one to alter, and all we have to do is change S074= 175 255 to read S074= 64 255

Now to add it into it’s new position we need to change two lines – S185= 174 255 becomes S185= 174 175, and S175= 255 64 becomes S175= 255 255. The altered tree now looks like this –



Convert the file back to 3dz and test it in game – Presto! It worked! Now we can do the same thing to the problem tail element E186 Once again, we will need to shift it to a location somewhere around 119, 185, 175, and 174, so we visualize the correct viewing angle of the model and ask ourselves the questions again –

Q1 - If 119 is visible do we want 186 to be drawn first or later? Drawn first. Q2 - If 185 is visible, do we want 186 to be drawn first or later? Once again, these won’t clash, so it doesn’t matter. Q3 - If 175 is visible, do we want 186 to be drawn first or later? Doesn’t matter Q4 - If 174 is visible, do we want 186 to be drawn first or later? Drawn first.

So in all cases that matter186 needs to be drawn first. The first thing you would think of, would be that the correct location would be on the ‘drawn first’ side of 119. I did, and of course it didn’t work out! Why? Well, it works fine if 119 is visible, but if it is NOT visible, 174, 175, 185 and 119 will all be drawn first, and 186 will be drawn later - on top of 174 like it was before. D-oh! This is a big frustration with RS, and it may take several attempts to work out the correct position.

We need to draw 186 ‘first’ at a position further towards the root, and then elements 174, 175, 185 and 119 will all be drawn later, which should work. Let’s try it on the drawn first side of S177 (a side fuselage element which renders correctly – always a good clue!) First, lets remove 186 from the existing tree, in the same way as we did with 175. Change S080= 186 74 to read S080= 69 74. Update your tree. It will now look like this

To move 186 into it’s correct position we change S177= 119 209 to read S177= 119 186 To join 186 onto 209, it goes from S186= 255 69 to read S186= 255 209.

Convert to 3dz and try it in game. Success - Hurrah! Once again, that was just one example, and each RS mod you try will be different, and require different approaches, but if you ask yourself the questions for each element, and keep a lookout for elements that do render correctly, you will get a good idea of where the new sequence line should go. Be prepared for a lot of trial and error work though 

When removing an existing sequence# from a tree, it is possible that it will have two branches (instead of one being 255), such as S068= 79 171. These are very complicated to move without affecting the rest of the model, as they may form a critical branch. I have no bulletproof solution for this, so remember that Sequence numbers with a 255 on one branch are easiest to move around.

//**Creating New elements and adding them to the RS.**// Essentially this is the same process as the example above. The one exception is that if you already have spare elements you can just add the new sequence into it’s correct position. If you are working with a Hirez 3dz that has a lot of disabled elements, naturally you will have to remove the element’s corresponding Sequence line from the tree before you can add it back into it’s new location.

Once again I’m using the HR P-47C – this time the F.3dz which has about 28 new elements which are used to reshape the nose. We will concentrate on one element which has been split into four elements, and then all the other new elements are done in the same way. I used Gurney’s 3dz Studio to add new points, added these points to the required elements, then used the ‘Duplicate > piggyback’ button to make 3 duplicates and deleted all the un-needed nodes from each piggyback until I had the original plus three separate piggybacks with no overlaps.



First I need to free up 3 sequence lines. There are about 44 unused elements (used to be the left wing) which are still plugged into the Sequence, so we’ll try removing some of them. Take a look at the left wing E.3dz to find out their Element numbers, then check in the F.3dz to make sure that none of them are being used, and write them down on a piece of paper. Make sure you get a few spares, as there may be some that are best not removed from the Sequence.

Draw up the RS tree from the text dump. Start at the root and continue until you have found enough unused Sequence numbers, and also the ‘good’ sequence numbers where we will add the new elements. In this example we are splitting E002, so assuming that it’s RS is already correct, the best place to add the new elements will be close to E002. The simplest elements to remove and relocate are always the ones with no branches, preferably those that follow on sequentially. In the next pic we have some Unused elements on the top left, and the tree surrounding E002 on the top right. I have targeted 133, 134 and 135 as the ones to shift, but any of them from 131down to137 could be used.



To take 133, 134 and 135 out of the sequence we just join 137 onto 132 where 133 used to be. It the tree then looks like the picture in the bottom left. Simple!

Now we must Assign our duplicates to the new Elements we have chosen. Take a text dump and highlight the 3 piggyback elements on E002’s data line. Right click and select COPY, hit the Delete key, and add a 255 to the end of E002’s line. Scroll down to E133 and paste in the data line from the clipboard. Now repeat the process, copying the remaining 2 piggybacks, delete, add the 255, and paste into E134. Repeat again to enter the data for E135. Ensure that your new data lines have the correct spacings and that they all end with a 255. In the example – 2/0 remains as E002, 2/1 becomes E133 2/2 becomes E134 2/3 becomes E135.

Check the Normals F value. With that done, we have to check the normals. It is possible that the elements you choose to ‘recycle’ may be old elements that used to be part of the landing gear or props. If this is the case, the F value in the insert section will have a number other than 0. When you run the 3dz through the normals calculator it will come up with screwy results, because it is allowing for an offset in the INSERT section. To avoid bad results, make sure the F value in your element’s NOMAL line is set to 0, unless of course it is meant to be that way!

Because E002 renders correctly, we will add the new elements in the same way as E002 is drawn. In this example all the elements on 2’s right branch will be drawn first, and then 2 will be drawn. To keep things the same we add our three new elements 133, 134, 135 in a linear manner onto the right branch as well. This way if 2 is visible, entire right branch will be drawn, and then 135, 134, 133 and 2 on the way back. If 2 had a main branch coming off the left, we would have attached our new elements on that branch to keep the drawing order correct. If 2 had branches coming of both sides, you would need to look at some elements in the branches to determine wether to put the new elements on the left or the right, or even further up the tree.

Enter the new tree into your SEQUENCE area in the text dump and test it in game. If all has gone well, there shouldn’t be a rendering problem in sight! Any other new elements that need to be added can be done in the same way.

This example was pretty easy because we could use our existing element (2) as a base for attaching the new elements, and we knew that they would render perfectly because of this. If your new element is has a vastly different plane to it’s parent, you will have to scour the 3dz for the correct place to add the new element.

//**Creating a new RS from scratch.**// If you think that you have the basics of RS worked out ok, you may want to try the next level of creating your own RS from nothing. WHY!! Well, for an example, take the HR P47C. A 254 element 3dz split into six 3dz’s all with 254 elements, and only perhaps 40 of them being used and the rest drawing processing power. It has to be more efficient to have all the unused elements deleted, but that’s a minor consideration. The main thing is that if you want to add on extra elements you have to delete some unused ones first and adjust the RS accordingly, so why not delete all the unused ones, as they just get in the way and make things more complex? The main reason why not, is of course that it’s bloody hard work, but it can be very worthwhile.

HR aircraft are surprisingly easy to draw up a new RS, because they have few elements, and very few of these element clash. Most wings are straight forward (except for perhaps the landing gear), and most tail sections are straight forward, with only the elevators that must appear over everything else. Also as most HR aircraft 3dz’s are mirrored left and right, once you have a working RS for say, the left side, you can use exactly the same RS tree structure on the right side. The F.3dz is the killer not only because of it’s complex structure, but also because of the hardpoints for attaching extra 3dz’s and hardpoints. Despite these difficulties, it can be done if you have the skill and the perseverance.

First make a backup of your ‘guinnea pig’ 3dz and use Gurney’s 3dz Studio to cycle through the elements, and hit the ‘Delete Entire Element” button to get rid of any elements that are Null and have no data. Save the 3dz and convert it to text. 3dz Studio renumbers all the elements, normals and sequence lines for you, but it doesn’t always put the sequence back together the way it should be. Some branches can get cut off, and of course they won’t draw in game like that.

On a sheet of paper write down the element numbers you have left, listing them into groups of separate structures (e.g. top wing, landing gear, top elevator etc.) Make a special note of any elements/structures that have special drawing requirements (on top of this, but behind that), and also note any elements that will have no particular drawing requirements (always draw everything else on top of this).

The first job is to find the root element. It can be any element, but ideally you should look for an element that divides the model neatly into halves. From there you have to piece the tree together in a logical way. If you have seen Gurney’s explanation of how the tree is set up in 2D, this may help you visualize a solution. I don’t think that there is a way that I can explain how to do it, but with more experience and experimentation, you will soon get a grip of how things should be put together. I have found that sometimes if you ‘sleep’ on a particular RS problem, a solution may present itself with further thought. Then again, you may just go mad!! If you look at the original RS tree, it’s structure may give you some clues as to how your new tree could be constructed.

//**Bug hunting - CTD’s and missing elements.
 * //If you test your 3dz in game and you get a CTD as soon as the aircraft needs to be drawn, then you have a problem in your Sequence section. Usually it means that you have accidentally used a number twice, creating an endless loop which the computer cannot leave so it crashes. Manually recheck your tree and the way you have entered it into the text dump until you find the problem. Sorry, but there are no clues to track down exactly where the problem is!

If you have an element that doesn’t display or even better, a series of elements that don’t display, then their branch has been ‘cut’ with a 255 somewhere. Once again recheck the tree you have drawn and the Sequence in the text dump, working your way from the problem element upwards until you find the S### that breaks the link, and then join it back in again.

If the RS is correct, another cause of elements that don’t display can be incorrect normals. If the first three points of the element’s data make a straight line and not a polygon, the calculated Y Z and X values will all be 0. If this is the case, you will need to copy the Normal in from a previous 3dz, or delete some points to get a polygon so the normals calculator can work correctly again.

If your elements display with no RS problems, but the normals still appear to be incorrect even after you have run the 3dz through a normal calculator, check that the F value of the normal is correct. Make the necessary changes and run it through the normal calculator again (see the Check the Normals F value section).

//**Conclusion.**//
 * //Hopefully you have learned the basics of making RS mods to 3dz’s. It may seem a steep learning curve at first, but with experience and experimentation, your confidence and skill will grow. The main thing is to remember that RS mods are NOT impossible, and with perserverence you should be able to tame any RS issues which arise. Good luck! //**

Thanks to Alessandro Borges, Paulo Morais, Gurney and Moggy for passing down their RS knowledge. Alessandro and Gurney for their brilliant 3dz Studio! Programs. Thanks also to all who have sent me 3dz’s with RS issues to solve. Practice is very valuable.//**
 * //Credits.

20th August 2005. jdmasters@ozemail.com.au //**
 * //John “Chompy” Masters.

Lets