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.

There is no floating point or trig functions in my code at all - just multiplication and addition to calculate Ax + By + Cz + D. Actually, I am using some C++ vector classes (http://eigen.tuxfamily.org/) to calculate the dot product Ax + By + Cz, but that is all in integers. I can't see that I would need any trig functions unless I'm coming at this from a completely wrong angle

Thanks,
David

Thanks, I'll be on the lookout!

Regards,
David

AHH!!!! my apologies, I am jumping the gun a bit. I was assuming you were doing all the calculations in the one go. The normals and normalizing them to unity.

Here is a link to an open source 3D model editor that I was thinking of converting to do EAW models, but never got around to do it. It is worth having a look at, should you be interested.
http://www.misfitcode.com/misfitmodel3d/

Regards Syddy

Hi Peter.

Please don't try and make another 3dz Studio, when we have a perfectly good one now. All it needs is finishing, by adding in Gurney's RS calc, Will's Normals calc, and Jelly's tools.

Then we have the perfect studio for EAW.

Hi John,

The reason I mentioned the other program was because I have actually tried it.
It is one of the very few 3D packages that work basically the same way as we work using 3dz Studio.
Putting down vertices and then making faces from them. It also has very functional editing capability that are not as clunky and long winded as within 3dz Studio.
I wont be making a new studio any time soon as I just don't have the time with what is going on at home at the moment, but I thought it would be worth mentioning as this new program is a very nice base point for this sort of development.

I suppose I also have a dislike for VisualBasic based programs, as I am a little too old to start to get good proficiency in that language. This dog has become too old to want to learn new tricks .... I have become a grumpy old fart.

Regards Syddy

Ah, there's some important things that Will's version does better.

1 - Adding piggybacks with new nodes. I know, we shouldn't be using piggybacks but they still have a place when upgrading old models.

2 - "Save As" option picks up the file you are presently working on. You don't have to pick the file name from the pop up window thus avoiding accidentally writing over the wrong file.

3 - Color notification if an element has piggybacks.

4 - Option to add a new node or an existing node on the element pop up screen.

5 - Texture pop up screen includes a "see all mapping" button.

6 - The option to outline an element in red rather than highlighting the entire element.



As a matter of fact the only drawback to Will's version is that it can't handle the new action codes.

Since it is superior in so many ways I will continue to use it and then when the model is complete I'll use the other version to add in the action codes.

Hi Ray.

I'm sure those feachers can be added to an updated original studio, with new action codes.

The one thing we desperatly need in an updated studio is making a new RS every time the model is altered, and if the RS can't work, then an on screen warning should be seen, as well as a warning for twisted elements.

Of course, there would need to be an on/off option, for modding old models.

HI Rotton50,

For the benefit of others, some clarification may be in order.

All the versions of 3dz studio are the work of "Gurney".
He created one version that worked in one particular windowing mode and then switched to another windowing mode to continue the development and finish it.
Both these versions had the source code.

The first version had a very nice way that the windows tabs were handled but it was flakey and kept crashing after even very small changes were done to a model.
None the less some people liked the feel of this version, and as such, I just sorted out what bugs I could find, added the extra action codes, and passed the corrected source code back to Col. Gibbon.
Any new work can be continued from this current version if one wants to use this particular version. I am sure some people would like to see this version advanced further, but I just don't have the time or inclination at the moment.

The second version was basically functional, and Will added some useful features to it.
Dealing with Piggybacks is one of the features that I personally believe has no place in any version of the 3dz studio. That feature is an abomination and only breaks any form of RS generation. If a person spent as much time on understanding and using Piggybacks, and spent it on understanding the concept on BSP, then the requirements for Piggyback would no longer be required.
I agree with you that the work that Will did , has produced in general, a better version of the second version of the 3dz Studio, ...... but ......., and it is a HUGE but ( Mmmmm I like big butts)...... he did not leave the source code behind of his version, and as such, if one wants to keep his functionality, it will require the recoding of his features back into Gurneys original second version.

If there is some one in the forum that has an understanding of Visual Basic and wants to do some development on the 3dz Studio, then I am sure Col. Gibbon will pass on the code, and the other members of this community would be very pleased.

Regards Syddy

"That feature is an abomination"

That's a little harsh, seeing as how about 90% of all EAW models with have them and they run with no ill affects in the game.



"If a person spent as much time on understanding and using Piggybacks, and spent it on understanding the concept on BSP, then the requirements for Piggyback would no longer be required."

I adamantly disagree with that statement. There's a big, huge, monumental, colossal difference between understanding the piggyback idea and wrapping your head around BSP.

I learned to make a piggyback in 10 minutes and I've taught it to other interested parties in the same amount of time. Can't say the same for BSP.







Anyhow, if Will's version can't be fixed than I strongly encourage anyone that works on the older version to keep my list in mind. These are worthwhile additions that must be included in any upgrade.

Including the abominable piggyback options, despite Syddy's opinion.

The reason so many models use Piggyback elements is because people have been pulling and stretching already working models into forms that they should not have. This has made some successful models and some very unsuccessful models also.

The reason I call it an abomination, is that it totally can stop one creating a new model.
If one creates a new model it will have no BSP sequence, there is no way one can get a starting BSP sequence in the first place to apply a piggyback onto to get a working model. It is a chicken and the egg problem. One will always be stuck just being able to stretch and warp existing models.
If one knows how to do a model properly to get a working BSP sequence, then there is no reason to have a piggyback as it is not needed.
And if one has the skills to create BSP compliant models, then one does not require piggyback even when one stretches older models, because one can see in their minds what that change will do to the BSP, and one will know how far one can mallform a model in the first place.

All that Piggybacks do is to stop people to learn how to do things properly, and as such, stop people from being as creative as they should be able to become.

Just look at what Col. Gibbon has been able to achieve, and many others.
And if I may say so, VBH has also done some sterling work with his knowledge of BSP techniques.

It is a personal belief , but I still stand by it,"That feature is an abomination".

Regards Syddy

It's a matter of theory vs reality.

Richard Petty was a pretty good NASCAR driver but I'll bet he didn't know squat about the laws of thermodynamics.

If we do it your way, standing on "principle", we should only make models after we learn the very arcane principles behind BPS. Some of us like to do other things besides make models and don't have the desire to learn that. For that reason the piggyback functions MUST be included in any 3dz Studio improvements.



One example to make my point.

I wanted to make a P-47N. Same as the P-47D except for much longer wings.

I attempted to get the R/S to work on the wing but due to limitation in the R/S program it was very time consuming. For one thing you have to remove all the inserts for the landing gear and then move the gear to a "neutral location" before even trying to get a working R/S. When and if you do get an R/S you then have to move the gear back to it's correct location. ( Quite a PITA.)

Then it still wouldn't work so I had to start deleting elements to find the offending one. After chopping up about 1/4 of the wing I said the heck with this. So I stretched the wing, added a piggyback to fill the gap and in a 10 minutes it was done.

I see nothing wrong with this approach.





BTW, I have also made a model from scratch so it's not like I don't have experience with that approach. After every 5 or so added elements you have to leave the 3dz program and run the R/S program or you run the risk of making a model that doesn't pass the R/S and you have to tear it apart to find the offending element.

I just can't see the advantage for most of the EAW models.

I certainly agree that new entirely new models must be done this way but not upgrading or modifying existing models.

Hi Rotton50,

I guess it comes down to if one want to understand the tools, or if one just wants to use the tools available to produce an outcome.

This is the part that I normally have issue with.

If one understands BSP(RS) techniques then that step is not necessary.
One just roughly designs the model with pencil and paper and looks at the parting plains. Then one starts creating the model within 3dz Studio one parting plain at a time to divide space into workable regions.(not one aircraft part at a time as many try to do). One has therefor divided space into safe BSP areas that are isolated from each other. Then and only then does on fill in the regions to complete the model.
If one uses a structured approach and some planning, it is not even necessary to test for working BSP until major parts of the model are done, or until the whole model is done. One only has to understand how BSP works and build the model in a BSP compliant manner. One should be able to build their new model and write out manually the BSP(RS) sequence as they are creating the model without even using a BSP(RS) tool. This is where bulkheads become a very valuable tool.

All the problems you are facing stems from a lack of knowing enough about the BSP sequence, because you can always rely on Piggybacks.

Regards Syddy

Hi Ray.

Wings are very simple models, but to make the RS work, you need to remove the offsets for the folding gear, so it stands in the correct position.

All I do is remove the 1/2's from the nodes for the gear, keeping a copy in text, so I can paste back the folded node positions. Then it's just a question of moving the gear back. Then the only other thing you need to do is replace the bulkhead element in the middle of the wing, and your ready to get a new RS.

Not difficult.

Syddy,

The point is that almost no one wants to be bothered with learning BSP when the other way works. If the other way DIDN'T work 100% of the time then it would have died out long ago and we'd be forced to learn BSP theory.

I mean we've got people playing this game continuously for ten years and there's never been a complaint related to piggybacks. LACK of piggybacks when there is an R/S issue, yes but piggybacks in and of themselves cause no practical problem.

They only cause shivers for theoreticians.




Another case in point.

We have a core of users that have been begging for a hi-res Beaufighter.

I'm in the middle of upgrading the old lo-res model. It will take about week to 10 days and that core group will have something new to play with. To build a new Beaufighter would require months of work in which time I wouldn't be doing anything else.

Yes, it does have some piggybacks but so what? The guys aren't going to know the difference and they don't care.

My method avoids some of the R/S issues by making an empty F.3dz with nothing in it but the hardpoints for the other 3dz files. The F.3dz does pass the R/S calculation thus guaranteeing that the other files will not have a problem interfering with each other. They still can have R/S problems with other parts of the same file but that's where the judicious use of piggybacks comes in.

Of course I give up one file for the skinners to work with but anything up to a standard twin engine model still looks fine. I could post pictures here and you wouldn't be able to tell which of the models used the old method and which used the new method.

I've already updated the DH103 Hornet this way which took a week. Next will be the Mosquito and the ME410.

So in the space of say 6 weeks we will have four hi-res planes that we didn't have before.


I'm prepared to agree to disagree in principle while in reality I wouldn't be happy if the piggyback function is left out of any upgrade. Since I'm the only one issuing new models I should think my opinion carries some weight.

Hi Ray.

You'll find, as I did, you can only piggyback so far, and then you'll reach the point where, you simply can't fix the model without redoing the RS.

I'm working on a case in point now, where cannons were piggybacked onto a wing, and showed though each other, because the wing did not have a split in the right place.

In these sort of instances, everyone who wants to work on models, needs to know how to fix these types of problems.

Absolutely. No argument there, John. I've encounter that same problem.

That's still no reason to chuck the piggyback functions in any 3dz studio upgrade.

Next we'll be reading that EAW 2.0 will have a check to prevent piggybacked models from loading.

Oops, I've said too much.

It's a good thing Gurney bailed when he did.. He'd probably be pulling his hair out by now.



What was wrong with 3DZ Studio again?

Simple. There are some folks that want to do away with perfectly functional parts of the program because it doesn't fit a theoretical ideal.






Kinda like doing away with democracy if your side doesn't win the election.

Some places that happens. It's called a dictatorship.





You think he was pulling his hair out BEFORE. HA!

Hi Ray.

Who said piggybacks were going to be dropped?

In some cases where we are adding damage elements to an existing fully RS compliant model, the use of a simple swap piggyback element is the solution.

So, I see no reason to drop piggybacks from an upgrade of the Studio.

Didn't you read any of Syddy's posts? He wants piggybacks banned from the universe.

The reason I bothered to post is that when one or "maven" here makes a declaration about something arcane like R/S and BSP's it becomes written in stone. I've seen it time and time again and I've found through experience that many times it just ain't so.

I wanted to make sure that all sides of the issue were discussed in detail so if a programmer decides to help out with a new 3dz Studio he would have a comprehensive list of the programs functions.

And ONE guy doesn't get to determine what's allowed and what's not.

Calm down Ray.

Don't bust a blood vessel for a piggyback!

I don't know why you think I'm agitated. I haven't resorted to any name calling or insults or anything that would indicate I was about to burst a blood vessel.

I've made a number of cogent, sincere statements as an experienced 3dz user.

I do note that it's always a trivial matter when it's the other guy's concern.

Hi Rotton50,

I am sorry if it has got you upset. That was not my intention.

All I was saying is that in my opinion Piggyback elements are a big no-no and tried to justify why I have that belief.

Things are always written in stone, but not based purely on what some peoples (my) beliefs are. The writing into stone is done by the up-grader of a program, as he/she will be doing only the work that is of interest to him/her.

As I said earlier, I don't have the time or the inclination at the moment to work on the project, so what I say will have no impact with any person that does choose to extend the 3dz Studio.

Regards Syddy

Oh okay, that makes sense I am just trusting the existing normal values in the models for now. This seems to be a reasonable assumption to make, except for elements that are parts of moving parts - I think they have correct normals, but the constant "D" part is wrong. Is this something that has been observed in EAW? Is this related to:

Are the constant "D" parts of the normals calculated as if the moving part's origin was (0, 0, 0) or something?

As for the argument:

I think that sydbod's approach sounds possible - I think I could make a model that way - but I can imagine an easier way...

I think the below would address this:

I was going to say the same thing myself! In terms of getting a warning when the RS tree can't be generated, I guess we might define "failure" as the tree generation running for more than a few seconds. The warning should probably indicate what element you added to trigger the RS tree generation failure, just in case you've added another element since then, but I gather the user interface probably doesn't enable you to add elements very quickly?

I can't imagine it would be very hard to add this to the current 3DZ Studio - you can just save a temporary .3dz file after every element addition and call the RS tree generator in the background. 3DZ Studio can kill the RS tree generator if it runs for too long and delete any huge log files it may have generated.

Also:

So a piggyback can't be a separate element referencing the same nodes?

How is this done, just by highlighting any element for which there is some other element with the same shape and node locations? Or is there explicit tracking of the piggybacking somewhere?

I'm not sure that that is a good reason to dislike VB. I, on the other hand, used it for years before I learned some better languages, so I think I am fully qualified to dislike it I like the sound of this other tool which runs under Linux - it can't possibly be written in VB But seriously, no offence intended to the VB programmers out there - it does have its place, and there are plenty of things that are easy to do in VB that are much harder to do in C!

One last, kind of off-topic, thing: would "vertex" be a better term than "node"? I have used the term "vertex" in my documentation for F-15 III, knowing that the EAW documentation used the term "node". Or is it like this: a "house" is not a "home" until someone lives there, and a "node" is not a "vertex" until it actually forms an extent of a line or polygon? I just think "node" is a bit too generic; one normally talks about a binary tree (such as the RS tree) consisting of a set of "nodes". Perhaps nobody will care to debate this with me

Regards,
David

Syddy,

I repeat, I am not upset, so no apology necessary.

This medium is lousy for debates like this. We lose so much by not being able to hear the other person's vocal inflections.

This is a hobby for me, not a vocation.




David,

1 - It would be a huge improvement in the R/S calculator if it would tell us which element was causing the problem. Right now you build a few elements and then test the model to see if it's still R/S compliant and so forth.

2 - On the "elements" pop up work screen there is a box labeled "Piggybacks". If there are piggybacks to that element you can scroll through them by clicking the up and down arrow next to the box. In Will's version the box turns bright green if there are any piggybacks. In Gurney's version the box stays gray.

G'day,



My understanding is that, except in a few trivial cases, the RS calculator is often NOT going to be able to tell you which element is causing the problem, except if it tries removing one element at a time. I guess the point is that it is often not one particular element, but a combination of elements that causes the problem. That said, I think the solution where the RS calculator is run automatically after you add each element would help here: you'll be told which element you added that caused the problem, you can try removing it right away to see if it fixes it, and if it does then you can think about what the fix is.

Maybe the RS calculator could allow you to supply the element number of the most-recently-added element to it and it could treat that element as new and unproven. Then, if at some point in trying to partition the elements, it fails because it would have to cut that new element in two, instead of just trying another partitioning scheme, it can fail and tell you which element intersects with your new element so you can consider splitting one of them. Still, I'm not that confident that such a scheme would help much - it might just tell you that every element you add is "bad" because the very first element you inserted was in a bad place.

Perhaps there is no way to make an editor and RS generator that are so smart that you don't have to understand how the BSP scheme works, but perhaps if the editor tells you right away when you've added an element that prevents an RS tree being generated, it will help people to learn. You might get lots of questions on the forum saying "why can't I add this element to this model" but perhaps when the experts explain which other element is causing the problem, people will learn from that? You can only hope!

Regards,
David

Hi David,

You are correct, we (the EAW community) tend to use the term "Node" rather than "Vertex" mainly because very few of us have had any formal training in anything to do with modeling and we tended to use the terminology that was used in documentation left behind by our forefathers. We maybe ???? should be using "Vertex" but old ingrained habits are hard to break. Maybe "Vertex is not the correct term either as we can have the dots or the Node/Vertex/Whatever-it-is standing in free space all by itself. I suspect a Vertex is just a Vertex if it is part of a polygon corner ..... or am I wrong there?

I believe we have the same sort of miss-naming going on with the RS Generator. The way we us it, it is just a BSP(RS) finder, and not a generator. The true BSP(RS) generators will actually produce cuts within existing polygons to enable the creation of working BSP(RS) sequences even if there is no current solution. Needless to say both the rendering engines for both games are limited to 255 nodes/vertices/whatever-it-ises and 255 Polygons so allowing the automatic cutting of polygons is not a viable solution.

Maybe we are fortunate in that we all appear to know what the other person actually means rather than says.

Regards Syddy

Just one more thing I would like to highlight about BSP(RS) sequences.
It is possible to create a model and as one is in the process of creating it, it is possible to get a situation where a working BSP(RS) sequence becomes impossible. As one continues adding to the model, a working BSP(RS) sequence all of a sudden becomes possible again.
EG:


If one were to create the wing and the tail fin first as in that picture, and then try to create a working BSP(RS) sequence, it would fail. Then one adds in a bulkhead from the body of the model, and all of a sudden a working BSP(RS) is possible again.

One may want to think twice about partially building a model and concluding that a construction path is impossible, just by testing for BSP(RS) compliance of a partially built part of a model.

Regards Syddy

Hi doshea.

All of the moving parts of a 3dz have to have to be built in the deployed position. The RS and Normals have to then be generated from the zero point of the model. At this stage you have to ad the offset codes to the Normals and Nodes, and reposition the parts of the model, back to the correct positions. This is because the Offset is normally the centre point of the folding part of the model, from the zero point, and when you add this Offset to the existing Nodes, it has the effect of moving the entire section, like a wheel, way out of position. This s a very complicated topic to try and describe, but I'm sure you get the idea.

Piggyback elements can be a duplicated element which is coded to switch on/off, like an engine panel, damaged and undamaged, or an element which is added to fill a new position on a model. Piggyback are often used to split old elements, to refine the shape of a model. Often you need to add more than one piggyback to cover this new element, so the new element appears to work correctly.

In EAW, Vertex = Points, and recently Nodes has been used. Either is fine by me.

ok I have to ask some questions too


first.. Gurney's rs_calculator: if the calculationen takes up more than a few secounds or say half a minute, does this mean the rs_tree is not calculatable?

is it important which starting Element is choosen when using rs_calculator? or does the program finds a good one by itself?

and: does onybody has succesfully used will's 3dz calc ?
(http://members.fortunecity.com/whb11/GunshipTool/Gunship.htm)
I'm not able to calculate a working rs-tree even from simple testmodels (easy enough that I can think them through myself and Gurney's rs calculator needs just a sec)

Hi Rolin.

The program normally runs in a fraction of a second. If it does not close and produce an Output.3dz, one of two things will happen. Firstly, you might get a failed Output text file after a few seconds [3 or 4]. Or Second, the program will continue to run almost forever, and if you leave it running, you WILL fill up your HD with a massive text file!

The program automatically searches for the best starting element, so you don't need to worry about setting a particular element, for the model to start from.

I've tried it on models that Gurney's RS calculator hasn’t been able to solve, but it has never made a perfect RS as Gurney's does. I've tested all possible settings, but there has always been rendering problems with the models.

Cheers

Hi VonOben.

These models you are having problems with. Are they new ones or old ones you have rebuilt?

I cannot stress to highly the need for care in aligning elements, so you have clear lines across the model.

At these points, insert bulkhead elements to cut the model into smaller chunks.

Make sure all of your elements are flat, and not twisted. It's very common if you have a four of more node element, for one of the nodes to be out of line. Best results come from having only triangles,

These three things will improve your chances of getting a good RS result.

Is there some kind of an tutorial on how to create a working model?

In my eyes it leads to very blocky looking models.. I'll have to make some test but my very simple but natural build and tri-only mig-3 does not compile.

Is it importatnt to have Elements that cut the model along the x-y-z axis or isn't that the deal? just elements that cut the model into halfs

Some example models that where successfully compiled with rs_calculator would be helpful too

Hi rolin.

Here are a few of my models which I have created from scratch using Gurney's RS calc. These are all clean models, which worked straight off in game.











If you look at this model of the Hampden, I have marked in where exactly all the bulhead elements are in this model. You will see how the cut the model into smaller chunks, and therefore make it easier to create an RS.



When the model is finished, the last job is to remove these bulkhead elements, although some will remain as part of the cockpit and bomb aimer / gunners positions.



I hope this help you understand how this works.

The reason the Mig3 model will not work is because these bulkhead elements have been deleted and the landing gear has the inseert codes added to the nodes. You need to remove these codes, and reposition the gear in the fixed down position, and then it should work.

thx!! this is great info

- do you always build in these bulkhead elements .. i know it will help the calculation process.. but this eats up polys and you'r already very limited with 254 elements (i know of the possibility to spread a model over several files)

and I was referring to my own mig3 .. I'll see if i can change the geo of the mig to be rs_calc compatible

Hi Rolin.

If you convert your Mig3 model to text, you will see where the bulkhead elements were in the model.

In the text version, look foe elements section. You will see groups of elements, divided by an element which is simply 255 [Like E098 = 255].

These are the former bulkhead elements, which have been deleted from the model, but still retain a position in the RS and Normals.

I know you might think your wasting elements, but it's really the only way to do it. The good side is building with up to 6 3dz files, it's hard to run out out of elements, because you'll run out of Nodes, long before you'll run out of Elements.

no you still got me wrong.. I'm building the mig in 3ds max and exported it with my own exporter

so there are no bulkhead elements atm

BUT

this info is very important thx!
so a bulkhead element is what? you can define it in 3dz-studio ?! I've seen it in one of the original bf109 lod models I think.. so what does the game do with it? it does only exist of a normal, right? and the placement in the rs-tree ?

is this a piggyback element?

I'm not quite sure I understand this thing.. at which point will the bulkhead-geo (the polygones) replaces by simply the end-of-line-code 255 ?

Hi Rolin.

As your building in 3ds, I suspect your going to end up with one big model, which you can then Davide into several sections.

I normally break the model into the following:

Engine cowling B.3dz
Cockpit section F.3dz
Tail section A.3dz
Left Wing E.3dz
Right Wing G.3dz
Prop P.3dz

OK on to the bulkheads. If you have ever built a card model, you have an internal structure, and external structure. The bulkhead elements are like the internal formers of the model. They just Davide up the model internally. They have no other use than to Davide up the model, into compartments, if you like, in a ship. They just simplify the RS, because the RS calc does not have to try and find the one and only RS for all the elements in a model, it just calculates the RS for the sections.

As I've said before, once the model is finished we just remove the element and mapping, after adding the RS and Normals, by replacing the element information with just 255.

The Element number, RS and Normals for the 255'ed element must remain in the model, or else to RS sequence will be broken.

The Game does not use the element, other than to continue the Rendering Sequence.

Piggybacks, are an element which has a second elements which shares the RS and Normals of it's original element. In most cases it's used to improve an old model, without recalculating a new RS, or Normals.

One thing though, you need to remember to build in 1/48 scale.

I'll be interested to see how this works out.

no, one can build the complete model in pieces in max (wings, body, engine ...) and then select only what should go into the specifc 3dz and export only that part.. this makes aligning quite easy

ok and bulkheads.. so this sounds great... have to test it soon.. this could realy make the deal..thx.. you're realy a source of great information!
only drawback is, that I can not include this into the exporter cause you have to do it by hand after rs_calc..
great would be an rs_calc script within max but therefor I had to know how Gurney does his calculation

Hi Rolin.

Clearly you need to build your part models, and export them to 3dz.

Then, assuming the bulkhead elements are there, you'lll just need to run the RS calc, and Normals calc, and add these results to your model.

I presume the exported model will be in 3dz format? This is the easiest to work with, as you'll just need to convert your 3dz to text, to add the results and convert back, and try in game.

Ok my tests didn't came out the way I hoped..

Is it important in which order the Elements are?

so does this work

E1
E2
E3
...
En bulkhead
En+1 bulkhead
En+2 bulkhead

or

E1 bulkhead
E2 bulkhead
E3 bulkhead
E4
E5
...

or

E1
E2
..
E3+x bulkhead
.....
En
En+1
..
En+y bulkhead
.....
Em
Em+1
..
Em+z bulkhead


it seams to me that the rs_cals is starting with element 1 and then proceeds to "grow" the tree.. if it comes into an infinite loop at element 22 it never ever looks up elements faar beyond element 22.. so if all bulkhead elements are at the end of the element-list they are somehow useless

is this true?!

Hi Rolin.

It makes no odds where the bulkheads are.

If your getting an error at 22, then there is a problem in the way you have built this part of the model.

Concave elements will give the RS cals a headache, so try not to have any.

I found this page a useful explanation of generating a rendering tree, but have since come across this page from Gurney himself although I haven't read the latter too much.

Regards,
David

Hi Guys.

I've been in contact with Gurney, and he is looking out his C code for the RS calc.

You might like to read these posts:

http://simhq.net/forum/ubbthreads.php/topics/523407/1.html

http://simhq.net/forum/ubbthreads.php/ub...html#Post504000

This was the thread I was looking for!

This post included input from John Parquin, who wrote a lot of the PAW code.

http://simhq.net/forum/ubbthreads.php/topics/504294/1.html

Read this thread from Page 1.

Some more light reading on the subject of building models.

Only 38 pages!

The EAW Skunk Works thread was where we took Gurney's RS calc, and discovered it was the way you put models together, which had to be done in a certain way. It all seems silly now, but all the in for , which was discovered at the time, is very relevant for anyone who wants to get a new model working in EAW.

http://simhq.net/forum/ubbthreads.php/topics/2130868/1.html

thx for the links.. exp the last one is very helpful but still, I'm just getting FAIL and infinite-runs one after the other for everything more complex then a box... this is really annoying -.-


esp. this makes me laugh

http://img.photobucket.com/albums/v30/ColGibbon/1.jpg
http://img.photobucket.com/albums/v30/ColGibbon/2-1.jpg

Hi Rrollin.

Yes, that sort of silly problem used to cause me hours of scratching of my head, and frustration. Now, I know better, but even now, I still get the odd element that refuses to play ball.

Hi,rollin,

If you can't get a sequence with Gurneys RScalc, you should try Will Baldwin's 3dzCalc. It's a brilliant little program, and it's not overly complicated to use, either. Personally, I like having the 4 options for creating the BSP tree, but most of the time I just choose 1,1,1,1. Don't even have to move the mouse for that-- four clicks in the same spot.

Unlike RScalc, there is cutting&pasting involved in 3dzCalc, though... The horror!

Admittedly, the program ain't perfect. It can create flawed sequences. Non-co-planar Elements are especially troublesome. As the Colonel pointed out, the program works best if all your Elements are triangles (but you don't necessarily have to limit yourself to tris provided that your Ngons are co-planar). 3dzCalc also sometimes has difficulty with models that have relatively few Elements, for some reason. iirc, it won't properly sequence a box.

