MTM2.com

Hi again,
have been out for a while but here's a new question:
Why does the backdrop shine when driving at night or dusk?
It usually starts during the race, not when I start. It looks like the backdrop changes to "day-mode".

thanks,
enocell

http://mtm2.com/~mtmg/errors.cgi?e=31


<IMG SRC="http://mtm2.com/~mtmg/errors/pics/dusktodaybackdrop.gif" border=0>


Not sure, but you might want to check out graphic card drivers too.

I think it's not related to hardware, since my computer is now 800 Mhz, and this happened also with the old 400Mhz machine, and with Voodoo2,Voodoo3 and now with Ati.
It usually occurs with tracks with many models in same place, but not necessarily.
NewYork and Flydrop are the most affected backdrops.

Welp, Baddy's picture is from a stock mtm2 track. However, the NY and Fly backdrops are texture heavy. Maybe you'd like to give a couple other, newer, more refined drops a try. Look for a 4x4evo track called Lowrider Central. The backdrop is much the same as the Flydrop but re-done with greatly improved texture efficiency and guaranteed face types. Another is Old Nick at Nite's backdrop from Old Daytonan. To use the Lowrider drop, you certainly have my and miyh's full approval. For Old Daytonan, you might like to send a note to Old Nick. I hope that helps. Good luck.

I tested the lowdrop but I still it shines. Are Fly! models so "heavy" for mtm2 graphics engine, 'cause I have some big buildings in that track.
Those have textures mapped as squares, as many of my models. Maybe this is causing more lag, but I think that it's easier to map textures in that way instead of making triangles. Is it recommended to map textures as triangles? (but then face count is doubled)

>>Are Fly! models so "heavy" for mtm2 graphics engine

The Fly! models are exactly the same as mtm2 models. The only difference might be that in Fly! the textures are used more efficiently (that is, less textures are used to cover more area).

>>'cause I have some big buildings in that track. Those have textures mapped as squares, as many of my models. Maybe this is causing more lag, but I think that it's easier to map textures in that way instead of making triangles. Is it recommended to map textures as triangles? (but then face count is doubled)

The face count has virtually no effect on the game. The vertex count is the fps hog.

re: Square vs triangle faces

They way Oliver Pieper explained it to me is that as long as the face is flat, then four corner faces are fine. But when there is a bend in the face (i.e., at least one vertex is not on the same plain as the other three verticies), then the game in effect folds the texture to meet the uneven surface. This has the result of creating a artificial/pseudo triangular face. Now, if the face was triangular to begin with, then the game just reads that info and renders it in the game. With the four corner face, the game has to do extra work to make it look right. In short, if the face is flat, then four corners is fine. If the face is bent, then three corners uses less processing. It's interesting to note that when the game bends the four corner face, I believe the seam benefits from some smoothing. So, there may be a trade off as well (appearance vs performance) when choosing between three- and four-cornered faces.

re: the track

Maybe release a beta version to see if anybody else has the same effect as you're getting. When putting together the error pages I needed a lot of help. I get a load of errors, but I don't get all of them. Different systems run different ways. It might be interesting to see how your track runs on other computers.

P.S. I should add that neither the flydrop nor the lowdrop are fly models. I made both of those from scratch. The flydrop is just the zilladrop but without the flames. The problem was that it used too many textures to run in 4x4evo. People were clamoring for a track for their lowrider trucks so I adapted Godzilla vs Bigfoot into Lowrider Central. There were many changes that had to be made...the backdrop was one of them....which I'm happy to say turned out very well...except for this shining problem.

[This message has been edited by Phineus (edited 26-04-2001).]

>Maybe release a beta version to see if
>anybody else has the same effect as you're
>getting.

Now I uploaded the track. here's a link:
"http://vales.com/mtm/TrackDescMTM.asp?ID=2526"

Just a quick note for now. Yes, I got the daylight backdrop too. I still want to play around with a couple things. I'll let you know what I find.

Later that day....


Using gold mode/slew/Z I was able to get the following info:

<table border=2 width="50%"><tr align=center><td>shot #</td><td>on/off</td><td>models</td><td>sector</td><td>vis poly</td><td>ttl poly</td></tr><tr align=center><td>399</td><td>on</td><td>52</td><td>94,41</td><td>2812</td><td>8965</td></tr><tr align=center><td>401</td><td>on</td><td>52</td><td>94,41</td><td>4138</td><td>11877</td></tr><tr align=center><td>402</td><td>off</td><td>24</td><td>95,55</td><td>1178</td><td>4744</td></tr><tr align=center><td>403</td><td>off</td><td>39</td><td>95,54</td><td>1625</td><td>6039</td></tr><tr align=center><td>404</td><td>off</td><td>40</td><td>93,52</td><td>1418</td><td>5642</td></tr></table>

Unfortunately, this does not give us a precise vertex information. However, the poly/face count should suffice as an indicator of what is causing this. I found that the two most consistent stats were the number of models and the number of visible polygons. It seemed that once the model count got upwards of fifty, then the backdrop would light up. Similarly, once the visible poly count rose above two thousand it would have the same effect. The trick now would be to confirm these numbers by trying other high model/vertex laden tracks to see if we can get the same kind of results. If we wanted the vertex info, then we'd have to guess it would be the visible poly count multiplied by three or four.


edit. I forgot to mention. I had all settings maxed out. Later, I tried turning off reflections and truck reflections but nothing changed. I also tried D3D and 3DFX but still the lit up backdrop appeared. Another thing would be to try and reduce visibility to see how that effects the gold mode stats.

[This message has been edited by Phineus (edited 30-04-2001).]

Posting for Malibu350 who sent this by e-mail; he had a problem posting tonight for some reason.

Subject: bbs
Date: Mon, 30 Apr 2001 20:47:54 -0700
From: Malibu350 <malibu350@karf.net>
To: Phineus <phineus@karf.net>

I think I've run just about every track made at KC's and have never seen this first hand before, but then I rarely run tracks at night so I guess I wouldn't huh? lol

Unfortunately I am getting this backdrop bug too and have tried a few things to try and determine why it happens and here's a quick summary.

============================================

visibility set at 100%
Scenery set to complex
Image quality set to High
Direct 3D, triple buffer
all options toggled "on" except truck reflections and lens flare
stock Bigfoot @ chase far view

With those settings here's a screenshot of precisely where the BD lights up, note the visible pollys and models.

http://malibuco.hostme.com/images_mtmg/Image1.jpg

OK now the exact same spot and settings as above "except" visibility is now at 50%

http://malibuco.hostme.com/images_mtmg/Image2.jpg

Now I can pass this area every time until I get to here

http://malibuco.hostme.com/images_mtmg/Image3.jpg

Nothing really conclusive in the pics above as far as pinning down a cause goes but I think it points to what's not causing it by looking at this screen shot of daytonas infield here,

http://malibuco.hostme.com/images_mtmg/Image4.jpg

Note the visible pollys are ten times what they are in Enocells track due to a very high concentration of high vert models but I can run this track all day long with no backdrop problems, I even put in Phins lowdrop.bin and ran it just to be sure it wasn't a possible cause but it ran perfectly still.

I was about to make some more changes to the infield to try and reproduce the backdrop light effect until I compared stats between the two tracks and found that "Don't have a cow" uses 2024 ground boxes where the infield uses zero. that along with the fact that there are more gb's where the backdrop lights up for me at 50% visibility. that tells me that this is another bug caused by ground boxes or perhaps a combo of ground boxes and models. one other thing is my vid card takes a tremendous hit just as the backdrop lights up (my fps drop to zero for about 2 seconds), those ground boxes really take a toll on a tracks performance.

============================================

I would like to suggest that you pinpoint where on your system the tracks bd lights up and reduce the number of gb's within view and see if it makes a difference, I am willing to bet that it does.

I hope this helps, either way let us know.

I removed ~300 ground boxes near the shine-spots, but still I got the shining. But it's very hard to tell what causes it since it still happens.

I checked the track couple of times in gold mode and got these results(just one example)

models: 63 vis.poly: 2925 total poly: 8129
->no shining

models: 20 vis.poly: 849 total poly: 3154
->shining

I don't have screenshots because those z-mode texts didn't show up on any of my screenshots

I can post the .txx file if anyone else wants to test

Is there a list of bugs relating to the evil GB (as Mal calls them)?
I know about the full stop when jumping onto a GB edge and the quite useful inheritance property of terrain (sound and grip) above or below a GB. Are there any others?

Have mark increase box count

http://cownap.com/~mtmg/errors.cgi?e=21

