Transparency test

[C2_Scientist]

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

[Harmalarm]

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

[C2_Scientist]

That's a pretty scene.

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.

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.

[C2_Scientist]

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.

[Harmalarm]

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.

[C2_Scientist]

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

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

[Toshiba-3]

Nice numbers there
I think groups of trees, or simply transparency should be avoided as much as possible in C2. It's sad but these artifacts can really get in your face sometimes... If people didn't mess with the YON, one could use the YON multiplier at the end of a track text file to reduce even more the drawing distance. Allowing for a good ton of trees, a dense forest, very foggy. That wood be a good setting

By the way Harm I think I remember total track textures being around 900. Maybe it's also counting reg pixelmaps and that would bring us to around 1024? Just thinking out loud. 400 textures sounds more like C1 limit.

I'll see if I can put the map tricks topic back in shape...

[C2_Scientist]

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.

[Harmalarm]

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.

[C2_Scientist]

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.

[Toshiba-3]

Once again, great numbers. Should have been obvious that the vertex count was behind this from the start. Though I'm very surprised as well by the fact smoothing groups and materials can split vertices. I quickly reproduced Guillaume Provost's examples from that link and compared in PT2:

2016-02-10.png (27.14 KiB) Viewed 10196 times

In PT2, vertex count only rises with split UVW maps. At first I thought that the bottleneck must have been further than the vertex count, that smoothing groups were another factor weighing on draw calls (and thus didn't split vertices). But now I rather think C2 renderer handles things a little differently than its physics engine. I mean, I suppose most limits we have to follow (1000 vertices per component etc.) come from the physics engine and thus the game loads assets the way PT2 sees them. But once at the rendering step, stuff has to be handled differently I guess and more vertices are split at that moment.

... I'm a bit lost because the game only creates material splits (hard edges in the shading) on the vehicle main models for example. Even UVW map-induced hard edges don't appear as hard edges if its for a vehicle shell model or track mesh (though it does on peds).

Are there tools that display draw calls, vertex/face count, etc. as an overlay within a game? Would be very useful.

[C2_Scientist]

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.

[Toshiba-3]

I suppose it's possible to gather a lot of infos via PIX for Windows. Have to understand what we're looking for first though
I had to use psVoodoo as glide wrapper as the other big two were crashing.
I got PIX out of the DirectX 9 SDK (June 2010).

Carma2_HW 2016-02-10 16-39-15-50.jpg (172.18 KiB) Viewed 10187 times

Have to find how to access triangle and vertex counts...
[edit] ok, by capturing a frame via F12 we can access a whole lot more of infos. We can even see each draw call etc.


By the way, I took care of the Adv C2 tricks topic, tell me if you still can't reply in it.

[C2_Scientist]

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

[Toshiba-3]

I did some tests but I'm not sure I did it right etc. (each time, I was in Action Replay mode and made sure either the 100 quads or each 'hat' were the only thing onscreen):
Whatever I tried, the 100 quads were always seen as 600 vertices. I tried two different SGs per quad. Splitting UVW. Applying a textureless material just in case.

2016-02-10 (3).png (17.6 KiB) Viewed 10175 times

Then I tried the hats as seen above in the same order:

2016-02-10 (4).png (10.84 KiB) Viewed 10175 times

no features: 354 vertices (see pic above)
sg only: 366 vertices
multisub only: 360 vertices
uvw only: 360 vertices
all of the above: 366 vertices

I don't know if we can make anything out of these at all

[Trent]

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.