[fre_ber]

There is a simple explanation for why vertices require more memory than faces. A vertex consists of a location, a colour and at least one texture coordinate. That is at least 3+3+2 single precision floating point values, i.e. 32 bytes each. A face is just a list of indices into the vertex list, probably no more than two bytes per corner of the face.
_________________

"He who re-invents the wheel, understands much better how a wheel works."

<[4D]JoeShmo> what we have here, is a failure.. to communicate

[Lex_Luther]

Yes that makes sense.

To make the numbers work the equation would have to be changed to:
Xresolution*Yresolution*4 + VertexCount*32 + FaceCount*6 = about 25MB

So now I am wondering a couple of things.

If each pixel is using 4 bytes, Is the game somehow using 32-bit color when it says it's using 16-bit?

Will the game accept coordinate-only Verts? Does any Zmod export filter option support this? What would I set the "fvf flags" to in order to get coordinate only PKG file?
This would probably look pretty crappy/weird, but it could be used for the lower LOD bodies in a PKG to free up some mem without any noticable change.
Anyone try this before??

[fre_ber]

I have a faint memory of successfully testing that, but I am not 100% certain. However, i have no idea if the ZModeler export plugin supports this.

I am not certain what pixel format MM2 uses, but it does have an alpha channel. I hope that means that it uses 32 bits per pixel since the 16 bit variants with alpha would be terrible.
_________________

"He who re-invents the wheel, understands much better how a wheel works."

<[4D]JoeShmo> what we have here, is a failure.. to communicate

[Lex_Luther]

I've made a discovery that is worth mentioning. While working on the NewYork Mod, I decided to delete the 1800 facades placed in the INST as a "Coordinate Type".
This freed up 150,000 verts! So then I converted them all to "Simple type" with a scale of 1. This also freed up the same amount of memory.
I then tried placing them all with a scale of .75 and this had no free memory gain.

So, apparently placing an INST with any kind of scaling is the same as placing a unique item, Each scaled item uses it's own memory even if it is placed elsewhere with the exact same scale.

IceHole and I are tediously working to re-place each of the 1800 facades, but will take us a while. but the end result will be worth it!

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

Another 'discovery' -- after switching computers, we noticed the new computers could load more inst items- I am suspecting that the game is using conventional memory (we got dual core machines) of the second core.
It would be interesting to compare memory usage on the same machine running under Win95 and WinXP assuming that available conventional memory would be larger in Win95. I may do a test run using VirtualPC.

But if I told you using Win95 would run the game better, would you actually bother? I probably wouldn't.

[Tonywolfe121]

YOUR NOT DEAD

anyways good luck and good find

[Lex_Luther]

Yes, I am alive It has been a couple months between posts there.

Turns out I wasn't completely right about the scaling. Memory is only saved if you avoid vertical scaling. I've also run some more tests...



In the picture above I inserted 500 of the same facade with various scaling. No noticable memory usage. Also note that the xref props (the trash bags) did not scale along with the facade. While I was at it, I found that the maximum number of items in an INST file that the game will load is around 20,400.

I've also discovered that modifier flag 0x100 if set for an INST disables the verticle scaling.

Speaking of xrefs....

In case you don't know, most of the props in the new york track are placed using an xrefs section in the pkg file. I removed all these xrefs, and converted them to individually placed items (over 2,700 of them).
While testing this I noticed some glass was rotated so it was facing down. I've always wanted to rotate props around more than just the Y-axis, so I looked into it farther.
I tried replacing the windows with f-18 jets to see if they would rotate. They didn't So I compared the banger files.
As it turns out, setting the BillFlags to 256 in the banger, enables the arbitrary rotation

Above is a screen shot showing one jet placed normal (flat) one facing up, one at 45 degrees downward, and the rest facing down (like the windows)

This deserves a second look into the pathset files... any takers?

playing with the seperate x,y, and z axis is complicated, but when I find an easier way I will share it here.

[Yallis]

[LongR]

Somehow all my maps I've done the last time I can't even try out in MM2 because of this heap overrun.

I didn't really get your findings..
Xresolution*Yresolution*4 + VertexCount*32 + FaceCount*6 = about 25MB

One of my cities:

1024 * 768 * 4 + 14729 * 32 + 10538 * 6 = 3680284


Does that mean it is about 3,68 MB ????
Do I need more? But how?


It is more like random to get one of my maps running in MM2.

[HummersRock]

Well you keep getting the heap overrun you say so maybe that is not 3.6MB but 3.6GB. Sounds crazy.
_________________
My MM2 Creations | My DeviantArt

[Riva]

Here's currently my MM2 folder (using your equation).

Base
Xresolution*Yresolution*4 + VertexCount*32 + FaceCount*6 = about 25MB

Ferrari 612 Scaglietti
(1920x1200x4)+(64932x32)+(75295x6) = 9.216.000 + 2.077.824 + 451.770 = 11.745.594

Bugatti Veyron
(1920x1200x4)+(23831x32)+(24128x6) = 9.216.000 + 762.592 + 144.768 = 10.123.360

Cadillac Fleetwood Brougham
(1920x1200x4)+(32496x32)+(38073x6) = 9.216.000 + 1.039.872 + 228.438 = 10.484.310

Rolls Royce Phantom
(1920x1200x4)+(41683x32)+(45187x6) = 9.216.000 + 1.333.856 + 271.122 = 10.820.978

Akina Mount approx.
(1920x1200x4)+(55000x32)+(32000x6) = 9.216.000 + 1.760.000 + 192.000 = 11.168.000

Countryside
(1920x1200x4)+(19761x32)+(18426x6) = 9.216.000 + 632.352 + 110.556 = 9.958.908

Neustadt v2
(1920x1200x4)+(32709x32)+(28309x6) = 9.216.000 + 1.046.688 + 169.854 = 10.432.542

Mountain Pass
(1920x1200x4)+(93396x32)+(101022x6) = 9.216.000 + 2.988.672 + 606.132 = 12.810.804

Stinger City
(1920x1200x4)+(29235x32)+(33245x6) = 9.216.000 + 935.520 + 199.470 = 10.350.720

Akagi Downhill
(1920x1200x4)+(58056x32)+(50944x6) = 9.216.000 + 1.857.792 + 305.664 = 11.379.456

Forest Club
(1920x1200x4)+(116794x32)+(88506x6) = 9.216.000 + 3.737.408 + 531.036 = 13.484.444

UK Bus City approx.
(1920x1200x4)+(8000x32)+(8000x6) = 9.216.000 + 256.000 + 48.000 = 9.520.000

Total : 132.279.116 (132 Mb ?). Overall : 10 Mb by addon.

But don't forget this, if I add another addon with high quality textures (1024*1024 pxl or 2048*2048 pxl), the game crash to desktop with the heap overrun dialog box).

And ... if I remove all of these addons and I add only one (e.g. a car) with more than 55 or 65k vertex, the game CTD (even that the polycount is low). However I can add many other addons with a correct vertex count and many many polies (more than 75k for each).

Like I said you cannot play MM2 with a vehicle addon having more than 65.000 vertices. It's not a limit imposed by the PKG plugin from ZM1 but just a limit of the graphics engine IMHO.
_________________

[Lex_Luther]

[LongR]

Oh... I get the "Find heap failed" message.

[Moylance]

I must say, awesome work to the people involved that are working out all of these new and exciting facts about the game. I do sincerely hope that you are all successful in your careers!!

Well done guys!
_________________
Hey guys!
Anyone that would like to get in contact love to
have a chat!

MSN: moylance@westnet.com.au
E-Mail: moylance@westnet.com.au