MTM2.com

Anyone know why I get an Access Violation offline on my soontobereleasedbutImnotgonnatellyouthename track?
It only happens on the first time out, then it never happens again once I restart race. Just wonderin, its not really causin a problem.

Drive2Survive and I were able to trip the access violation message when using too many animated models in close proximity to each other. Also, Alpine's Undeniably Crazy would give an av coming down the hill toward cp9. It was my guess there was too many textures in view. It seemed to happen less often when I removed the patterns that were laid down just off the main course. Lastly, wint's wake up track tirggered av's during beta. I'm not sure but I think he reduced the number of textures overall and spread out some models too - everything is very tight together in that track..

No concrete solution yet, but hopefully this will give you some clues about where to look.

Well, I have no animated models, but I do have 98 different textures all within a 40x40 area or so lol.

Hey, that's interesting isn't it. If you're able to reduce the number of errors by spreading out or removing some of those textures, please let us know. This has been a long time error and it would be nice to finally get a grip on its cause. The more often we can attribute this to textures, less coincidence it's likely to be. Thanks.

QUESTION:


What size are those 98 textures? How many of them are 64x64 and how many 256x256 pixels?...I'm curious if texture size is related to this problem....

According to some of ZOON's text, many old favorite tracks had a large number of 256x256 RAWs for the track/model textures, and suffered because of.....

If they are all 64x64 pixels, then this blows the theory...let us know either way please...

> If they are all 64x64 pixels, then this blows the theory..

Perhaps not. When large textures consume graphic memory, the game chugs no matter how many are in a close area. I'm not saying we should disregard texture size, but my experience is 64x64 contribute to the problem as well. Also, when I removed textures from certifiably, I removed terrain textures but model textures were a factor too. There's still a lot of questions yet, but at least I think we're finally in the right neighborhood.

I made a track with a 20x20 area with over 400 different textures and it works fine. THey are all 64x64
I was having fun with slice 60 and wasnt careful enough to make it possible to remove redundant textures cause the patterns i spilled werent 60x60.

http://badassrebels.net/ch_2005/tracks/switch.jpg

All my textures are 64x64. Last year I learned MTM2 cant handle many 256x256 textures in a small area. I had about 30 and I was gettin 10 fps lol. Though I also have 62 model textures and most of them are 256x256.

Stats:

Textures: 98
Models: 93
Model Textures: 62
Course Segments: 3
Ground Boxes: 66
Scenery Objects: 329

Due to the scenery object count, I have to decrease viewing distance to 80% to not get a "Too MANY Objects!" Error.

the ground boxes might be doing it. Are u getting a have mark increase box count error wih many trucks?

nope

Erm....I went back onto the track and did not get an AV...soo um...hrmph. btw, The number of ground boxes hasnt changed from my other WFs.

I believe there is your answer....it's the models.....most if not all should be 64x64......in rare cases, use a few 256x256 raws, but be frugal....

The following is text from ZOON, as he was recruiting people to make track models...I corrected a few translation errors:

-------------------------------------------

Ho, something important :
I was viewing at the TRAXX statistics of ZK2 and the textures folders, the original models and textures are using a lot of 256x256 RAW files. The used space of one 256x256 texture is the same than the space of 16 textures of 64x64 size....

