Weird stuff

[Master_Xan]

Alright, maybe I'm doing something dumb, but I can't get this working, so I have to ask.

 

The mission: import models into Rebellion.

 

I checked out the importer, thought it would be easier then using the other method (ResHacker and manually replacing resources). Downloaded the importer, unzip, set it all up as instructed. I run it, and it seems to go just fine. Load up Rebellion, and the old models are all still there... hmm. Go back to the importer, run it a few times with various models, replacing different ships (taking care to empty the Import folder after each one). Same as before, all the originals.

 

Okay... this isn't working. So I try the original method, using ResHacker. After a couple hours of tinkering, I figure out how to get it to show up correctly (although RebEd crashes when I view the model there). However, no textures! That's no good, must be doing something wrong... upon closer inspection of the tutorial, I can't find the location of the texture resources (the writer, is it The Mask? didn't know the location at time of writing).

 

Okay... this isn't working. BACK to the importer, and I go over the installation instructions with a fine-tooth comb. Again. Sheepishly, I realize I didn't put ResHacker's files into the importer's directory... do that, and it looks like the importer did something! I have a log file now! Load up RebEd, and it doesn't crash! Looks great! Load up Rebellion... and I get a ship model! With a texture! That also includes many purple dots! It's just grea- purple dots? What??

 

Does anybody know why I get purple dots when using the importer? They show up with the Dominator Interdictor model, by the Mask. Other models don't have the dots, but they all have one defect in common. All the models I import "vanish". What I mean is that any protrusions from the ship (say, engines, gravity wells, or even reverse dips, like hangar bay entrances) "vanish", sometimes half-visable, other times not at all, or all visable. This happens when I rotate the view in a circle at any distance. The main body of the ship remains visable at all times, and other, unmodified ships are unaffected. Its... eerie, like a ship with a cloaking field on the blitz. Particularly with the Dominator, as it's all mis-colored, and has so many cool looking protrusions and hangar bays that half the ship is in flux.

 

Basically, I've given up on importing until somebody can tell me something. Which is not good, because the RR project will probably require me to import new models at some point for testing.

[Mad78]

Well the vanishing is due to Rebellion's Z-Buffer which is hopeless. But its normal for that to happen. It all a hidden face problem which i never really understood.

[Master_Xan]

Hmm... so the vanishing thing will happen with every model I import, and there's nothing I can do about it? I don't suppose somebody could explain the Z-Buffer thing to me, so I at least know why?

 

I hope that doesn't hold true for the RR project, as its really not much better to have nice-looking models that are in flux then just having the original, low-quality models.

[Krytos]

Ok, I'll try to explain it as best as I can. First I'll talk about what the z-buffer is.

 

In the 3d world, you have 3 axis. X, Y and Z. The Z axis is in essence the "depth" axis making objects 3d.

A 3d model is made up of a lot of faces or polys - which can be considered as flat 3 sided faces. Each face needs to be "rendered" to be viewed. The fewer faces, the quicker it is to render the model. Games need to render each frame - so the fewer polys the higher the frames per second you get.

 

Now, the game engine will only render the faces that can be seen, which is called backface culling where faces you can't see (genereally at the back of the model) aren't rendered.

 

A Z-Buffer is something a 3d engine has that stores data relating to the distance between faces on the model. The idea is that the z-buffer helps decide which faces are hidden behind other parts of the geometry and doesn't render them.

Now, in the case of most 3d games, there's something called Z Fighting. This is dependant on the size of the z-buffer as well as how the model is made. When there are two over lapping surfaces, where one is hiding the other, the z-buffer tells the engine to hide the one behind - however, if the buffer is to small or is overloaded (say by viewing a highpoly model) the engine and buffer get confused about which face is infront and which is behind. This results in these faces rendering at different times, resulting in a flickering look to the model.

Newer game engines still suffer from this, though have much better z-buffers and engines as well as models designed to not suffer as much from this problem. If you play the Warlords mod for HomeWorld 2, you will see z-fighting on Mon Cal cruisers when zoomed out - the edges around the buldges of the hull flicker as the engine tries to decide which face to render.

 

Finally, in the case of Rebellion, the z-buffer appears to be very small (after all the engine is very old an primitive). Which means that it will struggle with z-fighting all the time and even on faces that are at a fair distance away.

So as your viewing the model, the engine is trying to figure out if the face you're viewing is actually infront of the model or behind. And because of the in accuracy of the z-buffer it gets it wrong a lot and doesn't render the correct face all the time.

That's also why if you keep rotating the face sometimes re-appears. The z-buffer is actually sending the correct data at that point in time.

 

Now the bad news. Rebellion's Engine is hardcoded - which means it cannot be modified, and we're stuck with it's poor engine, low level of colours and low output resolution. There's simply nothing that we can do to fix it.

From a modeller's point of view, there are ways to work around Rebellion's problems - all of which are far from full proof.

It's got to do a lot with the way the model is made, the distance between faces and trying to limit overlapping faces in the model. This, in turn, limits the detail that can be put into the model. So, if you want a higher detailed, better looking model, it will be more prone to Z Fighting.

 

For Reloaded, we've havn't been immune to this problem. And have been forced to make the model suit the engine better. To date, several of the designs have been heavily plagued with this problem. Though, with a lot of time and perserverance, they have been fixed - though aren't perfect unfortunately.

