You should be using `-chop 1024` for a map with such absurdly large surfaces. That will hopefully bring you down into a reasonable patches count. The MAX_LIGHTS message is an inaccurate error reported by qrad -- a typo, really. It has nothing to do with light entities. Rather, it's equivalent to MAX_PATCHES, which means that the compiler can't subdivide your map's faces into a reasonable number of patches to gather radiosity for them. While this limit is sort of arbitrary and modest for today's systems, the fact that you're hitting these limits should tell you something.
Even if you get that thing to compile, as soon as you throw entities into it, people will overflow when trying to connect because the entity baselines will blow out the 1400 byte packet size (MAX_MSGLEN). Your map is way too wide-open to VIS well.
Crap on the engine all you want, fucking thing's 20 years old. But this isn't exactly an example of fine mapping either The Quake engine was built for rendering indoor environments: not football field-sized box maps.
Hehe. Q2W is and will always be 100% free and open source. It's goal is to borrow some of the best aspects of the Quake series and meld them into a game that is, while better in many regards, still undeniably Quake2. We should chat sometime when your pak is complete, if you're still looking to work on that kind of stuff.
TC:granny.. man that takes me back. What ever happened to that clown?
Foc, I'm really looking forward to seeing your pak. You realize that if you become a proficient modeler, I have no choice but to flatter and pester you until you agree to work on Q2W right? What an unlikely couple we may yet become
I fixed this problem in Quake2World by doing a little trig in the game module. Each time you fire, I trace straight forward from your view vector to determine exactly what your crosshair was over, and from that impact point, I subtract your muzzle origin to determine the directional vector of your projectile. This way, the crosshair is dead-nuts accurate at any distance.
Still, like Whirling says, with proper texturing, you'd be surprised how low-poly you can make your meshes. For example, the qforcer player model in Quake2World is around 1200 tris.
While he's an MD3, his geometry is well within the limits of even MD2. Just food for thought.
MD2 does not have a grid system, but it does effectively "quantize" vertices to 0.125 units (okay, I guess you could call that a grid ). What's really happening is that vertices are stored as 16 bit numbers in MD2. When the program goes to squash your 32 bit floating point vertex coordinates into 16 bits, some precision is lost (obviously). The smallest value representable in this 16 bit format is +/- 0.125. The largest value is +/- 4096.0.
Side bit of trivia: all entity positions in Quake2 are represented this way in the network protocol. It's actually why your player "drifts" side to side slightly when you try to walk straight forward and backwards.
For best results, you should create your model in a scale that is relatively close to what it would be in Quake units. That will minimize the clusterfucking that happens to it during export.
Another option, if both programs support the format, would be to use .obj for your interchange format. It natively supports floating point vertices (it's actually a text-based format).
Electrified, I actually have a dozen or so .map files for Quake2World that you could open up in your editor of choice for Quake2. It's a lot easier to learn when you can fly around a map that someone has already built and poke / prod at it:
The rest would still load fine, but will be missing textures for you.
In terms of editors, I would recommend:
GtkRadiant 1.6.4 - Industry standard, best support for additional games QERadiant - A stepping stone to GtkRadiant and adequate for Quake2 WorldCraft 1.6 - Quake1 mappers still cling to this, so you can probably find help from that community
Right on. I watched jitspoe (Paintball2 maintainer) crank out a rocket launcher in 10 minutes in MilkShape3D. I couldn't do it, but I was really impressed with how efficient he was with it.
I started mapping with Qoole in 1999, and then learned QeRadiant in 2000. I guess, having learned it when I was still a teenager, I never appreciated how odd / unintuitive it is. I've never found the mechanics of mapping to be difficult (with the exception of bending pipes) -- just the creative part
Does anybody still check and/or post on that forum regularly? Been delving into learning modeling a little bit lately and it would be nice to have any place I could ask a question or two when I need to a get a decent answer within a day or two. I've asked a few questions on the Quark boards lately, and I doubt I'll ever get an answer.
The Q2 Cafe does still have activity, but it's almost entirely mapping-centric. For modeling, especially for Quake and Quake2, I would check out the Inside3d forums as well as #model_design on Freenode (this is the old Polycount community) as well as #terrafusion on QuakeNet (oldschool Quake mapping community, many of whom went pro and work in the industry).
Best of luck learning how to model! I was never able to pick it up.
Show Posts
The Quake engine was built for rendering indoor environments: not football field-sized box maps.
TC:granny.. man that takes me back. What ever happened to that clown?
). What's really happening is that vertices are stored as 16 bit numbers in MD2. When the program goes to squash your 32 bit floating point vertex coordinates into 16 bits, some precision is lost (obviously). The smallest value representable in this 16 bit format is +/- 0.125. The largest value is +/- 4096.0.