I think this is another important part on this kind of track, we need to optimise the (texture) files to prevent FPS problems about the 3D Card (performance), even if (today's) actual hardware is more powerfull than old generation 3D cards.

For example, the spoon of ZK1 was using a 256x256 texture ....there was no reason for using a big one like this, since there's only a grey color inside ... without blending ... I changed it to a 64x64 raw. This action has open a space of 15 textures for the same used (memory) space!)


------------------------------------------------

It's me again.

SInce one 256x256 file uses as much memory as sixteen 64x64 raws, you want to avoid the larger textures for all but the most extreme cases, ....

An example of an exception would be the couch model I made for Zoon's track...the trucks will be driving ON it, rather than near it, so my first attempt with a 64x64 pixel texture looked bad close-up...I had to remake it with a 256x256 raw, but the other models in the same area of the track will still use the smaller size RAWs....so the game should run OK even with the couch model. Even using seven or eight 64x64 pixel raws is better than one 256x256 raw...


--------------------------------------------

THE SAME RULE applies to trucks....nearly all of my scrapyard truckparts use 64x64 textures to keep the truck's total POD size down....the exception was with my body and engine models, since they need large RAWs to look realistic, as they do in EVO.

>> Due to the scenery object count, I have to decrease viewing distance to 80% to not get a "Too MANY Objects!" Error.

Well now, you've pretty much identified the problem, and it ties in to what I was thinking.


>> Erm....I went back onto the track and did not get an AV...soo um...hrmph.

Been there!


>> wint's wake up track triggered av's during beta.

Yes, here is what I thought and wrote at the time:

"During development I ran into the mysterious "access violation" error more than a few times, but it was rare and hard to predict"

Later...

"I think it may happen due to sheer numbers of models within a given area. I know it's not specifically related to animated models, I got the error before any were in my track. When I shift most models up from sparse that should solve any problems for long term racing prospects."

"when I've gotten the error it's usually been after roaming - then simply panning the view into or entering the central area of the track (where more individual models would be in range, naturally)."


Removing a number of models helped my track, you should consider merging or removing some of yours if you can.

The primary reason that toy's in the attic was delayed a day was because during the final tweaking I ran into the AV error and found a way to make it repeat.

[pod mounted below startup.pod] In complex mode, cockpit view, drive to cp3, then go up the hill a little ways beyond the flag and stop where you see a 'wrong way' sign on the road below to your left and wait for the blimp, it'll get there around 2:50. When it gets there follow it at the same speed, stop when you reach the first yellow support that you come to. The blimp will have passed underneath by that time and if you didn't already get an AV then you probably will shortly thereafter.

That is the same spot that I first encountered the error on the track, but I didn't tie the blimp into a possible cause because I didn't see it, it was out of sight under the road. The second time I encountered the error (as mentioned in my readme) I was approaching cp11 just as the blimp was passing through the road there. At that time I tried to get it to repeat unsuccessfully. So I wrote it off as just a fluke we'd run into once in a blue moon.

Yesterday in a last minute effort to remove the blimp from blocking the racers view I created a replacement... A big red low poly transparent balloon :o) I also translated it an additional 100 feet off the ground. While testing it in game I rediscovered the AV, at the same spot near cp3, and it would trigger it every time, at the same spot. I really liked the balloon lol so I ran another test after raising it another 150 feet into the air.... after a half dozen test runs the error didn't pop up but on the seventh it did. So in a final effort to remove the error I reduced the goody.bin to a single vertex point and ran 20 successful test runs... remove goody = no more AV?, I don't know, time will tell I suppose.

Reflections, damage, tire tracks and dashboard off. Everything else up full.

I tried a few times but didn't get a thing.

> Reflections, damage, tire tracks and dashboard off. Everything else up full.

Same here... Makes me wonder if it's vidio card related then.

With so many variables to deal with, a definate fix may never come about.

Here's the balloon version I originally intended to use 478k zip

Nicely pinpointed!

Yesterday: (on Toys in the Attic)

At the point at which the blimp disappears <i>entirely</i> beneath the road surface, or very shortly thereafter, on the slope upward after checkpoint three: access violation! So far I find I must be in motion for it to trigger, if I am parked it doesn't occur. I triggered this about four times in a row, consistantly. I was thinking that the blimp sharing space with bins might be factor, on that note I followed the blimp around on Wake Up to no effect (I get AVs all the time on there).

Today:

Today, I was killing time while waiting for the blimp to arrive at the designated area, but as the time neared I was travelling backwards on the track, <i>down</i> toward checkpoint three, and about the time I neared it I crashed with an AV. The blimp was hovering over course segments eight or nine (the loops preceeding checkpoint three). This does place the blimp at the scene of the crime, but kinda rules out the 'sharing space' notion. I restarted the game and tried to repeat this, but no troubles occured, then I turned and followed the blimp through the main trigger zone and... nothing happened!

I'd planned to try more stuff before I posted but figured I'd add this now.