 Why Not?
#517 posted by ijed on 2011/03/26 13:59:26
#518 posted by necros on 2011/03/26 19:17:34
i did that exact thing in that blue coloured ruins map i posted shots of. i had detail brushes that were interchangeable so i'd just put in the appropriate ones and leave them all seperate.
i ran out of vertices doing this and i had to go back and combine all func_walls in one room together so the compiler could start to cut out vertices and such.
you can be sloppy and leave your func_walls seperate in a small map, but once you get to a certain size, you'll need to go around optimizing again. :(
that said, i'm not sure i'd be entirely against making some kind of new bsp format which allows a much larger amount of vertices, clipnodes and such. i know that the new limit imposed by metl's original fitzquake of 65536 vertices cannot be broken without changing the map format.
#519 posted by mh on 2011/03/26 19:21:00
There are plenty of reasons in a traditional Quake engine to not do this, including the fact that traditional Quake engines will choke on rendering so many brush models. The RMQ engine does not choke on brush models. Like I said - throw out your current understanding of what the renderer is good or bad at, because it's no longer valid.
Reasons that remain include having them count against MAX_MODELS, having them count against MAX_EDICTS, and having to have physics run on them on the server.
Reasons in favour include accelerating visibility calculations and producing a much simpler BSP tree (which gives perf gains elsewhere too).
Look on this as an intermediate step. The longer term plan to take those func_wall entities, merge them back into the world, convert them to detail brushes and produce a BSP that draws them as part of the worldmodel. The func_wall'ing of entities is just step one along the way to that, and has the bonus that it will still work even if the longer term plan doesn't work out so good.
#520 posted by mh on 2011/03/26 19:28:35
The 65536 vertex limit is one that's already been hit in an RMQ map - even without any func_wall'ing.
The most obvious solution is to take the standard BSP 29 spec, convert some of the data from unsigned short to unsigned int, and produce a new BSP format that doesn't have those limits. It would have the bonus of keeping the map format identical to before, but would require tools work as well as engine work to support it, and would obviously need buy-in from outside of the RMQ team.
#521 posted by gb on 2011/03/26 22:36:33
It's definitely intended that innovations made during the creation of Remake Quake should benefit everybody.
It makes sense to look at what other people need or want. Because we got quite a bit of dev power in one spot here, and there is a bit of networking going on as well. That gives us a bit of leverage to do "uncommon things".
I guess if an extended BSP format (ie limits removed, "detail brushes") would be used outside of RMQ, that'd be all the better. Then we might as well do it right (TM).
Terrain generator not Quake: I dunno, I think it remains to be seen. :-E
#522 posted by mh on 2011/03/27 03:40:42
Ultimately all that a terrain generator would do is build standard brushes to put into the same standard .map file to be processed by QBSP/etc in the standard way; no different from any map editor in other words.
One must always remember that unless explicitly stated, any talk of new stuff should always be read as if "...and it will work just the same way with standard tools" was appended to the end.
#523 posted by gb on 2011/03/27 03:57:35
A terrain generator simply allows us to build large outdoor areas in a more intuitive and user friendly way than "create 5000 triangles; then start using vertex manipulation..."
Even thinking of that makes me sick. Something like this looks like a really good idea at this point:
http://www.youtube.com/watch?v=FckhbVHqeoA
 Obj2map
#524 posted by grahf on 2011/03/27 09:51:32
It exists. Rather old mac-only commandline tool. http://quake.chaoticbox.com/
I'd offer my tech support for Mac RMQ but I know zero about coding and compiling.
 New BSP And Other Tech
Whilst working on my own maps scale rather than detail has become the main thing that I enjoy, which is a shame because of how poor the engine is for it. I really like the feeling of the world you're in being huge, and that the part you are exploring is only a piece of a giant world (even if you never *actually* get to it), a feeling that I got from Necro's latest map and that fantastic mountain range.
So I was wondering who else would think that a great edition to a new Quake map format (or whatever is involved to make it work) would be 3D sky boxes. Preferably something like Half-Life 2's where the skybox is scaled up to allow a smaller area to appear massive.
 Watch This Space
#526 posted by ijed on 2011/07/02 18:22:26
 If You Enjoy Massive Maps,
#527 posted by dooomer on 2011/07/21 02:15:41
try putting Q3A maps in dpmod, and run them in dpmod using darkplaces and "deathmatch 7". You sort of get a dmsp experience with this setting, but playing in all those gorgeous Q3A maps.
 Fair Enough