If you have a basic understanding of BSP trees, there's another useful feature in the program:
You can delete the Normals for Element(s) of your choice, and they won't be factored into the sequence. Those Elements can later be manually added to the 3dz.txt file Sequence Sector wherever you see fit.

3dzCalc also gives the option of choosing the Root Element, which can be very handy in some situations. If you leave the Root box blank, the Calculator will try to determine a Root that gives the best balance to the tree.

I've had tremendous success using 3dzCalc on fairly complex models (including ones with concave areas).

Just another option to consider.

Hi samovar6.

I tried and tried, with Will's RS calc, and always ended up with see through panels, and other errors.

The other thing is Will's RS calc will, as you said produce a result for any 3dz file, but that's not to say the model is built correctly. you could well have RS impossibilities built into the model.

If you check as you build, using Gurney's RS calc, you will be forced by the program to build a clean model, because of the way Gurney's program only gives results if you build in a RS compliant way.

samovar6, I was, like gibbon, not able to create a working rs with it but thanks for the tip!



ok I WAS able to run rs_calc with success.. (and this for itself is incredible)

but..

I only see .. well.. 10 faces of my model ingame (ok their rs is at least correct ) but where are the others? no flickering or something.. my exporter should make no normals-errors.. but to be sure I've recalculated them with wills program.. but still.. (and only the same faces where visible)

