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
One Should Always Snap The Vertices 
But it's not obvious to new mappers. When TB was released, I actually expected it to do this automatically - making perfectly valid, grid-snapped trisoup terrain/brushes without additional user input. Easier said than done apparently. I suppose a notification popup ("Do you want to snap/validate brushes?") before saving wouldn't be the smoothest solution, either. 
Snapping Verts 
This is actually what I meant by dumb down. This would solve all problems, but there may be situations where the user wants off grid vertices? 
Wanting Offgrid Verts. 
most of the time I'd say you don't want off-grid verts, but I know for certain in my map there are a couple of instances where I *do* have them (on purpose). But you'd be unlikely to tell if you looked in the editor as they are clipped along the same plane as another brush that *is* grid snapped properly.

I think I'll stick with v1.05 and just run through the motions of checking at every stage. 
Func_unsnapped 
Fringe cases, certainly. Again, a Quest example (call me neqer): you could generate brushes of certain geometric shapes which would rely on lenient treatment of vertices/coordinates. Snapping them to the grid triggered a bunch of consistency warnings; leaving them unsnapped could make their vertices 'wander' with each save/reload sometimes. I used it to make trees
 
also arbitrarily rotated brushwork can be compiled correctly when the vertices are off grid. most of the cooler bits in CZG's honey are all off grid. 
Off-grid 
I can't think of an instqnce where this would be beneficial. But then again I have my own boxy style of mapping.

Why not make it an option, default on? 
Negke 
So you resave multiple times to get irregular spheres?

Maybe that could be a 3dsMax style 'noise' function...

Which could also be used to instantly generate terrain - and then tweak it to fit the level requirements with the vertex tools. 
Very Loud Ambient Noises 
Now that I have a map that compiles properly I have noticed that the ambient sounds for the water is very loud. What gives? 
What Compiler 
Are you using?

It shouldn't affect anything greatly, some of Bengt's stuff allowed for control over the ambient sounds from sky volumes as I recall.

Quake sounds function on visibility, more than audiable range. They're quite primitive in that respect. Maybe you don't have enough other ambient sounds? If they're drowning out weaponfire or monsters then something very weird is going on. 
 
to avoid confusion:

there are 2 types of ambient sounds:
- point sounds which are made with ambient_* entities and attenuate with distance centered on the entity.

the other type is area ambient sounds which are based on if specific vis leafs that contain either sky or liquid are visible to the player. in simpler terms, if the player can 'see' water, then a water sound plays, if they can 'see' sky, then a sky sound plays and this sound is full volume until you can no longer 'see' the area in question, at which point the sound just stops. 
Off Grid 
Would still be possible as the result of anything but vertex editing. Going into vertex mode would snap the veers however. 
Necros 
Honey is all on grid; The 0.125 grid. 
Ijed 
It's the contrary, actually. The sounds function on range. Otherwise you would run around a corner and the all the ambient and monster sounds from the previous room would suddenly stop. More often than not you also hear sounds through solid walls when they really should be blocked for logic reasons. 
I Have Only 
used slime water portal/brushes but they're real loud. At the moment I'm just using Bengt's TreeQ alongside Tyranns light/vis, once the map is done I'll be using his bsp tool too. I tried using -noambient and -noambientsky but vis recognises neither of these things and it doesn't vis quite right. 
So... 
you guys are saying that snapping vertices usually fixes most brush problems? 
SleepwalkR 
Version 1.05 managed to fix the more simplistic geometry in my map that I created in version 1 that was creating the errors. It didn't work on the really crazy terrain geometry that I had made. But I have yet to retry making the terrain, I have some ideas on how best to approach the terrain but my fear is that I will be fudging around the real problem (and I could still end up creating bad shapes that you can fall through), we'll see how it goes. 
Did You Trisoup It? 
Because the more planes you have per brush, the more likely it is to get errors. 
SleepwalkR 
I made a grid of cubes and then selected all of them so that I could edit multiple vertices at once. I hope this is the right method. 
 
Czg: is that an important distinction? Maybe if TB snapped to a 0.125 grid? 
Which Compilers/editors Support That Size? 
Isn't that idTech4 resolution? 
Doesn't Matter Ricky 
The compilers don't give a shit because the map files only contain the planes. 
FifthElephant 
Sounds good to me. Necros? 
SleepwalkR 
So it's an editor restriction?

I'm just asking because I've been dealing with 24 sided circles and curves, and there are severel limitations on what can be done with a 1x1 grid, at the scale of Quake. 
Severel??!?! 
several? or severe? Take your pick. Was meant to be the latter.... 
Yes 
It's an editor restriction. 
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.