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
Well 
I was talking about what to avoid specifically for TB. Apparently there are some things which will lead to bad brushes etc. and I'd like to know how that happened. 
SleepwalkR 
The map design videos would be TB-centric.

In terms of how to avoid bad brushes, who knows? I never took off grid snapping and I almost never went below the standard 16 units. I think some brushes just "become" malformed if you play with the vertices too much or you make shapes that are just too crazy!
Even some of the (very plain) curved walls which were grid aligned had become very very slightly nudged off the 16 unit grid. It wasn't until I did the correct/snap vertice trick that it was fixed.
Again, the tools used for pointfiling and treeq really helped me to get to a water-tight map. Though I think whatever you fixed between version 1 and 1.05 obviously helped a lot. I just hope I can redo the terrain, that *IS* after all one of the big selling points of TB ;) 
Turns Out TB Was A Trojan Horse All Along 
A QuArK in disguise!!! 
Here's Some Advice... 
I was using the co-ordinates and the pointfile to find leaks (as is the standard procedure), and to locate them easier in TB I was dropping in a monster_boss entity and entering the co-ordinates in the "origin" key, then when the entity moved I would delete and replace it with a shambler (again with the same co-ordinates), and then with a rottfish. Only last night at 3am when I was looking for the leaks I had forgot to take the shambler out the map when I compiled the fixed map... It scared the bejesus out of me! I decided that was a good time to stop mapping and sleep. :D 
I Think 
those problems are mostly the result of imprecisions when loading the map. I'm working on an improved version of the vertex generation algorithm that will do a better job of avoiding degenerate edges and faces.

An edge is considered degenerate if it is very short (shorter than 0.5 units) and a face is considered degenerate if it is a triangle and contains such an edge. This should help avoid such problems, however I can't predict whether QBSP will do the right thing, too. But I think everything will be much better if I can switch TB to use only integer plane points. 
Negke 
You're not too far off there, sadly. 
 
those problems are mostly the result of imprecisions when loading the map. I'm working on an improved version of the vertex generation algorithm that will do a better job of avoiding degenerate edges and faces.

That might explain why some problematic brushes (one that caused a crash for instance) look completely different when reloading the map?

In terms of how to avoid bad brushes, who knows? I never took off grid snapping and I almost never went below the standard 16 units. I think some brushes just "become" malformed if you play with the vertices too much or you make shapes that are just too crazy!

Pretty much my experience.
One thing I think can be problematic is adding new vertices, in certain cases those can create strange n-gons that almost certainly will get screwed up after a while. Also dragging planes on a non-grid-aligned plane tends to end up badly a lot of times (especially in conjunction with above case). I guess that kind of makes sense when you think about the floating point issue... 
Spiney 
That might explain why some problematic brushes (one that caused a crash for instance) look completely different when reloading the map?

It might ;-). I can't say without seeing an example. 
It Almost Sounds Like... 
you're running into the same type of problems that plagued Quoole 0.99 (creeping brushes). I hope that you can figure it out and fix it. 
Possibly 
I promise that I will find a solution, even if that means that vertex editing has to be dumbed down a bit. 
Dumbed Down Crushes Creativity 
That would be a great shame because this is one of the best features of the editor. It would be a shame to fall into the trap of GTK 1.5 and force mappers to only create limited brush shapes because of vertex problems. Personally I prefer the ability to push brushwork to the limit and then have tools that look for problems afterward.

I personally use SDRadiant 1.8.3 and when I get issues with brushes I take the brushes and cut them. This forces the editor to re-generate all the planes and this usually fixes most of the problems. One other solution is I use an editor plugin called Bob's Tools. This goes through the whole map looking for potential brush plane errors and re-creates any brushes with problems. When it is finished it highlights what has changed (selected) so I can decide if to save/carry on. 
Yes 
I liked how Quest would allow me to make invalid-shaped brushes which I could sort out afterwards, whereas in GTK 1.5 I always have to go out of my way to create properly angled (rotated) or abstract stuff, because its validation system is so overly rigid and limiting. 
 
hi, was very busy today and didn't have a chance to check func.

i'd really need to see how the map is made to be able to tell, but a lot of the time, i found just snapping the vertices seemed to always fix my problems. i never really did anything special to get it to work.

sorry i can't be of more help. 
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. 
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.