#528 posted by ijed on 2011/07/21 02:49:17
 In Fact
#529 posted by ijed on 2011/07/21 02:51:18
Engine developments aside, I've taken on board some of the discussion over my past few func visits and yeah, the immersion is better when you're a speck in a large world, making your way through one part.
It can lose the focus a bit though, for Quake.
 RMQ's Episode 1 50% Layout Complete
#530 posted by gb on 2011/08/03 18:19:03
You seriously calling a map Necrophilia? :p
#532 posted by gb on 2011/08/03 19:18:58
Yeah :-)
I mean, we all like Quake a lot but, ew.
#534 posted by [Kona] on 2011/08/04 00:07:38
Cool update GB! Those screens look great. You could always take the best bits of the other base map you did and merge it with one of the others. not sure what though, e1m2 wouldn't make sense and e1m1 doesn't need it. It would make e1m1 suitably epic though.
Looks like rmq is a good few years away yet though :(
 We Indulge Ourselves Too Much
#535 posted by ijed on 2011/08/04 03:11:44
Or too little.
#536 posted by metlslime on 2011/08/04 22:04:37
I'm glad to see this project is still moving forward. Are you guys considering releasing one episode at a time? Otherwise I fear it will be 2020 before we see this thing.
Also, what do you consider "layout complete?" does that include brush detailing, lighting, texturing?
 Well
#537 posted by ijed on 2011/08/05 02:08:11
We'll be changing our release format to make things more streamlined and to work on a easier to handle scale. It will also mean more releases, albeit smaller ones.
Thanks for the interest.
 Layout Complete
#538 posted by gb on 2011/08/05 11:49:32
100% layout complete I consider this: all areas actually exist as brushwork, not just as plan, and the map can be "played" from the start to the end along the intended route.
My calculation includes basic brush detailing, lighting etc. because I do these things as I go (other people do it differently). The %ages really mean "map roughly finished to this degree".
e1m6rq is layout complete according to the definition above, but the %age is only 90-95 because I subtracted some amount for needed rework, which might include switching rooms around, joining rooms, changing lighting, adding some secrets etc.
The calculation does not contain the creation of additional props etc. If we did the same calculation for the entire project, we'd have to figure in many more things and we'd probably not be at 50%.
Especially things like voice acting, rigging and animation proceed at a really slow rate, and implementing features to the engine is also really hard work and not always just quickly done.
The map layout is so important because coming up with stuff and creating the basic brushwork of the levels is the hardest and most important part of the level design. It's also what took me longest to get reasonably good at. I tended to overthink stuff in the past before committing to brushwork. But once it actually exists (even if it's just orange cubes), it can be tweaked. Making it exist is the main challenge.
My calculation includes basic brush detailing, lighting etc. because I do these things as I go (other people do it differently)
I've got approaching a dozen or so nearly complete layouts with ten to twenty minutes of gameplay and no graphical detailing :(
I'm more and more thinking of just releasing my maps as collections of as-bug-free-as-possible speedmaps cause I more and more can't be arsed with making levels pretty. It's not what I enjoy at all, even though I like the idea of it, and I'm impressed by what you can all do with brush work, but man is it just infuriating for me. So for me layout complete has nothing to do with actual geometry.
I'm curious to know how others mix the two as well. How many people plan stuff out on paper or in the editor extensively before beginning the proper architecture, vs your approach of building the layout and architecture as you go.
 Zqf
#540 posted by nitin on 2011/08/05 14:34:19
just give them to someone else to detail.
Plenty of people here dont like the layout side of things but like detailing.
 Heh
#541 posted by ijed on 2011/08/05 14:38:51
That sounds a lot like me - I have little patience for lighting or making cool looking stuff, but spend a long time moving monsters about and completely reworking the flow of levels almost on a whim.
It can be cathartic though to chill out and texture a wall, or make textures for it, or build a skylight or temple.
When building I box things out fairly quickly with a loose idea of the gameplay I want, making mental notes of what goes where whilst I build.
Long term projects like RMQ are trickier - like Gb, I've got episode 3 layout complete (apart from the secret map) but I suspect I'll be rebuilding each map about 70% just because they're not up to quality.
I find that a series of strong ideas can make even the most visually simplistic maps work great. Then the simplicity becomes part of its style.
If the detail that it does has and texture choices are clever, then even better.
|