Q3map2 and ram

[VolumetricSteve]

I’m mostly getting malloc related errors these days, mostly safe_malloc failed, and I crunched the numbers, it was trying to address 11.8 GB of space to tinker with. Some of my maps are…crimes against decency and I like them that way, so I’m wondering since my motherboard, processor, version of windows all support 16GB of ram, if I got that much ram, would q3map2 know how to use it all? I don’t know if Q3map2 has a memory limit built-in…it seems to have a lot of limits like that.

I already tried increasing my virtual memory to 6.1GB and no dice, which makes sense…

4GB of ram + 6.1GB of virtual memory < 11.8

I’m assuming that’s how q3map2 tries to address it all anyway, first ram, then VM.

Bottom line, if I can throw money at the problem I will. (about 300 bucks for 16GB…the times we live in, jeeze, I remember when a 1GB of ECC cost 210 bucks)

Thanks

*** edit

I’ve googled around a good deal for this issue, which is why I’m already to the point of considering just adding a senseless amount of memory to my system. I saw the older threads about this issue and those methods/workarounds haven’t really done the trick for me. I could just switch my operations to UT3, but…

I <3 my Q3map2.

[obsidian]

I’m pretty sure this is best solved with a little optimization in your actual map. There have been some pretty big projects over the years, most just require a good understanding of how to map cleanly to avoid hitting these limits in the first place. Those who hit these limits are usually people who are new to idTech 3 mapping, those who are experienced (and have created some pretty amazing projects) rarely run into these problems and it’s certainly not from a lack of ambition.

Perhaps you would like to share a little bit about what you’re working on, so we can see why you’re running into problems?

[VolumetricSteve]

well, I’m sure the problem is just that I’m using unreasonable compiler switches on my maps, which are gigantic as they are geometrically complex.

Here’s one of my projects I’ve done:

http://sirventolin.webs.com/razztazzmagoria.htm

The Checker-board pattern present in all of my maps is done by taking four brushes, two with one texture, the other two with a different texture, and I just copy that all over the floor surfaces of the map which results in brush counts in excess of 35,000 in the case of razztazzmagoria 2. I realize from an engine standpoint, this isn’t good in any dimension (it tends to make the bot ai compiler go nuts) but I like the sharpness and clarity of the edges that wouldn’t be possible if I just used one big brush with a checker board pattern instead. This was intentional, I knew it’d murder my compile time and have an impact of the kinds of things I could really stress in both quake 3 and the map compiler.

In my most recent project, CorePanic, I was able to achieve really stunning visuals by compiling with the -patchmeta switch, but I was starting to run into MAX_MAP_DRAW_INDEXES or something like that, so I had to compile without patchmeta, which really took the thunder out of the visuals in that particular map, to me anyway, but I was trying to meet a Halloween deadline, so I didn’t wanna mess with it too much.

The final product looks like this:

http://sirventolin.webs.com/corepanic.htm

What I’ve been doing recently is globally increasing the detail of the lightmap size, compiling without -fast, and throwing in things like -bouncegrid and -bounce 12, I know a lot of people can’t tell if these were ever turned on or not when they see the final map, but from my standpoint, working with the same maps for weeks at a time and having to see the same lightmaps all the time, using those settings makes a very visible difference to me.

I already went to the trouble of buying a computer specifically for q3map2, which is a 6-core system overclocked to 4.4GHz and it’s been working wonders for my compile times, even with my ridiculous switches being given to the compiler.

So, basically I know that the reason I’m hitting these max limits and ceilings are my own fault, but they’re also an intentional part of the design. For example, you’ll notice in CorePanic, I have arches and what might look like patch-mesh bevels/curves. They’re not. That’s all solid brushwork I did by hand simply because when I used the curves, they never compiled right, the lightmaps always came out wrong, and -patchmeta wasn’t fixing it, nor was any guide I could find on using patches within Radiant (Gtk or Net Radiant, I tried both) So my choices were to use the more compiler-friendly and quake 3-friendly patches and have them look wrong, or to replicate the triangles into brushes to arrive at the exact result I was hoping for.

I do a million little insane things to try to make my maps look a little nicer, they really tax my system and the compiler…and quake 3, but the end result looks really good, and in a lot of cases I get comments like “I didn’t think quake 3 could look like that” which is what I’m really shooting for in the end, which is why I’m always in this forum, I’m trying to push the visual limits intentionally.

