Getting models from other games/apps into OpenZone

[Amphitryon]

This can be a challenge given that you have to use Anim8tor and it has a very limited range of import options.

However I have found a decent conversion path for getting objects into OpenZone (ala Anim8tor). In my case I extracted 3D Models from Star Ward Galaxies and converted them for use in OpenZone.

1. You need GMAX (registered). Its free and you can still obtain the download.
2. Secondly you need a GMAX to OBJ (Wavefront) export script which can be had here (I use the GMAX2OBJ script)

http://www.katsbits.com/htm/tutorial...models-obj.htm

That link also provides a very goo, and accurate tutorial of how to do the export to OBJ.

3. Then you can Import the model into Anim8or vie the Object>Import menu and selecting .OBJ format.

Whala, the model is loaded. You will still need to assign textures and such.

As for how I got the objects and textures out of SWG, there is an app called TRE Explorer which will browse the game's resource archive and allow you to extract files, and I also have a GMAX importer script for SWG's .MSH and .MGN 3D formats.

At anyrate I had far better luck using the OBJ format for import than 3DS with Anim8tor.

As far as WHY I did this...SWG's models have a LOT higher polygon count than the EQ models ,plus have higher res textures and I wanted to see how OpenZone and SimpleClient behaved with more detailed models and textures.

[GeorgeS]

One question I have - EQ came out years ago, and pc's were slower then by a huge amount. I wonder with my core I7 (3.6ghz) - how much of a poly heavy zone it will take to still make the game playable...

I have some nice models that would look very good in game..

GeorgeS

[EternalBlack]

GeorgeS,
From what I have seen in terms of poly limit. The number is quite high however there is a catch. Openzone has its compile limitations when it comes to both the shear size of files as well as the quality of the textures being used.