is there a way to display the wireframe ingame?
and all faces I see are on one (right) side of the model
in my rs-tree are many elements like S130 255 255 .. could this be the problem? but I though when rs_calc DOES work the RS tree IS correct.

using no-alpha (code 5) elements.. so an strange alpha-bug is also excluded

it's late now so I'm stopping testing for today.. but if anybody has an idea..

Hi rolin.

Did you create new Normals?

? what do you mean with "create new Normals" ?

I have all normals I need.. and I've back-checked with will's tool to make sure my exporter is not the problem.. When I check it again with 3dz-studio (press the "recalculate"-button) I get the same values too

Hi rolin.

If you have good RS and Normals, then the model should work.

The only other question is, are you using the Output3dz renamed, or did you convert your model to text, convert the Output.3dz to text, and copy and paste the RS out of the Output.3dz text, into your text file?

The problem is, despite you getting a good output.3dz, these 3dz's are normally corrupt in some way, and do not work in EAW. But, if you cut and paste the Output.3dz RS into your original model, then it should work perfectly.

If your still having problems, please send me a copy so I can see what is going on.

ahhhhhhhhh .. shame on me!!! this is something i knew but had totally forgotten over time

its working now! thx a ton gibbon

I'll try to incorporate these informations into the tutorial I'll have to write for my exporter

but now I have the prove.. I can create an airplane from scratch in 3ds max and get it into the game!

Hi rolin.

Great news!

I'm very pleased you now have the clear road to build in 3ds, after all, it was how the original EAW models were built.

My only concern is how you can easily build an EAW style model, in the correct scale [1/48], and without using to many elements and nodes. My experience of 3ds is, you can make a beautiful model, but use 1000's of elements.

I wait to be corrected.

Hi Gibbon

I've come across this scale thing once .. what's it about?

I simply import an default model (in my case the pf109ef) and use this as reference in the way of size and rotation (where is the front ..)

about the way you make your model.. there is no difference to 3dz-studio EXEPT it's not very easy to create more then one poly(element) that use the same verts (nodes). You have to know what you're doing. (This is something I _could_ make easier if I extend my exporter though)



If someone can't model in an efficient way it does not matter what program he's using.
But in fact I think it's way faster to build a model and make optimizations. these kind of optimizations you have to do to make the model rs_calc ready.
The drawback is it costs a lot of money.. so I think my tool is just an addition to the other EAW tools.. not intended to make 3dz-studio obsolete

(and 3dz studio is perfect to change small things on an working model. )

Ok Model itself works perfect.. have recalculated the normals to tweak them a bit more .. seems my exporter makes some rounding errors but anyway it's hard to notice


hardpoints are working too.. only the default propeller (bf109ef) is producing some RS-errors .. (only the left side of the model: the moment the model points to the right the propeller goes though the left side.. if the model is pointing to the left all is ok .. so it seams to be an problem based on my top-back bulkhead that splits the model into left-right)
but I don't know what is different to the default bf109ef model.. do I have to somehow recalculate the propeller in connection with the new plane model ?

-.- ok here we go again.. after some more tests I've stumbled over the scale-bug.. I have an simple model (48 elements with bulkheads)

if I scale the model.. even just a very tiny amount it doesn't work anymore (like the fort you've done gibbon..)

but I've scaled in max.. and may values are still lined up perfectly.. but to be sure I've aligned points again .. but still.. rs_calc can't output the model, recalc the normals .. no effect, load into 3dz-studio and save .. no effect

this is so absolutely strange that I hardly know what to say

Hi rolin.

OK, DON"T PANIC!

Rescaling, changes everything, so the first thing to look at is concave elements. Because when you change sizes, some round up, and others round down, in and out too, so you need to look very carefully. I'll bet you have at least two elements, [a mirror of each other] causing the trouble.

I normally these days build in half profile, and then mirror the sides, then join them together. Working that way you half the chances for errors, and don't have to map the second side.

I'm sure you'll find the offending elements and put the right.

no I'm quite sure this is not the problem bc:

I just have triangles
I've doublechecked that everything is ok again concerning the aligning

but

I have no created new (better) bulkhead elements and now it does work.. WHY the other (unscaled) model does work with the bad bulkhead elements is confusing non the less

man I have no idea why I'm still working on this : )

Hi Rolin.

I ask myself the same thing, almost everyday. But, I guess the old lady keeps throwing up new challenges all the time, and just when you think you know it all, there is always something else to add to the knowledge base.

Hello Rollin,

since the node positions are integers, any rescaling will cause a distortion on all elements when the values are rounded off. In the worst case an element may no longer sit in the right position compared to the other elements and the previous BSP tree may no longer be correct.
It's adviced to recalculate the r/s after rescaling or make sure that the node positions are in the same relative position as compared to the node positions of the original model.
This is quite a timeconsuming undertaking but necessary if you do not wish to compromise the shape of the model. The more complex the model, the more severe these distortions can become, some very small elements may even completely disappear when their node positions will be calculated to be in exactly the same spot because of rounding off. Increasing the size is less problematic then decreasing, also because of the minimal node distance you can use in EAW, an element using minimal node distance allready, will completely disappear when only one node will occupy the same spot as another in an element.
Also after a rescale the normals need to be recalculated since the node distance from the centre has changed.

VonBeerhofen

vb: thx for dropping in, jea thats what I've read in the loooooooong thread gibbon posted earlyer.

but I'm very sure this is an 3dz-studio problem .. not related to max bc max uses intern a way more detailed unit setting then what I finally read out. (though you can never be sure so I always check alignment again)

so to make it clear again.. I'm NOT working with 3dz-studio of any version or modification


So I'm always happy for every kind of help but general tips are normally more helpful then program specific ones



btw: is it important or does it have any influence in which direction the bulkhead elements point (normal) ?
EDIT: and the size ?

Hi Rolin.

The bulkheads normally cut the model in the vertical plane, but sometimes you'll need one in the horizontal plane on rare occasions.

Think of a ship, with it's watertight compartments, and you won't go far wrong.

you don't need to build in a full shape bulkhead, a 4 node flat rectangle is more than enough to get a correct cut in the RS.

If your going to add a hard point, you need firstly to add an element which covers the position where the joint will take place.

Joining things like wings need very large cutting element, which cover all of the side of the fuselage. To this element you piggyback the hard point. Once you have finished the model these large elements can be deleted, leaving only the hard point to use the RS and normals.

ok then I'm not doing something wrong.. thx again gibbon !!

I'll be off now for a while until I'm able to calculate the rs in max (or at least build an check-rs-button)
I simply don't have time and nerves to waste it with endless trial and error

Thx so far.. you was a really great help!

Hi rolin.

I hope you get this going, because it might be a way for others who use max to build models for EAW. I'm not a fan of 3ds, because I don't understand how it works to well, but if you get your converter working, you can teach me all the new tricks.

Hi, Colonel,
Well, if 3dzCalc don't work for ya', it don't work for ya'. Sorry to hear that. There doesn't seem to be much (any?) support for the program here, so I guess it doesn't work for a lot of folks. It almost makes me wonder if Gunship! handles the RS differently than EAW. Extremely unlikely, imho, but I suppose I can't entirely discount the possibility.

Not to put too fine a point on it, but I DID state that 3dzCalc can create flawed sequences. It's been my experience that such bad sequences are often relatively easy to correct manually in the 3dz.txt file. It ain't always easy-- but more often than not it's very little trouble. Occasionally (and infuriatingly) no amount of tweaking the RS will help because, as you correctly pointed out, 3dzCalc will supply a sequence even if it's impossible for a given model to have a working one. That's the most frustrating part about using the program for me.

While 3dzCalc definitely has its flaws, I don't think that it's entirely useless.

Here's an example. I don't know whether you'll consider it trivial or not. The first 2 pics are from 3dzStudio, and the 3rd and 4th pics are of the model in GS:









Spare me the Freudian interpretation of the shapes in the model, please.

There are 252 elements in the .3dz. All triangles. There are no bulkheads, no duplicated polys, no Piggybacks, and no Nulls. As it is, the wireframe cannot be processed by Gurney's RScalc. I used 3dzCalc (Root box blank, Options 1,1,1,1) and got a working RS the first time. There was no need to manually edit the sequence at all.

You may argue that had I built the model piece-meal with bulkheads and ran RScalc at various stages that I would've eventually got an RS-compliant model. That's likely true. Far be it from me to criticize that approach to building .3dzs. There're no worries about RScalc fobbing off a bum sequence on you like 3dzCalc can do at times, and you never have to get your hands dirty in the RS sector of the 3dz.txt file.

Sometimes, though, it's a whole hell of a lot easier and quicker to build a complete model and deal with the sequence after the fact.

Es muy interesante para mis proyectos de lo que ustedes estan hablando.
Lamentablemente no logro interpretar algunas cosas correctamente debido a que no hablo ingles, solo castellano.

El problema que ustedes hablan es el que se produce cuando un elemento posterior se superpone con un elemento que esta visualmente mas cerca?
ejemplo, dentro de un 3dz "W.3dz", hay un tablero sobre el ubicamos un instrumento, pero al probarlo al eaw el tablero se ve pero tapa al instrumento, es eso de lo que estan hablando?
----------------------------------------------------------------------------------------------------

It is very interesting for my projects of what you are speaking.
Regrettably I am not able to interpret some things correctly because I don't speak English, single Castilian.

The problem that you speak the one that takes place is when a later element is superimposed with an element that this visually but close?
is example, inside a 3dz "W.3dz", a board on the we locate an instrument, but when proving it to the eaw the board you do leave but does it cover to the instrument, is that of what you are speaking?

Hi samovar6,

It is a most interesting sample you have created.

Have you done a manual check on that RS sequence and see if it is truly a working RS sequence.
From what I can only crudely see from your model, a true working RS sequence is probably impossible.

Something that has many smooth continuous coupled surfaces is not a good measure of a RS generation program.

To demonstrate what I mean, create a cube or a spherical shape with many polygons. There is only 1 true possible RS sequence for this sort of shape. Every polygon has every other polygon behind it.
The only true RS sequence would be a starting polygon (any one of them) followed by any randomly selected polygon behind it, followed by any remaining random selected polygon behind that, followed by ..... until the straight line BSP tree is finished.
Any cube or spherical shape will now render properly with a true PROPER BSP(RS) sequence.

NOW: with the same model make up any random WRONG BSP(RS) sequence for that cube or sphere.
See if you can force that model to render incorrectly in either EAW or Gunship.
Please let us know if you can achieve a corrupted model this way for a cube or a spherical object.

I suspect this little test should give you some insight about BSP(RS) and certain exceptions that don't require proper BSP rendering sequences.

There are many of these strange quirks that one detects, but only after playing with BSP(RS) sequences manually within the mind, and seeing how it all ties together.

Regards Syddy

Hi samovar6.

My crittque of WB's 3dz RS program was based on my experience of using it.

Here is an example:

My new Typhoon wing.



This is the RS as created by Will's RS Calc, which produces holes in the model, which would need to be repaired by piggybacking.

;the first line is the start point of rendering sequence
S000= 2 0
S000= 34 255
S001= 46 255
S002= 4 78
S003= 1 255
S004= 255 255
S005= 255 255
S006= 255 255
S007= 255 255
S008= 26 47
S009= 35 45
S010= 37 95
S011= 255 255
S012= 102 51
S013= 255 255
S014= 31 255
S015= 255 255
S016= 18 80
S017= 88 16
S018= 255 255
S019= 20 255
S020= 24 84
S021= 23 255
S022= 32 90
S023= 22 255
S024= 255 255
S025= 255 255
S026= 255 255
S027= 255 255
S028= 255 255
S029= 255 255
S030= 29 57
S031= 30 13
S032= 255 255
S033= 25 255
S034= 65 255
S035= 255 255
S036= 76 255
S037= 255 255
S038= 255 255
S039= 255 255
S040= 75 0
S041= 255 255
S042= 27 44
S043= 255 255
S044= 43 61
S045= 5 42
S046= 15 55
S047= 53 59
S048= 255 255
S049= 255 255
S050= 255 255
S051= 11 14
S052= 255 255
S053= 255 255
S054= 255 255
S055= 12 255
S056= 255 255
S057= 93 101
S058= 255 8
S059= 28 33
S060= 255 255
S061= 62 255
S062= 63 40
S063= 255 255
S064= 70 255
S065= 7 66
S066= 67 79
S067= 255 255
S068= 39 69
S069= 52 74
S070= 41 68
S071= 72 255
S072= 94 3
S073= 38 71
S074= 60 73
S075= 255 255
S076= 6 58
S077= 99 255
S078= 49 83
S079= 85 96
S080= 54 64
S081= 255 255
S082= 255 255
S083= 81 10
S084= 82 17
S085= 255 255
S086= 255 255
S087= 255 255
S088= 255 255
S089= 91 19
S090= 56 89
S091= 255 255
S092= 255 255
S093= 255 255
S094= 255 255
S095= 48 77
S096= 92 36
S097= 255 255
S098= 255 255
S099= 86 103
S100= 97 104
S101= 50 9
S102= 255 255
S103= 98 100
S104= 87 21

This is the result as generated by Gurney's Claculator, which works perfectly.

[SEQUENCE]
;S000= Back Front
;the first line is the start point of rendering sequence
S000= 8 0
S000= 255 255
S001= 3 11
S002= 255 52
S003= 255 255
S004= 49 59
S005= 255 101
S006= 58 78
S007= 255 255
S008= 15 64
S009= 50 44
S010= 255 255
S011= 13 42
S012= 255 102
S013= 255 255
S014= 16 77
S015= 27 1
S016= 17 255
S017= 18 255
S018= 255 255
S019= 255 20
S020= 255 21
S021= 255 22
S022= 255 23
S023= 255 24
S024= 255 25
S025= 255 28
S026= 34 255
S027= 33 19
S028= 255 29
S029= 255 30
S030= 255 31
S031= 255 32
S032= 255 255
S033= 255 26
S034= 46 255
S035= 255 51
S036= 86 56
S037= 90 255
S038= 39 53
S039= 60 255
S040= 255 41
S041= 255 61
S042= 45 9
S043= 255 255
S044= 43 35
S045= 255 255
S046= 255 255
S047= 93 92
S048= 83 255
S049= 255 255
S050= 255 255
S051= 255 0
S052= 255 38
S053= 255 54
S054= 255 255
S055= 94 47
S056= 87 5
S057= 255 255
S058= 36 88
S059= 7 80
S060= 255 255
S061= 255 62
S062= 255 63
S063= 255 65
S064= 40 14
S065= 255 66
S066= 255 67
S067= 255 68
S068= 255 69
S069= 255 70
S070= 255 71
S071= 255 72
S072= 255 73
S073= 255 74
S074= 255 75
S075= 255 255
S076= 79 255
S077= 95 6
S078= 48 4
S079= 81 255
S080= 10 2
S081= 82 255
S082= 99 255
S083= 84 255
S084= 255 255
S085= 76 37
S086= 96 255
S087= 91 255
S088= 255 55
S089= 255 255
S090= 104 89
S091= 255 255
S092= 255 85
S093= 255 255
S094= 255 255
S095= 255 255
S096= 97 255
S097= 98 255
S098= 255 255
S099= 100 255
S100= 103 255
S101= 57 12
S102= 255 255
S103= 255 255
S104= 255 255
[END]

From memory it should actually be



For the benefit of those that want to check the RS sequences out manually.

When the text converter was created, it appears that the relative positions of those entries for that text line was created back to front.

Hiya, sydbod,
I've read about the cube/sphere sequencing phenomenon before. Thanks anyway for the tip. You'll forgive me if I don't trouble myself with the experiment that you suggested.

I completely agree with you that "Something that has many smooth continuous coupled surfaces is not a good measure of a RS generation program." I really didn't want to spend much more than 10 minutes creating an example model. (Lazy bustard, me) The torus happens to be a primitive in the modelling program that I use, and I was pretty sure that passing a few polys through it would give RScalc an aneurysm.

As far as the example's RS goes, you may well be correct. Perhaps it is impossible. I can't understand why that would be so, but I'm willing to take your word for it. The model APPEARS to work fine in-game on my machine. Maybe I'm not looking hard enough for rendering issues?? If they exist, they're damnably difficult for me to see. That's definitely one of the drawbacks when using 3dzCalc-- it doesn't let you know if the sequence is impossible. And, no, I didn't manually check the RS. How do you go about that? I've got zero desire to draw a 252 Element BSP tree on paper, and significantly less than zero desire to make mental comparisons between all of those Elements' positions in the 3dz.txt's Sequence Sector. When I can't see anything wrong with the thing when running it in my game, what's the point of that?
You're more than welcome to take a gander at the .3dz and manually check the RS yourself if you like:

download psychedelic doughnut

Today, I remapped the model in a manner that I thought would make any RS issues much more obvious. (Another 10 minutes down the drain, damnit!)
It now looks like this:


GS models are significantly larger in scale than EAW ones, as you probably know. If I had to guess, I would think that you should be able to view the thing in EAW, but I dunno for sure. If you have any problems, let me know and I'll try to reduce the scale of the model. (See VBH's post in this thread on the perils of re-scaling.) I'm kinda' in a bind regarding the scale. If I were to make the model much smaller, it'd be very difficult for me to detect any RS problems in GS.

*****
DISCLAIMER:
The whole "due diligence" thing an' all that.
(My mom always wanted me to be a lawyer.)
I don't have EAW. I went as far as to visit a Previously Owned Games store at my neighbourhood shopping mall today to see if I could find a copy of EAW. No such luck. Less than 48 PC games in stock (If my Grade Two arithmetic skills are still serving me correctly). Looking for a PC version of "Trophy Bass 3d?" Have I got a store for you!

There were about 9854 copies (estimated) of various games for something called X-BOX-- whatever that is.

I tested this model on two computers with three different operating systems. One machine with an ATI card and one machine with an INVidious. WinXP, WinXP PRO Corporate, and the ol' timey Win98. No rendering issues as far as I could tell. Then again, these ancient eyeballs ain't what they used to be.

And then again, again-- I don't have EAW so maybe none of my ramblings should be of any concern to you.

If you don't believe me that this thing works on my machines in GS, maybe you could find a trial copy of GS somewhere to test it yourself. There's a .3db file of the model included in the .zip if you're willing to do that. Or, even easier, you could nag Stratos or Spitty to test the model in GS for you. I think that they both love doing that sort of thing.

END DISCLAIMER
*****

If there's something theoretically wrong with the RS for this model, I'd be quite grateful if you could explain it to me. Never too old to learn a few more tricks, and all that. (Not entirely true, that. Still can't get the hang of "The Man on the Flying Trapeze" with my yo-yo, despite years of trying.)

If I'm not failing to spot any rendering issues in-game, and the RS is theoretically impossible, an interesting question is raised. How do I tell my game's .exe that it can't be displaying this model?
*****
*****

Hello, Colonel,
Yep, you're always better off trying to get a sequence with RScalc BEFORE resorting to 3dzCalc. I've tried to make it abundantly clear that 3dzCalc has shortcomings. It definitely ain't everyone's cup of tea, etc.

Nice wing, btw.

I appreciate that you went through the effort to post the Sequences, but without access to the .3dz itself it's pretty hard for me to make heads or tails of that data.

Moot point, anyway, since you've already got an RS kindly provided by Gurney's program.

Good luck with the Typhoon!


¡Hola!, Ecv56Sera,
You probably weren't addressing my post specifically, but I couldn't tell for certain. The Translator didn't do you any favours. A couple of lines from a few songs by The Clash is the extent of my Spanish, so I didn't know what you were talking about, or who you writing to.
Just thought I'd say "hi" on the off-chance that you were responding to my post.
Didn't want you to think you were being ignored.
I hope the Translator can handle my gibberish.
Cheers!

Hi samovar6.

Perhaps the way Gunship and EAW handle the RS is different, because this is the result I get, using your 3dz, in EAW.

Hi samovar6,

Yes .. the picture that Col Gibbon posted is what I would have expected.

To create a torus as you have, the only way to produce a working RS/BSP sequence for the torus is to start from the outer polygons and work towards the inner polygons, so that the outer polygons are already committed in the RS/BSP sequence and therefor are not being influenced by the cutting plains of the inner polygons. The trouble with that, as you approach using the inner polygons, they start to cut the polygons from the inner triangulated tube.
One also can not start the RS/BSP sequence from the triangulated inner tube because they cut through some of the torus polygons.

It is obvious that Gunship is treating separated meshes as identities in their own right and uses some other means than just BSP/RS to order them. Without the source code for Gunship we will probably never know what the true answer is in that game.

It would be interesting to know if the current version of Gunship is actually using BSP/RS at all, and maybe the format of the file structure is a carry over from before, but some of the data is not needed.

Just for interest, is it actually possible to see any sort of BSP/RS model fault within Gunship. Are you sure that Z Buffer is not being used ?? IE: have you actually tried to create a faulty BSP/RS sequence, and then can physically see the defect in the model??
When I look at the yellow ring in the inside of the torus, the bottom yellow is brighter than the top yellow. This tells me that the normals are being used for light reflection, and therefor correct normals are required. BUT.. I am not 100% convinced that Gunship is actually using the BSP/RS tree to sequence the polygon rendering. It is looking more like Z Buffer operation.

Col. Gibbon, Thanks for running that model through EAW. It saved me the trouble of chasing up all my old disks for EAW and reinstalling it.

Regards Syddy

EDIT: the more I look at the scenery in that torus picture, with the very limited "Far distance" rendering and fog, the more it looks like gunship is using a 16 Bit Z Buffer, rather than the BSP rendering sequence ... hmmmmm ... very strange.

Hi Sydbod.

When Gunship was drawn up, it did not come through the PAW line of development as EAW. Was born though the Kart game, which used the same 3dz system as EAW, but in development it was impossible to engage 3dz artist, as in the two years, since EAW was programmed, most of the 3ds to 3dz tools had been lost. So, Brandon Gamblin decided to improve the 3dz format, and out of that came 3db higher polygon models, with the z-buffer implemented. None of the complications of 3dz, and a simple 3ds to 3db exporter. This is what Brad told me, over a number of emails. Although he has still a lot of Gunship files, he does not have everything, which is a shame for us as we could do with having the better detailed models working in EAW.

You have my humblest apologies for your wasted time, Colonel.
Your screenie forces me to conclude that the RS is, in fact, handled differently in GS. That, and what you mentioned about the z-buffer.

That goes a long way in explaining why I’ve had such success with 3dzCalc, and you guys haven’t. .

I had briefly considered the notion that the two games might process the RS differently, but thought it far-fetched. .3dbs are very similar to .3dzs. Z-buffer or not, the RS Sector of a .3db isn’t just some non-functioning vestige of a .3dz. It’s a vital part of the model, and it’s very easy to botch. Many of the MicroProse models in GS contain RS glitches.

And there I was yesterday worrying about re-mapping the texture to make viewing any possible rendering errors more obvious. Well, it can’t get much more obvious than what’s going on in your screenie. lol.

Honestly I’m dumbfounded! (You can truncate that adjective to just plain “dumb.” I deserve it.)

I can assure you that this whole episode wasn’t just a prank on my part. I believed that the model would work in EAW. It really does work in GS.

@sydbod You were right. It’s an impossible sequence in EAW. Sorry if I wasted any of your time, too. And yes, as I mentioned, it's very simple to get rendering errors in GS models, so the z-buffer ain't entirely foolproof. GS does have a a few lighting effects. Vertex normals (TVNs) are also used.

Hi samovar6,

It is good to see that Co.Gibbon managed to get a bit more background.(thanks John)

Don't worry yourself about time wasted, as none was wasted at all. It is a learning exercise for all of us. Without the source code, it is obvious that people will have to do many trial and error tests before the truth can be determined.

It is a shame that the source code for GS could not be acquired, as it is obviously so much more advanced than that of EAW. It would be a very nice game base code to do a re-port of EAW into.

I know that I (and the other members of this EAW forum) found it most enjoyable to interact with both you and doshea. We have to keep in touch.

Regards Syddy

hey ho.. back again (faster then I thought)

this thread holds an incredible amount of great info

I have to check Gunship ... I don't have a copy of it but I'll try to get one

it's now a lot more obvious why 3dzcalc does work with gunship very well but not with EAW
(will created it for gunship in the first place)


but back to EAW for the moment.

I've been busy the last days and I was able to create an rs-calculator in max.
it has the option to select all convec polys (so you don't have to search for them)
you can specific a preferred cut plane (XY, XZ or YZ) (for planes this should be the plane cutting the model into left/right)
and if the script finds an RS-Loop it does select all polys that cause the loop. This makes it so much easier to debug a model

I'm now going to test the script in real-live-model-making and see if it does work in all situations

it WAS able to calc my basic simple testmodel already though

the logic behind the script is quite waterproof but I havn't tested it yet.. so wish me luck

Hi rollin, You have been busy.

As far as RS/BSP calculators are concerned, there is one unique case that pops up very often and I am not sure if you have allowed for it, so it is worth mentioning.
One can have a situation where more than one polygon sits on the same 3D plane. In this situation, it does not matter what polygon is placed infront/behind what other polygon (RS/BSP wise) for these. It may be worthwhile to have a routine to check for this particular case.
Good luck with your testing.

Regards Syddy

BINGO !!!!

it does work..

it seams my calc is as strict as Gurneys.. but mine does tell you where the problem lies

so now I have to finalize the hardpoint stuff

and something more.. you have the possibility to mark faces as bulkheads and the exporter will convert them to 255 automatically.

the only thing my exporter will not handle are piggybacks .. this is something you have to do by hand or in 3dz studio


edit: hey sydbod, my calculator atm simply puts all polys sitting on the same 3d plane into on of the rs-tree-branches .. maybe it would be better to put an even number into both branches but normally you don't have too many polys on the same plane (if you know how to make good models) so I think it does not make a big difference anyway.. but this is something testing will bring up I guess

Hold on Rolin!

A couple of thongs.

To get a correct result for a hardpoint you need firstly have to have a element which covers the area of the model where the joint will be. Getting your calculator to do that would be a bit difficult, unless you can select which elements must be covered by the hardpoint.

Secondly, automatically deleting bulkheads is all well and good, but it gives you no way back. That is why, I leave them in until I'm 100% sure I'm finished, and then just manually delete the ones which are no longer needed. Once again, some bulkheads are needed as the stump of a torn off wing, or cockpit interior.

What would be great, as you mentioned, is an error report, showing where the RS goes wrong. we have a text dump of Gurney's RS calc, but the readout you get, although does help pin down the error, it's result leave most people completely lost.

hi gibbon,

I'll add a checkbox where you can decide if you want the bulkheads to be removed or not
and of course you don't have to mark them with the "I'm a bulkhead" marker.

And about hardpoints.. why does the element have to cover the whole model? the hardpoint itself does not save more then one vertex/point and the RS-tree can only say (in front of / behind)

so .. does the game use some kind of z-sort for attaching models via hardpoints ?

I'll do some tests anyway.. but thx for the warning

Hi rolin.

Here is an example.



The two elements shown, carry the hardpoints for the joint between fuselage and inner wing, and the inner wing to outer wing. The actual hardpoint position is 0,0,0, not in the middle of the elements, as you might think.

you don't even have to delete those elements. I've had good success with just assigning them an action code that won't show up in game. I use 146 / 4. That's the code to switch the pilot from living, to dead, to bailed out. The game only uses 146 /0-1-2.

hey cool info rotten50,

but that's no problem .. you can assign the action code to the bulkhead elements in max and simply disable the "delete bulkhead" function on export

so everyone can do like he wishes