Hi all,

I am trying to write a program to generate a Rendering Sequence Tree for F-15 Strike Eagle III models, and I think this would probably be easy to adapt for EAW since the file formats of the two games have some things in common.

Is Gurney's Rendering Sequence Calculator, dated 24-11-2004, the most recent/best tool that is currently available to do this? I read in another forum post that it has trouble with larger models.

Are there people here, or are there other forums where I might find people, who are able to discuss the algorithms for generating the tree?

Does anyone have access to a Linux computing cluster I could try running my tools on? My tool can currently generate a RS Tree for a simple model with 52 nodes and 21 elements in under 1 second, but for a more complicated one I have let it run for hours and eventually given up! I am confident that it will actually finish eventually though.

Regards,
David

Hi David.

There is no real big bug with the current RS calculator.

It just does not like models which are built a long way off the zero point.

This problem came to light, when I was building a model of a Zeppelin. The front and rear sections were a long way off the zero point, because they were hard pointed to the tubular centre section. When the RS calc was run with the front section, as built [a long way offset from the centre] the RS calc fell over, but if I moved the centre point to the centre of the actual model I was working with, then it worked normally.

So, is it a bug or not? I now know how it works, and I have made some very complicated models with this RS calc.

That's good! I guess I had assumed there was a problem because you showed an example of an unsuccessful run of it in your "Is anyone interested to.............................." thread - I figured you might have showed us that since you expected we might see it



Why is that, are there rounding errors or something?

Thanks,
David

Are you sure that there is at least one possible BSP solution for that model.

Try doing this one to see what I mean.

or


Normally when making a model, one starts by looking at how the 3D space is being cut up to get clear in the mind that the model being created does have a possible BSP sequence. It is a visualisation in the mind as the model is being built. If one has done it properly, then the very first sequence attempt that the BSP (RS) generator tries will be successful and should only take a second or two.

Do the BSP tree in your head for that problem model and see if there is actually a solution for it, before you suspect it is a lack of computional power for your program.

Regards Syddy

I am trying to re-generate the RS trees for models that came with the game (i.e. F-15 III), so there should be a possible sequence So far it looks like I have something like rounding errors - when calculating Ax + By + Cz + d to determine whether a vertex/node is above/below/coincident with an element's plane, there is obviously some tolerance for the "coincident" case (i.e. the equation need not give exactly 0) but I don't know what that tolerance should be. For one model, to get my code to think that the original RS tree was correct, I had to increase the tolerance from +/-8,000 to +/-16,000. I can only hope that by running this over all the models that came with the game, using various values, I can work out what the correct value should be, and there aren't in fact different values for different cases

Thanks,
David

I don't know if the BSP(RS) engine in your game is the same as in EAW, but in EAW there are things called piggyback polygons. These are polygons that appear twice in the BSP sequence. The reason for this is because a model was created (by slack model creators) that did not have a working BSP sequence and it became necessary to introduce the rendering of that polygon twice to cove up visual anomalies.
Are you sure your problem model is not using piggyback elements. If it is, then maybe that model actually does not have a working (possible) BSP sequence and you program is just going on forever retrying over and over all possible sequence.
Regards Syddy

EDIT: when I said "polygons that appear twice in the BSP sequence" they are actually 2 seperate polygons sitting in the same area of the model representing the same surface of the model, but are in different areas of the BSP sequence.

You are using double precision floats in your program I hope?

G'day,



I haven't noticed anything of this sort yet. I assume that none of the models that came with either F-15 III or EAW have this problem as in both cases the people making the models should have had access to the correct tools Of course this leads me to the question: didn't the source code for EAW, which some folks have, include the source code for an RS tree generator or something?



Since the data in the file is stored as integers, I am doing calculations on integers too. I am using 32-bit integers which should be fine since the values in the models are all within the range -2048 to 2048 (i.e. should fit in 12 bits) and even if I multiplied three such co-ordinates by a maximum 16-bit signed value as stored in a normal vector, that wouldn't overflow.

Thanks,
David

I can not state with 100% certainty, but I thought there were original models from within EAW that did use Piggyback elements.

Can one of the other members confirm or deny this please.

No, there was no source code for any form or RS generation with the source code that I know of.


It may be that I was not very clear in what I meant.
Single precision integers would be fine. What I am saying is when doing calculations, these integers will be automatically converted to the largest number system being used in the computation. If the largest number system being used is a standard float then the results you will get is a single precision floating point result. At shallow angles this is not very precise. You want to force all values to be double precision floats. this will give you much better precision.
Also make sure you are using double precision trig functions.

Regards Syddy

Memory is tricky, but I recall John (Col. Gibbon) pointing out some use of piggyback models in the original EAW.

Before use of the calculator, the BSP Tree (rendering sequence) was a horror to deal with. How "Charles" and others did it is a wonder.
I recall Moggy posting pages of his long, long, R/S calculations by hand.
So piggybacks were commonly added as a 'fake' solution to most models. Their success depended on how well the piggyback followed the R/S already set up. Some kink could be found in most models.

Which is why Gibbs insists there be no piggybacks when trying to run the R/S calculator.

Hi Guys.

The original EAW models, did on occasions use piggyback elements, with -32768 in the Normals. One of these is in the tail of the original B17 model, where two elements are duplicated to cover up an RS glitch. I guess Gurney's calc is a bit too precise, and that is good, because it forces you to build a clean model. If you, on the other hand take a look at Will's RS calc, this will deliver an RS result, on almost any model, but it will not be 100% perfect. To date, I've never had a bad result from Gurney's program, so I guess it's better than the original MPS calc.