A simply example of this was a redesign of the westcommons zone from EQ classic. Our team rebuilt the zone from the ground up adding more size as well as a new Orc stronghold burried within the sanddunes along the side. After populating the zone with over 1000 or more trees each broken into 3 seperate imports(1 for the trunk, tho that part was kept low in poly count, 1 for the top-facing branches, and 1 for the bottom-facing branches) per tree set, which at 200 trees, there were roughly 5 sets (5*3=15 import groups of very high poly count) added to the terrain (broken into floor, 3 border sections, and the fort and tunnels them selves) as well as all of the "junk" that was scattered about the zone (new wizard portal, druid ring, camo'd scout towers, and destroyed variants, Orc tents and campfire, signs for direction, and much more). After all only completing the proper import of 3 sets, being 9 imports for trees after the terrain was imported, an error prompted us that Openzone did not have enough memory to contine, and that it had reached its limit, of i believe 2 or maybe 3 gigs.

Mind you that the machine we were using had 12 gigs ram, and 3 Tera Hdd as well as was running 64 bit xp with all proper drivers and we had dual 4870s rocking 1 gig vram each...

I believe the reason for the crash was because of the high quality/resolution of the textures being used and the overwhelming number within. using 2048x2048 for nearly every texture, in .bmp format, each was roughly 12m... and for each piece of each set of the trees, there were anywhere from 1000 to 6000 renders of the texture. at 12m, simply 1000 would need 12000m if the system did not simply cache the texture in the database for multiple use. also before i forget to mention, alpha channel textures for branches/leaves were also present on all 1000 - 6000 planes doubling the 12m to 24 per face.

Mathematically the volume used was almost endless, and the render times within max its self was actually visable... normally its click and done.. looking back, dropping the textures from 2048 to 1024 or simply 512 would have drastically changed this, but our goal was to push the limits... and apparently we broke them.

Let me know if you are interested in trying to perhaps put something together. If you need stuff modeled, and have some kind of concept art... I'm more then happy to see what i can do for you. It will be created in 3ds max fyi.

EternalBlack
Member of OrisonIndustries

[GeorgeS]

That's good to know. I try to limit textures to 512x512 anyway, but like slightly more detailed models.

I model everything myself, even did many of the npc's for simpleclient (should be a thread here somewhere), so am quite familiar with the process. Trees on the other hand seem simple, but can take quite an effort to look good.

GeorgeS

[Amphitryon]

That is great info, thanks guys.

Newer CPUs/GPUs should handle a LOT more than classic Everquest dishes out. My interest is centered around whether or not EQs' or SimpleClient's render engine could handle a zone full of hires/high polygon count stuff.

I have been 'borrowing' models for now as I am not so good at making them from scratch just yet. (wanted to see how models done up by folks who know more than I do looked).

Out of curiosity, has there been any movement at all on updating OpenZone and/or SimpleClient? (I am guessing if its not mentioned here, then the answer is no). Its just the OS compatibility problems are really putting a crimp in my style, having to fall back on Windows 2000 to get stable operation.

The main issue there nowadays is getting up to date Win2K drivers for newer GPUs.

[EternalBlack]

As Far as imports go here is what I have discovered.

When trying to create beautiful high poly high res zones, there is limitation to the max compiler size limited by 32-bit applications to a 2gig cap. For this reason, no matter how good a modeler or texturer you are, you are limited to this cap. Some key things to remember when trying to create the best/max quality zone.
-High poly meshes are limited to a 64k max either poly or vert... so you cant import 64k of 4vert planes... because that breaks the 64k vert limit 4 fold.
-Being limited to the .bmp format for textures means that all textures take up much more space then using other formats such as .jpg. In the case of a max resolution single texture, that will be 12mb for a single texture... not bad for a terrain map... tho higher res is typically prefered... this size is much to cumbersome for tree branch/leaf sets.
-All trees if using an alpha channel to designate what is shown and what is clear means that if you use a 2048x2048(max res) .bmp, you now are doubling the megabyte usage for a single object.
-Branches and other forms of single sided planes do not show a backside. If you want a leaf to have 2 sides to it, you need to duplicate the plane and reverse the normals of that plane thereby creating its backside. Once again, this doubles 24mb to 48mb.

To show the difference between a low poly tree modeled and textured to allow for many copies to be seeded across a terrain versus a high poly variant, I have modeled, textured and taken photos of both. I will include statistical data for both.

First the High Poly:

By icedfate at 2010-03-24
This one is using clustered x,y,z planes to create branch sprouts.
Number of Branch Polys: 300 single sided doubled to 600 for realism
Number of branch Verts: 2400
Number of Trunk Polys: 1581
Number of Trunk Verts: 1909
Total Polys for a single tree: 2181
Total Verts for a single tree: 4309
Res quality for all textures is max (2048x204
Breaking trees into trunk and branch for import means max set import of: 26

This means you would need to import a set of 26 and a set of 26 trunks to make 26 trees show up... and if u think 26 is alot, try using only 26 on an entire zone.

Low Poly Tree

By icedfate at 2010-03-24
This one is using folded 2 poly planes.
Number of Branch Polys: 18-2 poly planes for a 36 poly count doubled to 72
Number of branch Verts: 216
Number of Trunk Polys: 10
Number of Trunk Verts: 10
Total Polys for a single tree: 82
Total Verts for a single tree: 226
Res quality for all textures is max (512x512)
Breaking trees into trunk and branch for import means max set import of: 296

For this reason, the ability to seed a forest with low poly trees is much more possible with low poly... and if you want an actual forest, then 26 or ven 52 trees just wont cut it unless your zone is about the size of one quarter of crushbone.

Dont let me stop you from trying however. I simply do not want people to get mad when they hit the OZ import/memory cap of 2gigs and it crashes causing you to start all over again on your imports (yes, this happened to me... about 30 or so times while trying to see what the limits were).

Another thing to remember is that I am simply counting trees.... I havent included terrain, objects, buildings, bushes, plants and whatever else you want in a zone that would look very "beautiful".

I am also currently playing with the idea of grass seeding, similar to how it works in the revamped version of the common lands... Since .s3d doesnt support the same type of clipping that .eqg does, there is a problem with this idea.

If however we could crack the .eqg format, some if not most of the limiting factors would change simply because .eqg supports more...

Side note: Bump mapping doesnt work... tried and failed. Would have been a nice thing to add to the realism..... no flat ground... with paint splatters would be nice.

EternalBlack
Member of OrisonIndustries

[Taurinus]

Just a note here about the technical aspects of the 2GB memory barrier and 32bit applications (it's the only thing i can speak of here - i know zilch about modeling).

Large Address Aware (LAA - common terminology) 32bit applications actually get their virtual space extended to 4GB when executed on a 64bit OS (under Windows).

I've never looked at the source for OpenZone so I don't even know which language it is written in, but making the application large address aware is a trivial matter as long as the memory addressing remains sane.

Here's a discussion on this I found with Google:

http://www.wintellect.com/CS/blogs/j...ressaware.aspx

[Packet]

Has anyone attempted to use OpenZone on Windows 7 64bit in Windows XP Virtual PC (comes with Win 7 stock).

[Secrets]

Originally Posted by Packet

Has anyone attempted to use OpenZone on Windows 7 64bit in Windows XP Virtual PC (comes with Win 7 stock).

I've used it successfully on Windows 7 itself 64-bit. You need to have the latest graphic card drivers for DevIL library support (yeah, they added legacy stuff later, go figure.) and you'll also need to use OpenZone 8.6 for creating zones.

OpenZone 8.4 seems to work fine for compiling zones under 64-bit Windows 7/vista & 32-bit windows 7/vista. Hope that helps.

[GeorgeS]

Let me know if you need OZ ver 8.3 that I've tested in win7 64.

GeorgeS