 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
that you might also want to check the Vis Issues section of my ToolTips for detail brushes in Q1. Please bear in mind that it's not any Magic Bullet, but might be useful in some cases with a bit of planning.
The reason I'm very interested in this method is because I'm planning a large scale map that will be almost entirely rocky terrain.
I'm also currently working on another map that has a fair bit of terrain in it, but it has all been constructed with the "triangle method", which is a nice safe method that gives good results, but is very time-consuming, and isn't very useful for really freeform stuff like in the Alice screenshots. The "overlapping boulders" method seems like a really quick way of building terrain, but the map I am planning would consist of hundreds upon hundreds of brushes overlapping in this manner - I just wondered if it would be a realistic option. ag>What do you mean by crash in vis at 70%, does it actually crash (with a dialog from the OS), or just seems to be stuck on the same position for a long time?
OS crash on my decompiled map elmdm5 which I fixed up since then with colored lits and map fixes. It worked just fine many previous versions of vis. It took about 1 hr to compile on my p200: treeqbsp, vis(that website), and tyrlite. as Just read the relevant bits, aguirRe, and it got me wondering: just how big can I make a func_wall? You mentioned that all the brushes of a single func_wall must be in the same area, but would I also run into problems if I made a REALLY big func_wall?
I've no idea how the compiler (or probably more important, the engine) will handle very big func_walls. What I know is that entity brushes seem to be less efficiently rendered by the engine so you can't go overboard with them.
Also, the reason why you should keep all parts of one func_wall in the same area is that otherwise the engine will have problems knowing whether to render them or not according to the vis PVS (potentially visible set). In any case, I wouldn't suggest relying too heavily on assumptions of qbsp/engine, you'll have to trial and error step by step. parts of your func_wall will not be drawn if it crosses too many bsp nodes, becuase each node it crosses creates an efrag. So as you walk around, you will notice those pieces appearing and dissapearing.
When I was a less knowledgable mapper, I was working on a terrain map for Q2 using almost all overlapping brushes for the rocks -- I'm talking 26 sided cylinders clipped and skewed every which way. When I compiled with the standard tools, it took 4 or 5 days to get half way through it, at which point my computer would just shut down. It is unrealistic to build large areas of rocks/terrain in this manner.
In conclusion, the best way to the kind of map you are talking about is to build it mostly from triangle meshes. A pain in the ass, yes, but you will have very few problems. Hello,
It seems that major problem than mine occured these night, and then nobody answer my basic question... grrr.. Anyway, I'll retry now: I never used lift (and train as well) into map, and I would like to use them for the next one. So, How can I build a lift with for example 3 stairs, with 3 call buttons on each stair, and the possibilty to choose the stair destination when into the lift ?? It's like our real world lift..... hum... Is there somebody who knows how to do that ?? Thanks I think I'll stick with the triangle method for the time being, until I'm ready to move on to a newer game engine.
=== JPL: the closest behaviour to what you require can be achieved with a func_train, but only if you use the Hipnotic QC source, or equivalent QC which allows trains to pause at each path_corner, waiting for retrigger. Note that you won't be able to have call buttons inside the lift though, because you can't set up buttons that move as if connected to the lift. If I were you, I shouldn't worry about trying to do complex mover behaviour like this until you've mastered the basics. Once you can make great "vanilla" Quake maps, then you might want to start thinking about custom QC etc. Hope this helps :) Thanks for this quick reply.
If I understand correctly, it will be very hard to perform a complex and complete lift feature with more tha 2 stages... grr.. And as well, I need to "trigg" the path_corner before it let move the "func_train platform"... but what about the waiting field ?? Do I need to set a wait -1 to stop it ?? But if I set wait -1, does a trigger will be enough to restart the lift ?? Sorry but I'm not sure about the right methos I have to use... Thanks You will need to use a "func_train2" in the Hipnotic QC code to make a train (lift) that is capable of stopping and starting.
In the path_corners, set "wait -1". This will stop the lift when it reaches each destination. The train will then need to be retriggered to start moving again. Note that this is fine for movement between two floors, but as far as I am aware, if you want to give the train a choice of paths (i.e up or down), in a 3 stage lift or more, you will need to write custom QC. Concerning QC custom code, I'm not a very well software designer (C code is not my "cup of tea"...)... so, forget this option ;-))
I'm currently building a base-based map using 3 stairs (perhaps 4, it's not yet clearly defined) and an unique lift to reach each stairs should be great... I will see later how to build it, perhaps with an automatic one... Anyway, thank you very much for these quick replys, and for the informations.. Regards. You could also check out the Custents pak; I think it also has some func_train enhancements. Get Custents at Fat Controller's site http://www.planetquake.com/fatty . Look in the downloads section.
...for the moment, use the Oubliette method. Have the lift (train) access all levels in a continuous loop, but restrict access to all areas until certain buttons are pushed.
This method was the first idea I had... and it seems that I need to come back to it !! Anyway, I've just started the map, and there is still long way before designing the lift... I still have a lot of time before taking a decision about what kind of lift (or several ones.. ) I will use..
Thank you for this advice Using triangle method for terrain is great to avoid huge plane terrain, or cliff in a map.. As described in VoreLord related links, you build a surface using triangles.. It is very easy to build if your map editor includes a "brush splitting" tool like described... But in some editor it doesn't exist (like QuArK).. you'll so have to build your triangle-based terrain manually using pyramid or tetrahedron polygons... and it can take you a long time (you can see an example with my "ugly" bunker map.. the dune terrain was built like this..)
You will have a cool look, but there is a bad news.. it increases painfully the VIS process time.. You will so have to find a trade off between compilation timing and polygons number... Hoping my poor experience gives you some further infos :) Regards.. Thx im gonna Make some kickass terrain now!
Kinda off topic but who wants to recomend a good QWbot? (a bot u kill not a bot that kills for you) I don't know about a "QWBot", but for normal quake, you can't really go past the Omicron
http://www.fileplanet.com/dl.aspx?skorpion/files/obots102.zip especially with an The easiest method by which to create a terrain mesh is, of course, GenSurf. It's fun. Lots.
Combining it with Terragen I can create my heightmaps from pseudo-fractals and a bit of elbow grease in PSP. This gives lots of control over the look and feel of the terrain overall and also allows specific modifications to be made in respect of conventional brushwork, Vis, LOS etc. Even to the level of adjusting one/several terrain vertices by as little as 8 units z-axis by simply changing the color of a pixel. Optimising the terrain is another matter. Grouping the whole lot into a func_wall requires that vis blockers be constructed inside the terrain, as per the Q3 terrain method, and with the hope of casting appropriate shadows where the func_wall sadly will not. Using a single func_wall for a large terrain is also going to shatter the thing into a multitude of efrags, which could look bad as whole rock formations blink in and out of existence due to the vagaries of your PVS. Strategically grouping pieces of the terrain into individual funcs is better and some terrain brushes could even be left solid where useful. I'm hitting all this stuff because I have been working on a large Q1SP terrain map for the last few weeks and have hit various problems, not least of which being the estimated vis time for a solid terrain version being something in the order of a month. The strategic func_wall method is probably what I'm going to have to resort to, unless I miraculously gain access to a state of the art processor. If you use GenSurf, I recommend a mesh resolution of 128 units/triquad. 64 is only really possible for small, isolated bits of rocky stuff in an otherwise 'architectural' map. 256 drops the brushcount+compile time+render issues considerably, but looks extremely naff and is a pain in the arse to traverse. A large terrain map is a beautiful thing to make, but think very carefuly about exactly what you want to do with it and if you really want to be so ambitious. I wish I'd given more thought to my landscape. In the absence of Q1 detail brushes, even the generous limits now pushed back by current compilers and engines struggle to swallow massive terrain. Despite its name, even Quake can have a hard time moving mountains :P
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |