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