Now that the veil of secrecy has been lifted, and - all going well - the rest of you will be able to enjoy the end result of this recent work over the next few days, I can talk more about what's been happening recently.
The very first thing you should do is read this: http://kneedeepinthedoomed.wordpress.com/2010/12/23/i-mapping-robot.
OK, the key point here from an engine/tech perspective is GB's comment: "I think we do need detail brushes".
This was a brutal map to fullvis, as you might gather. What's not mentioned (because it's not relevant to GB's post) is that I may very well have fried, or come close to frying, a 2x dual core Xeon box with this one too.
The current situation is that RMQ is hard up against the limits of what Q1 formats can handle. There is another map that is an almost constant battle to keep the number of vertexes below 65536. That one hasn't even been attempted to be fullvised yet.
So something needs to be done, obviously. What is that something? We don't know yet, but we're damn well going to find out. Tech should enable content creators to realise their visions, not embroil them in a constant frustrating struggle.
And that's all for now.
Thursday, December 23, 2010
Phew!
Posted by
mhquake
at
10:41 PM
Subscribe to:
Post Comments (Atom)
11 comments:
whoah @ the possibly-fried xeon.
Check the QuakeForge tools. Supposedly there is detail brush support inside!
I think THIS is the way to go..
(Using hint brushes to manually guide the VIS tool, giving the mapper more control over the process).
damn you guys are the personification of bad ass.
hey if your xeon gets fried. hit me up i have some lying around. for you free of course.
The Xeon survived. :)
I stopped the madness with almost 200 hours left to go (and over 20 done already!)
Hint brushes, alas, aren't good enough. When you see this map you'll know what I mean; it's the sheer number of generated visleafs that cause the problem. Detail is really the only way to go here.
But the idea of giving the mapper more control over how the vis process operates is absolutely spot on though.
Not sure if I did something wrong, but I just (afaik) fullvis'd the map in four minutes. More info in the func thread.
The released version of the map will fullvis in 4 minutes, but that needed huge chunks of the brushwork to be converted to func_wall, which caused trouble for some BSP compilers, wrecks shadows and hugely increases the number of models.
Oh, I misunderstood the 'I, mapper' post then. I thought fullvis times were melting xeons even with everything as a func_wall. :P
Anyone up for the challenge to make a GPU version of the VIS tool?
I'm not sure whether the process of calculating visibility would fit a data driven processor, but if it can be done, surely having 240+ stream processors would beat a quad-core CPU ;)
Maybe a prototype / proof of concept can be made in pycuda/pyopencl...
It's a neat enough idea, but there's only so far you can get by throwing processing power at this problem. The harsh truth here is that traditional Q1 map compiling is just not up to the job, and pretending otherwise is going into John Henry country.
Post a Comment