News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
 
OK, thanks.
I thought it only had to do with speed, so gameplay doesn't become choppy. 
 
Speed is a large part of the reason but there are other concerns, yeah. 
Also 
There's lots of ways to build a map where full vis doesn't have to take weeks. Level of brush detail, turning details into func_walls, making LOS blocking 'doughnut corridors' putting clip brushes inside small holes and so on.

Its finnicky stuff to do, but it makes the map very easy to compile - which is important for betatesting, since not everyone has a powerful machine as mentioned. Some might be emulating in Wine or have other issues.

My Quake machine will have trouble on non-fullvised maps, for example - a decent incentive to keep my maps well built. 
 
"putting clip brushes inside small holes and so on. "

I don't see how this would improve VIS times. Clip is a collision thing while VIS looks at the rendering side of things, right? If you meant plugging up holes with solid brushes then, yes, that would help... 
Too Many Static Entities Is A Bad Thing 
the consequence is that some static entities wont appear in game (like torches and stuff)

AguirRe's engine should tell you how many static entities you have and what the limit is (256 IIRC)

Take some out and replace them with other light sources (i.e. light textures) 
Ok 
Not vis help, but general good building of the map.

For example putting a crate in the centre of the room on the floor or putting a crate in the centre of the room floating 2 units above the floor.

The second one is better (and invisible to the player) because it causes less subdivisions, which also helps compile time. 
No. Wrong. Don't Do This. 
 
Nevermind. I'm Wrong. But It's Still Dumb. And Makes Extra Portals. 
 
Hmm 
As CZG so eloquently explained, while this will indeed reduce subdivisions of the floor, the saving in VIS time/polycounts will be negligble when compared to the creation of many tiny, tiny vis portals under the crate (which'll slow down you VIS a fair chunk, especially if done with every crate in a level (there should be as many as possible)) 
Hm 
Fair point - I'll go back to my cave now. 
 
It's not dumb. It can lower the polycount considerably (depending on the area) and I doubt a few additional tiny portals will slow down VIS "a fair chunk." There's a more definite risk of ugly shadows beneath/around the crates, though.

However, speaking of poor VIS design: I'm now (again) stuck at a slow portal with no progress for a full week. 
Nasty 
 
 
found something interesting out about the hipnotic rotating stuff.

had never noticed this before, but you can attach ANY entity to a func_rotating_*

as long as the entity's targetname matches the target field of the func_rotating_*, that entity's origin will be continuously updated to match the position and angles of the rotater. i haven't tried, but i suspect it may not work with bmodels because of the way quake handles those, but point entities (even monsters o.0) work.

i was able to build a func_rotating_train which had torches attached to it as it moved about.

the effect is kind of ruined if the rotater actually does rotate though, because the angles of the child entities aren't updated, only their positions. 
 
clip brushes would help with BSP times as it's already telling BSP what areas to not put hulls. Some of the best ways to avoid high vis times is to avoid small brushes, huge open areas, and overly complex geometry (which is boring to me.)

I've never really understood the entire fretting about vis time other than your giving up use of your machine while vis takes place. Why should it matter if it takes 1 hour or 1 day as long as the map has good game play, is built properly, and looks great?

Most people playing these maps aren't wondering how long it took to Vis. They're having fun hopefully. 
Dear Programmers: 
Detail brushes have existed in Quake (1) for a long time.

http://quest-ed.sourceforge.net/files/mapc/qutils_2_src.zip
http://quake.chaoticbox.com/downloads/equakeutils.sit

It's a pity they've never been incorporated into more modern compilers, because they really do work to cut down vis times. I used pOx's eUtils quite a bit back in the dark days of mac quake editing. They even have nifty features the Quest tools don't, like non-solid detail brushes. So you can have your func_walls and func_illusionaries, but they still cast shadows etc. 
AEnoch 
The problem is that, these days, people are making maps that don't so much take days to fullvis as weeks.

It wouldn't be so bad if this trend wasn't utterly unnecessary... 
No Q1 Map 
I've ever made has taken more than ~5 hours to compile.

Someone's about to post a warp map compile of 6 hours to prove me a liar.

Remember that this is a mapping forum, on the mapping help thread - this is the place where we complain about vis times. 
Yeah, But ... 
In reaction to post #8797 posted by Lardarse:

Yeah, but if someone was to come up with a decent map, about ID sized, who would take notice ?

If you look at the work of people like Ijed, Tronyn, CZG, Necros, Kona and Kell(to name a few of the best ever), it's almost all huge. And I like it.

ID's Quake was great, but what these people have made is so much better. Better even than all the crap games you can buy in the stores these days. Works of art that inspire people like me to try and come close to, even without having all the knowledge that they've got. 
 
The size of the map shouldn't matter though. Proper construction and respecting the engine should result in reasonable VIS times. If you build a gigantic football field with bleachers, well, yeah, that will take forever to VIS but in my mind that isn't proper construction.

You can build a large map and still have VIS be reasonable.

Having said that, my current map is going to be a bastard once it's sealed. I've committed a lot of VIS sins and I know the VIS gods will punish me for it. 
 
"Yeah, but if someone was to come up with a decent map, about ID sized, who would take notice ? "

A map the size of an id1 map that was nicely detailed and well put together would be well received I think. You couldn't duplicate the originals and get away with it anymore but that size of map isn't necessarily a problem, IMO. 
Fuck Limitations... 
... do whatever you think is cool... And you end up in a 2 month fullvis map :P 
 
I dunno. I guess I'm of the mind that you have to keep evaluating your 'return on investment'. A map that takes 2 months to VIS isn't necessarily 60 times better than a map that takes a day. It may just be built wrong. 
Lack Of Skill / Knowledge 
I agree that lack of skill or knowledge is the bottleneck for people who start mapping. Even people who have been doing it for years could be making things more difficult for themselves without them ever knowing. That's why it is a shame that so many websites dedicated to map making are disappearing. 
 
ID's Quake was great, but what these people have made is so much better
bear in mind that id's levels was made ~95/96, do you remember, any custom levels of such quality those years? 
I'm With JPL 
If I build a map and people enjoy it, that's my return on investment (your pleasure is my pleasure, in a non-kinky way). I map for fun, not for money. My computer is not a 'resource', it's a hobby.

Sixty hour vis times is fine by me, I'll be doing plenty of other things in the foreground. So, time is not the issue: impatience might be. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.