So now, when I see the compiler is telling me I’m out of memory, it’s because what i’ve given it to do is way more than it was intended to handle, but…that’s also on purpose.

Would it work with 16GB of ram?

Thanks.

******edit

I wanted to note, all of the maps I’ve made so far have been done at least in part because of the help you’ve given me this year. I couldn’t have done a ton of that stuff without the help I got here, more specifically from you. Thanks again for all of the help you’ve given!

[obsidian]

I doubt you’ll need or be able to make use of 16GB of RAM. I’m not sure what limits you’re hitting, but I doubt it’s from pure memory consumption. Maybe try using -lowmem and see if that helps at all (warning: long compile times ahead).

BTW, what you’re doing is positively insane, but looks cool.

[VolumetricSteve]

Thanks!

Unfortunately, I’ve resorted to -lomem a while ago, I hit safe malloc errors with it, which is why, et ceteris paribus I immediately jumped to “let’s go buy 16GB of ram” because it faulted on a HUGE number of bytes, whatever 11.8GB is equal to.

I will make an effort to try to caulk more edges though, and I’m finding ways to cut back the brush counts…a little…with no impact to the visuals

The only reason(s) I think 16GB of ram would fix it is because:

1. Q3map2 was last updated a while ago I think…computers didn’t normally have 4GB of ram back then, but mine does now, and it’s maxing that out, and I’ve seen q3map2 calling no less than 1.7GB of ram for itself and that was on a simpler project

2.Getting errors on huge memory chunks I don’t have seems to imply that it’s trying to address that space and simply can’t because it’s not there

3.I haven’t been given proof that it can’t utilize 16GB of ram

So anywho, thanks for the tips thus far, I’ll keep trying to refine my projects to see if I can get better results, but, as you aptly worded it…this is insane. It’s gounna be all up hill from here.

If anyone out there is still mapping, and is having a similar memory issue (you poor soul, who ever you are) I’ll post my findings here so that other people may learn from my mistakes/example/craziness/expense.

[ronboy]

I too map, not for Quake III Arena, but for Rtcw Sp. These 2 games use the same engine, so I might have a problem sometime that you have had and solved. Good to see some mappers are around to this day. :stroggtapir:

[obsidian]

There is no shortage of mappers in the world, it’s just that the less determined ones have long been weeded out.

[VolumetricSteve]

Yeah, I keep coming across college/doctorate level projects that seem to center around quake 3. Also people seem to have an odd fetish for porting it to every cellular device on earth. It might never die.

Unfortunately, there are notably fewer of us, which is actually why I map the way I do…if these are the last days of vanilla quake 3 mapping, I want them to be remembered in their most maxed out state possible. Someday people will look back and see exactly how good something from 1999 could make a level look.

[ACROBAT]

cool any more pics?

I wish to play that map when it’s done so repost/

[ducks]

Part of the level design process is to work within the limits set out by the engine and tools, and to efficiently use their power and flexibility. Talented level designers cleverly work within these rules to produce levels that sometimes the original programmers never thought technically possible!

So, instead of trying to move the goalposts, see if you can do something differently.

Creating all those brushes and polys for a checkerboard floor is really not the way to get the look you’re after. Make yourself a checkerboard texture, and use what it gives you back in a more inventive manner.

…work with the compiler, not against it.

[ailmanki]

I would try using ASE models for extending the limits…
You can then use patchmeta to create an ase out of your patches…
Dunno maybe a checkerboard ASE consumes less off these limited things.

[VolumetricSteve]

ACROBAT - checkout my website for download links and screenshots

http://sirventolin.webs.com/

ducks - I understand that’s how the world works and that’s how a lot of great content has come into being. That’s just not what I do.

ailmanki - interesting idea, but I don’t know thing one about ASE models except I can generate them from other models but I feel like you might be right about their use.

[ailmanki]

http://en.wikibooks.org/wiki/Q3Map2#Creating_an_.ase_model_out_of_brushwork

Basically you can just copy your map, remove all which is not be exported into a model, add that box for leaks and create that ase in a few steps. Probably you will have troubles with Player clipping, AFAIK NetRadiant’s q3map2 can produce different results with new keys for misc_model (http://dev.alientrap.org/projects/netradiant/wiki/Complete_list_of_entity_keys).

Though I think those things are also merged back into other forks of Radiant…

Curious what you are going to build next