Angled Brushwork
#20439 posted by wakey on 2020/03/10 17:36:47
For long time now i ask myself how you guys to angled brushwork in Radiant, like arches that lie on 45°, 33° or any other weird angles on the grid.
A great example for what i mean would be the huge chains in czg's q1 map Honey.
I try avoiding building stuff on grid 90° on grid an then rotaing it, as this brings the vertices off grid.
Some stuff i manage to do via a mix of csg_subtract and clipping, but for more complex constructs my brains 3D projecting algorithms fail ^^'
Are there any "cleaner" methods to do it?
#20440 posted by Kinn on 2020/03/10 17:46:14
i did a post here once about "magic" (aka on-grid) rotation, but fuck knows where that's gone - same technique czg did for those angled bridge ruins in saint.bsp
These days though, misc_external_map is your friend for a lot of this stuff...
http://ericwa.github.io/ericw-tools/doc/qbsp.html
In That Case
#20441 posted by wakey on 2020/03/15 13:38:49
i could do it with .ase geometry, as i am using Darkplaces with q3map2.
It's for a total conversion and use advanced features of both.
In some cases using .ase or a model instead of brushwork are not practical, at least that is what it seem to me.
And i guess the main problem in what i am trying to do is not the brushwork and it's limits, but my geometric understanding of things.
Here some screenshots of things i try to do:
https://imgur.com/a/Eg0E4ry
Maybe i asked even the wrong question, so i rather ask: how would you guys do that stuff depicted in the screenies?
I'll Be Honest
#20442 posted by Kinn on 2020/03/15 14:25:44
If you are doing stuff for the q3bsp format then it's a pretty good idea to use meshmodels/ase to work around the times when brushes just won't cut it.
For "seamless" joins of arbitrarily rotated meshmodels to surrounding brush geo, you'll want to use some artistic license and design the model in such a way so you have some "wiggle room" to be able to butt things into each other a bit and not look ugly - e.g. hide the joins with some raised trim or raised brick quoins or something
#20443 posted by wakey on 2020/03/17 00:57:49
I will for sure use that approach for more complicated geometry.
Just saw that screenshot of Wrath: Aeon of ruins in another thread:
https://imgur.com/Qg3VSqU
Would be interesting to know how that hall, especialy its in multiple directions facing door arches, where made.
At least that domed ceiling would be no problem with a trisoup.
PS:
Is Sock still around?
Another Wacky Experiment
#20446 posted by Aberrant on 2020/03/30 18:59:05
Built this ship for someones map and I wanted it to be a rotate train. I got it all working fairly well despite some tuning I can do later. But for now I have this movewall that doesn't rotate. So if you ride the thing straight or fairly straight everything is fine. Once the boat turns the func_movewall doesn't. Is there a way to make the rotate_object solid so I can remove the movewall entirely?
A video showing it does work on my server.
https://drive.google.com/open?id=158gR5W8kGsF8pER2jKuH7wUifnlQOuv0
A link to the bsp. It meant to run on teamfortress with hipnotic ents added. So that means megatf and custom. I haven't tried other mods to see how it works.
https://drive.google.com/open?id=1JP77gLYtk6RX0D6FpH84gemy13pCwzeN
#20447 posted by metlslime on 2020/03/30 19:48:57
bsp collision can't rotate without an engine feature. (this does exist for some engines, can't remember which, but Baker had it in MarkV I think?)
The movewalls are basically a hack to get around this -- you actually need many small movewalls, each one will not rotate, but the positions of them all will orbit the origin of the object to sort of make it work. For example if you put a movewall for just the mast of the ship, it would correctly move with the mast. Warning: You will need a lot of movewalls.
Bsp Collision
#20448 posted by Aberrant on 2020/03/30 19:57:10
Yes, I read through preaches site on all this. The server I intend it to run on will be FTE. I wont do the many funcwall thing, but I appreciate you suggesting. It would take way to many to simulate what i need here. I am pretty sure it can work, a non solid into a solid, but setting movetypes and avelocites blows my mind.
WTF Too Few = Too Many ?!
#20449 posted by Inky on 2020/04/06 13:56:45
Dear skilled mappers,
As a beginner in mapping, I'm facing an unexpected (but probably well known?) issue.
The number of monsters and entities in my map is quite low, and anyway far below the standard number in the original editor's maps.
The original game's maps display without any problem, whereas my map doesn't: it seems a threshold is reached concerning the number of monsters/entities and the most recently added ones are not displayed (as a player I am attacked by an invisible opponent, an invisible brush entity blocks my way, etc.) The entities beyond the threshold index behave normally except they are not drawn by the engine.
This occurs very soon in the mapping process, even before I really start to populate my map with monsters, as if all the available slots for entities would already be taken by doors, lifts, lights, artefacts or whatever. Yet the number of those is, once again, really low. Especially compared to how many entities are found in the game's original maps.
Any help would save not only my day but weeks of work, actually.
Thanks a lot in advance!!!
First Things First
#20450 posted by wakey on 2020/04/06 16:24:14
This could still be any number of problems afaik, so lets narrow it down:
Which engine do you use?
Even "standard" Quake could mean three different ones: DOSQuake, WinQuake or GLQuake.
What mapeditor and compiler are you using
Have you tried loading your map in another engine and see if the problem persists?
How many entities are there actualy in your map?
Are your sure your map does not leak?
Make sure your map does not extend past + or - 4096 units on any axis.
If it does and you can't shrink it without negatively impacting your map, compile it with the "-bsp2" command line parameter (for bsp.exe) and run it in a modern engine.
Also, if your map has lots of entities it's probably a good idea to make sure you're running protocol 666, not protocol 15.
I Thought..,
#20452 posted by madfox on 2020/04/06 16:43:09
A usual Q1 map can have 37678 brushes and 640 entities. If you have less, than another error has faulted.
Check Your Functions
#20453 posted by madfox on 2020/04/06 17:19:31
Are you sure there are no "empty functions" in your map, like a func_door without arguments? It is easy to add a func and forget to add arguments. You would hardly notice.
Most times these cause a "too many edicts" error.
Good Guess!
#20454 posted by Inky on 2020/04/06 17:34:16
Thank you for your quick answers :-)
I actually map for Hexen II. The only engines supporting it that I know are Ultimate Quake Engine 1.13 and Hammer of Thyrion. I have the problem with both of them.
My map editor is Trenchbroom 2019.6
My compiler is ericw-tools-v0.18.1-win32\bin\qbsp.exe
Without counting the world, there are currently about 220 entities in my map which is probably far below the limit (although I don't know what that limit in Hexen II is compared to Quake's 640).
My map IS actually leaking. Good guess Wakey! I would have never thought about that because it seemed to me that leaking problems were far behind for a while... and I must confess I still can't understand what the problem is. I open the pts file and carefully follow the "leak line" in TB but at the places it goes from inside to outside, it simply goes through solid world brushes and not between them through unnoticeable interstices as usual leaks do.
So now I know it's about leaking, but I can't figure out what the leak is.
Shall I very humbly and respectfully submit my map to one of you to get their insight and improve my understanding please? I would be most grateful for that!
@Shamblernaut: the actual count of entities doesn't seem to be the direct responsible but as a side note, what are protocol 666 and protocol 15???
Actualy
#20455 posted by wakey on 2020/04/06 18:42:17
your map does not gave to be open anywhere to leak.
An entity by mistake placed into the void can cause a leak too.
At least thats true for q3bsp, so i asume that is a valid statement for q1 maps as well.
What shamblernaut was talking about are different network protocols.
15 is the original, 666 is an enhanced one, by Fitzquake methinks.
It's important because Quake works with a client-server protocol, so even offline in sp the gamecode communicates internally over this.
#20456 posted by metlslime on 2020/04/06 19:12:30
if you're mapping for Hexen II then the protocol 15/666 question isn't relevant.
Aside
#20457 posted by madfox on 2020/04/06 19:56:50
Leaks can be very tricky. Following the pts file will lead to the initial brush, but it always starts at one corner fading on a irragular vector into the void.
Very useful to set the sky brush dark and look with a 3d viewer along the pts line.
#20458 posted by Inky on 2020/04/06 20:58:57
About the protocols, got it, thank you for the precisions.
The pts line didn't show clearly the leaking point but went from inside to outside in an irregularly shaped part of the map (a cave). Certainly not a coincidence (thank you so much Wakey for having put me on the leak's track!)
I never understood where exactly was the leak but I found a workaround.
I encompassed the whole area into a giant square box. By chance the cave was a dead end and was connected to the rest of the map only through a rectangular tunnel. I just opened a square hole in the giant box wall to let the tunnel go through, et voilà!
Hop this trick could help someone in a similar situation in the future.
As a side note, strangely enough brush entities or water brushes partially in the void don't seem to cause a leak. I have the impression that the only "entities in the void" counting for leaks are model/point entities...
Thank you again to all of you for your help.
#20459 posted by metlslime on 2020/04/06 21:57:52
the "put a big box around a leaky area" is an old trick, and it does work, but you'll have longer compile times and a larger BSP than if you actually plugged the leak. Depending on the cost/benefit analysis, might be worth finding the actual leak, or not.
Planning Routes
#20460 posted by wakey on 2020/04/09 09:11:37
is something i want to learn more in-depth.
Just can't properly wrap my around yet.
How did you guys learn it and do it now?
Learning by playing doesn't seem to do the trick for me.
My guess is that most of you will already have a rough idea of the routes in a map in your head when starting to block out a rough layout - is that right?
To you take notes and sketches beforehand?
Like "I want this traps in that map, that many arenas..."?
Especialy interleaved routes with some backtracking and opening paths give me a headache, but my guess is that im thinking about them the wrong way.
Yes.
#20461 posted by Shambler on 2020/04/10 10:40:20
Sketch layouts first - including approx player routes, likely combats etc.
My Nitwitz
#20462 posted by madfox on 2020/04/11 01:20:20
32768 brushes - 620 entities standard quake
I often asked myself what happens on the edge of the 33768 brushes. Having a map that big gets weary adding one brush or deleting one entity.
Still the knowhow behind it isn'nt clear to me.
Let's say I have map with that account. It is widly surrounded in the editor with all kind of edges. I assume the compiler uses all that outer brushedges to come to that 32768.
Then, would it be of any use to pull all outer edges to one line so the outside would be a cube with only 8 sides. It should make a difference, or am I just short sighted as these outer brushes get deleted after compiling?
|