Hopefully, as Reloaded gets closer to being released we can go back over all the models to make sure there the best that they can be.

 

 

I hope that explains the problems with Rebellion's Engine and Z-Fighting in general. If I've gone over head with any of this, tell me and I'll try to re-word it . . . try

[Master_Xan]

Nope, not over my head. Simplified, it would be that the z-buffer is essentually acting as RAM, and how much you have (and how sophisticated) determines what the program is capable of rendering at any given time. Z-fighting would be like layers, which the program has to decide which one to display at any given point. Only there are many layers, not just a few. What doesn't make sense is why not having enough buffer space would confuse the z-fighting... wouldn't that just slow down the render? Or make it not render at all?

 

I assume that the z-buffer doesn't act exactly like RAM, and so when it's overloaded it doesn't slow down, but tries to figure it all out, thus sending mixed signals. Or is it the z-fighting that is sending mixed signals when it gets overloaded?

 

Also, I'm glad that the Reloaded team, though unable to fix the problem at it's core, is at least doing what they can for it.

[Krytos]

You've pretty much got it right.

A buffer is a pocket of memory - virtual (paged on your harddrive) or physical (stored in RAM). In the case of the z-buffer, it's storing in effect coordinates of the faces. The z-buffer has a fixed size, and can't increase past its maximum. Force Commander had a 32-bit z-buffer, we have no idea the size of Rebellions - I'd be assuming a very low figure, like 2 bytes or 8 bits even. 32bits of data isn't that much - it's the deafult size of a integer in programming when programming in a 32 bit environment.

 

So, think of it like this - you've got two faces overlapping, and the z-buffer is storing their values as 10.1115 and 10.1123 (these values are completely random and have no actual significance). As you zoom out, these values would loose accuracy because the buffer is of a set amount and needs to store new data - thus the only way possible to achieve this is too loose data/accuracy from the existing values to allow for the room of the new values. So, the new values would be 10.111 and 10.112 - which mightn't have too much problem. Also in programming, number's aren't rounded off, they just loose the last digit.

Any more lose of precision and you'd have major problems as both are being stored as 10.11, and now the computer doesn't know which face is infront and more or less has a seizure and renders the faces off at random.

 

Now, this is just an anology as I don't know the type of data stored in the z-buffer or the method of storing. I'd assume that the z-buffer stores cooridantes of the faces, or perhaps the distance between faces? I'm not even sure if the z-buffer is for every (ie. there's only a single z-buffer runing) or a buffer per model.

 

Though when applied to a game like Rebellion, and it's practically non-existant z-buffer, you can kind of see how it has problems determining what face is what simply because of a lack of accuracy. A few test I've done to more or less confirm my theory about the z-buffer being the fault (I should note now that this is my theory and it might be wrong - though most things point to it being right), such as importing into the game a model that has these problems, though several times larger. The results where good, most of the flickering disappeared as if the faces had been too close.

That being said, this is not a fix, because the game's space battles occur in such a small area that having mulitple large units would have the ships overlapping within each other and just look wrong.

[Master_Xan]

Alright, that helps clear it up quite a bit. You're unsure if its a buffer per model, or just one buffer, huh? I would imagine per model, as if it was just one then you'd get flickering and fluxuactions on the stock models in larger battles, and I haven't noticed that yet. Although, in larger battles, the fighters aren't visable from the same distance...

 

You're very right, 32bits isn't much at all. If it's that low, I'd almost have to assume its a buffer per ship, as that couldn't possibly hold all the information for fleets of any considerable size, be it coordinates, some sort of framework, or distances between faces. Also, the only bonus I could see for such a low amount of data would be minimal performance loss in large battles, back when Rebellion was put out.

 

This also helps explain why there are three versions of the same model, depending on how close-up you get. Zoom out, and you can't see the details anyway, so no need to confuse the buffer, or see the flickers at all. And model-makers don't design them with less data (thereby preventing face overlaps) because that would make the models just as bad as the original ones...

 

If its hardcoded in, it can't really be changed, and Rebellion wasn't added with extensive mods in mind. Has anybody gone to LucasArts, shown then the progress of Reloaded, and asked for the code to fix just this sort of problem? I bet yes, but I had to ask... though if they asked for the code a long time ago, LA may be more willing now that more time has passed (and with samples of Reloaded, they will take the request more seriously).

[Mad78]

No we haven't though I must admit its a very good idea. We should maybe give it a try. The Problem being that we don't know who to contact.

[Master_Xan]

I'll see if I can't drum up somebody, or scare some poor old programmer out of hiding. http://forums.lucasarts.com/thread.jspa?threadID=100464

[Mad78]

Good. I mean some guys succed in getting Actvision to release the code of Civilisatons why wouldn't we succed with reb.

[Evaders99]

Activision isn't LucasArts ... I thought Activision only did "Civilization: Call to Power" ?

[Mad78]

Call to power 2 I think was the one they released but only under certain conditions.

[Master_Xan]

I assume that if they decide to give us the code, it will have strings attached, and will probably be only for the RR project. But if they decide to just give us the code, I won't complain...

[Mad78]

Got any answers yet?