Yes, phantom triangles. A visual glitch formed in rare conditions where terrain rises up though one a certain way, a face that is textured with a raw that isn't even used in the area. There is a lost conversation about this problem somewhere (near the secret course in Alphaville no doubt).

A similar and more common effect is seen when terrain slopes up and bisects a box, causing a weird shine-through, inside-out effect.

Then there is the invisibility effect caused when they penetrate the water level, the visible bottom portion being invisible in proportion the the amount buried in the water.

I forgot about the invisible bottom above the water (which you already explained when I did LaPaMa).

I think there's another one: when driving backwards exactly perpendicularly into a GB you stay glued to it and must call a helo.

In the end, I think Mal found a pretty appropriate name.

>>> In the end, I think Mal found a pretty appropriate name

Wint's the evil ground box guy... I'm the noah dude :o)

I agree with wint's assesment tho and avoid using GB's except when I need to... like for ridding a bridge model of the splashing water sound effect by burying them under the water beneath the bridge model or to add the echo sound effect in tunnels by inserting a few up above/inside a tunnel model.

Why so shy?
http://forum.mtm2.com/viewtopic.php?t=2205&highlight=sidewinder+stop

Are there any advantages of using GBs?
Especially: what are the comparative advantages of GBs versus bins when it comes to simple cubes painted with 256x256 textures?

I have a (city) track under construction, where I started to put in lots of GBs as placeholders in order to sort out the viewing distance problem in the first hand. No problem so far (except the box count error). Now I wonder whether I will run into problems if I replace the GBs with bins.
Do GBs use the texture memory of the terrain?
Is object texture memory handled differently (less efficiently) by the game?
Do vertices of GBs cause less impact than those of bins?
(Likely because GBs are vertical cuboids fully determined by any pair of diagonally opposed vertices and there is no need to look at 8 vertices)

> Do GBs use the texture memory of the terrain?

Yes, ground box textures count as terrain textures. Yes, model textures still put a strain on graphic load.

> Is object texture memory handled differently (less efficiently) by the game?

Not significantly. Althought totals tally differently.

> Do vertices of GBs cause less impact than those of bins?

No.

> because GBs are vertical cuboids fully determined by any pair of diagonally opposed vertices and there is no need to look at 8 vertices

A vertex is a vertex, whether you can see it or not. Texture and vertex numbers are the same whether they are in view or not. If they are in range, then they impact performance.

Hope that helps. Hope even more that it's right.

>> Why so shy?

I think he heard me laughing and had to mention that I had first referred to them as 'evil'.


>> Are there any advantages of using GBs?

Their terrain-like grip and type.

There are 2000 available, while there is less than 500 models available, making more walls, roofs, bridges and buildings possible.

They are very effective for those who cannot build their own models, for the things just mentioned.

Their 90 degree sharp edges are useful in many circumstances (compared to terrain).

> They remove splashing effects from bin bridges over water.

> They add echos to tunnels and buildings.


>> Especially: what are the comparative advantages of GBs versus bins when it comes to simple cubes painted with 256x256 textures?

See above.

The GB echo effect is desireable, but for roofs I like to use big bin cubes, one single cube can replace many GBs. For example, I used eight simple bin cubes to cover my loading dock with a roof, each covers the area of 8x8 squares, which is almost too much for single model, but each replaced 64 GBs, and the whole roof would have required 512 GBs in one small area, which would have been fatal.


>> I have a (city) track under construction

Groundbox buildings are an excellent addition to a city when used wisely, sparing the model count.


>> Now I wonder whether I will run into problems if I replace the GBs with bins.

I don't know what you've done, but too many models in close proximity is bad news. Even so, I would say that the models will cause you less problems than GBs, because of the way GBs so easily trigger the error.


>> Do vertices of GBs cause less impact than those of bins?

I would say... more, for whatever reason they have a strong impact on overall performance.


>> Is there a list of bugs... ?

When two GBs are next to each other and differ in height there is a visible seam between them, in the form of... a line of sparkling light, but when they have the same dimensions there is no seam visible.

Another GB use would be to prevent chase far/close camera views from going beyond model walls that can cause temporary track blindness.

Unfornunatly I just ran into that very problem... but raising the terrain or inserting GB's to keep the camera in place would ruin the effect I'm trying to get... Man I spent three days getting this section just right, all the time testing-checking with the cab view, never even taking the chase camera into consideration. ... dangit