I would have posted in the map tricks galore, but it wouldn't let me.

Anyway, nothing too special here, I just thought I would share this little transparency test map I made quickly, for those interested.

http://c2s.toshiba-3.com/DLoads/TreeTest.zip

Contents: a working C2 map, the source .max file.

The scene consists of 320 trees arranged in several rows. Surprisingly, even with all of them in view simultaneously, they seemed to develop no major transparency artifacts for me, such as the back rows vanishing from view. Does it depend on the hardware and glidewrapper used, maybe?

In the .max file, you'll find a toggleable modifier for the branch objects, which greatly increases the geometry detail of the branches. You'll notice that enabling it will (or should) result in dramatic increase in transparency artifacts in-game.

Things to try:

1) Simplify the branches further: 2 rectangles -> 1 rectangle
2) Multiply the number of trees, and see how quickly artifacts begin to occur

I did a similar test, but your amount of trees far exceeds mine. I made a tree with 2 triangles, both of them double sided. The trunk was, as in your excample, non-transparant.

I think the game is simply limited to a nuber of transparent faces in its virtual buffer. As soon as we exceed the limit, things start to disappear.
Also note that the number of opponents, having transparent glass, affects this limit as well.

And thanks for this post, you just got me interested in c2 science again ;)

edit: Actually found the scene. The trees each have 5 triangles, 2 vertical ones for the horizontal viewing, and three horizontal triangles for a proper top down view.
I uploaded the scene here

That's a pretty scene.


I'm a bit sad that these artifacts won't let you make a massive forest in C2... but I guess if you wanted to attempt one regardless, your best bet would be to use spruces or other triangular trees, in order to absolutely minimize the number of transparent faces. Compared to rectangles, this alone would double the number trees you could manage (at the cost of monotonousness of trees, heh). Plus, of course "optimizing" other props by turning their transparent textures into actual 3D geometry.

Too bad it's strictly the number of transparent faces that is the decisive factor. If it was the drawn area instead (for example), you could attempt some creative tricks such as making spruces almost completely use an opaque texture, save for a thin strip of transparent bits at the edges.

After further testing:

- Doubling the number of trees shown above was ok (640 trees), but
- Tripling the number of trees was not (960 trees); one group out of three would remain invisible

At this point, I simplified the model from two polys to single poly (two triangles). The result was that ~ 3.1 groups would remain visible, so about 1000 trees... perhaps 1024 - a power of two number.

Reducing the tree models further, into single triangles only, ~ 4.4 groups would remain visible, so roughly 1400 trees - not twice the amount, despite halving the face count.

Lastly, while the trees were in their simplest form, I also tried scale reduction (original -> 10%), and texture size reduction (256x256 -> 16x16), but neither seemed to have an effect.

So can we do an exact count of the number of polygons that can be shown safely?

I would have expected that the texture size would impact the games behaviour on transparancy, but I guess it doesn't...

I wonder if the games texture limit is affected by the texture sizes. The texture limit of tracks is around 400 if I remember correctly. Another limit we could easily test.

Not sure what it should be exactly, as the max number seemed to change as I changed (simplified) the mesh complexity:

- 640 trees of 4 triangles -> 2560 triangles
- 1000 trees of 2 triangles -> 2000 triangles
- 1400 trees of 1 triangle -> 1400 triangles

Go figure... maybe one more test where the rectangles are subdivided instead, in order to increase the triangle count, heh.

<EDIT>

After doubling the polycount of the original trees, ~ 1.2 groups would remain visible. And after quadrupling that, 124 trees would remain visible.

- 384 trees of 8 triangles -> 3072 triangles
- 124 trees of 32 triangles -> 3968 triangles

Since we can see sort of a pattern here, I went ahead and created plane primitives with varying segment counts, applied the tree material and cloned the planes. Results:

- 45 planes of 100 triangles -> 4500 triangles
- 12.25 planes of 400 triangles -> 4900 triangles

While I could be wrong, I'm thinking that we shouldn't look at the total faces count, but the total vertex count:

1400 x 1 triangle = 1400 x 3 vertices = 4200 vertices
1000 x 2 triangles = 1000 x 4 vertices = 4000 vertices
640 x 4 triangles = 640 x 6 vertices = 3840 vertices

The numbers don't match exactly, but that's because the tree counts are really only close estimates. I think they're in the ballpark anyway.

If you create a triangle, that's 3 vertices. Expanding to a rectangle requires only one additional vertex, so your faces count has become 200%, but the vertex count has only become 133%. Each new face costs only one vertex after the initial cost of 3, as long as they're all connected. That's why single triangle trees aren't very efficient use of the limits we have, but it's unavoidable if you absolutely want to maximize the number of separate trees.

On the other hand, the long, fake forest edges I've used are very efficient, in terms of vertex count, and the number of trees present per vertex cost.

Additionally, remember that the vertex count will increase if you break the UV mapping and/or smoothing groups. In fact, I just tested this with the 100 triangle planes I mentioned above; I selected roughly half of the squares, in a checker pattern, and assigned them their own smoothing group. This reduced the number of visible planes in-game to ~ 28 planes, down from 45. The number of faces (before the disappearance takes place) was the same, but the vertex count had increased due to breaking SGs. The outcome was identical if I broke the UV mapping instead.

yes, the texture vertices make sense to me. In fact, the number of texture vertices is leading for the vertex count in carmageddon. (I know this because that's the way I built my exporter) It surprises me that changing the smoothing groups has changed behaviour ingame though. I thought the game would render these without any costs, but now it seems to be that two adjacent faces with different smoothing groups will generate multiple vertex normals? ... anyway, this still very good information and a thing to keep in mind while modelling.

This is best explained in the link Tosh posted a good while back, in the part titled "Welcome to Splitsville":

http://www.ericchadwick.com/examples/provost/byf2.html

The vertex count will typically increase from the number you see in your modeling program, unless you're using one material only, one continuous UV-mapping method only, and one smoothing group only.

As you are posting actual numbers, I should clarify that when I said...

"vertex count had increased due to breaking SGs"

...it was only an assumption based on both what I saw in game and what I had previously learned from the linked article (also assuming it applies to BRender engine in full) - so I myself don't have any real numbers to back it up * such as the screenshot of BRender registry you posted, for example. Feel free to take it with a grain of salt.

Still, I believe it is what probably happened, and like you said, it's possible that the vertex count increases at render time from the number that is displayed in any Max/PT2 statistics.

* Obtaining these would probably require just the kind of information overlay you mentioned.

Hmm, that's neat. I'll share the planes test scene file, if you want to give it a try:

http://c2s.toshiba-3.com/DLoads/PlaneTest.max

It looks like the glide wrapper is using D3D's DrawPrimitive method using D3DPT_TRIANGLELIST as the primitive type, so each triangle always has 3 unique vertices no matter what circumstances. I think PIX probably isn't the best bet to see what the game is doing given that it sits between the glide wrapper and D3D, so any commands it intercepts are what the glidewrapper has munged together instead of what the game is actually trying to render. I would guess the glide wrapper does a lot of work translating the data sent through glide commands into an acceptable format for the D3D commands it pumps out.

Ideally you would either want to have a PIX-like piece of software sitting between the game and the wrapper for intercepting and analysing glide commands or somehow hook into the actual game to capture the data before it's rendered. I wouldn't be at all surprised if the game's internal mesh data is different from what it's sending to Glide and converting it at render time, but I'm no expert on Glide or BRender so I'm only guessing there.