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: http://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
Distrans 
You seem to have a hull 2 leak. Take a look at my Q1 ToolTips: http://user.tninet.se/~xir870k .

Basically, the leak isn't visible and only shambler-sized ents will be able to detect it (by e.g. falling out). Inspect the brushes that intersect with the brush that the leak line penetrates. It's probably one of them that "pokes" a hole, especially if the intersection is non-axial.

If you wish, you can send me the zipped map+wad and I'll take a look at it. 
Textures Wanted 
hello i'm new here but i was wondering if there where some jungle, grass textures out there i could use or even maybe some prefabs jungle wice like say leafs and trees and such
if someone is wondering i'm trying to make a unusual quake dm map... as i always do ;) if you guys want to have a look at my previous maps go here http://www.geocities.com/elvstrom
hope someone can help me it's kinda hard to do stuff when your not sure what your doing ;) 
 
o.k i�ve learn somethings and i already make some mapping... but got a problem what is rvis??? how to use it? i put the light�s and all the stuff but dont know how to use this...

any help? 
Compile Programs 
id provided quake with three programs to compile maps to bsp:s with:

qbsp.exe - this makes the bsp
vis.exe - this makes the bsp faster to play by making it so that rooms not visible from the current room are not drawn. If map has leaks, vis aborts (sort of). If vis is not run, the map has really bad fps unless it's very small and simple.
light.exe - makes lightmaps for the map. If this is not run, the level is ugly fullbright.

rvis is another alternative for vis.exe. I think aguirre's utils have the actual filename as vis.exe. You just edit your editor's settings to use the aguirre's tools instead of the ones that came with the engine. You can read the readmes in the zip for how to use additional features.

Read the basic tutorials please. 
Thanks AguirRe... 
... my first Hull2 leak :) I'll check (and simplify) all contact with that floor brush before I send through a map + wad. 
Elvis 
You're probably out of luck on doing that style...the closest thing I can think of is take some textures from Vondur's Uzuldaroum http://wp.vondur.net/index.php?page_id=15

Quake isn't great at handling high-poly models without using a custom engine, and you would definitely need some custom code to get any sort of grass/leaf/tree models into the game in the first place. 
 
thks bambuz, then i just have to run rvis :) is not something i have to add to the map :) the other stuff i think i�m making better every day... just wait for my next speedmaps :) they are getting better everyday!

did sm109 = crap
sm110 = less crap
sm111 = almost crap but not crap :)= 
Triangles And Allocations 
All necessary files at:
http://skynet.campus.luth.se/~chosen/bam/spir/

The map is just a 12-sided spiral where the floor is split into triangles. Just 24 triangles per circle.
It's pretty big.

1) I find that qbsp (fail to remember if it's tree or tx) really fucks up my map, it makes all kinds of crazy excess amounts of triangles from flat four-sided polygons (the walls of the spiral). Too bad I don't have a shot here, but if you load that spi7.bsp in fitz and put r_showtris 1, you'll see what I mean.

2) vis doesn't block other parts of the spiral very well, although it's absolutely clear that they can't be visible from the current location. I've run fullvis but not -level 4. Vanilla id vis gives a playable map only at even smaller map sizes (spi7van.bsp).

3) if the map gets big, neither fuh or fitz will load it, they complain of some malloc overflow or something similar. I have to put about three quarters of the map inside a solid cube for it to load. The original map is very high but it should not have big continuous areas. It does have brushes spanning almost the whole height of the grid (the outer and innver walls of the spiral) but they should be broken by qbsp anyway.

What to the help? Sky textures? I tried that on the outer wall, but it didn't help, at least not noticeably. Upscaling textures?
This morning (haven't tried it yet) I came up with a way to reduce some brushes (floor can double as the below-roof if I make the brushes thicker), but the result should be identical after the qbsp phase.

Why does it crash?


- And sorry metl for not investigating that plat thing further, it was a speedmap that I then abandoned since it was getting so much out of hand in idea and style. I don't have internet on my own computer so handling files is always a little hassle. 
Theoretically 
if qbsp tried to make the minimum amount of triangles, every 12-sided "storey" would only have 24 floor tris, 24 roof tris, 24 outer wall tris and 24 inner wall tris, that is total of 96. 
Hm 
it seems it's treeqbsp and aguirre's vis uses testlevel 4 by default if i read the logs right. 
Bambuz 
It sounds like you have ye olde AllocBlock: full error in Fuh/Fitz. Take a look at my Q1 ToolTips for hints, engine section. Also, my engines can usually load such maps and they'll tell you how many lightmaps that are required.

And yes, my RVis defaults to level 4. Qbsp has nothing to do with vis levels. 
Bambuz, Some Ideas: 
I loaded your map into darkplaces, and looked around a bit with r_showtris 1.

1) Those aren't "excess" triangles. QBSP's subdivide size usually defaults to 256, and it appears to me that the massive surfaces of your structure were, for the most part, neatly subdivided into 256*256 blocks, each of which are further divided into two triangles for rendering. It just looks like the subdividing went crazy because your surfaces are so huge. You can change the subdivide size from qbsp's commandline, but I think if you set it really high, like 1024 or so, you'd get other errors besides the malloc/allocblock thing (maybe a subdivideface: didnt split the polygon?)

2) That's vis for you. sucks, doesn't it? You may be able to cut down on that very long visible distance if you put in some periodic retaining walls that radiate out from the center core of the spiral.

3) I ran into this with a similar map. My layman's guess is that some engines just hate large brushes, even if qbsp is supposed to subdivide them. Try breaking those brushes that are the size of the whole available grid into about 4 subsections and see what you get. 
Lightmaps 
Thanks for the help guys, I have a few more questions.

1) Lightmaps
Would it reduce them if I made more of the textures as sky? That isn't lightmapped, correct? I can also increase the tex scaling by 2 in both directions easily in the floor.

2) Triangelization or however it's written..
Well I'm still not at home and can't post shots, but it seems at times, a 4-sided polygon is taken from one corner and divided into twenty thin triangles or something.

3) How do I increase the subdivide size in qbsp? Didn't find any docs. Aguirre you could really compile even a short list of switches into the readmetree and readmetx files.
-subdivide 1024? 
More Sky 
and/or increased tex scale will help reducing lightmaps. As for subdivide size, you set it with the -subdivide x option, although I definitely do not recommend messing with it.

You can get a brief option list with any of my tools by just running it without any parameters, results end up in the console window and in the log file (if any). 
Thanks Aguirre And Guys! 
I increased the floor and roof tex scale to 4 in both directions and now it compiles and runs at full 77 fps in fuh (and 72 in fitz). I also removed some flat areas from the map and further reduced the brush count (151->102)...

Now this
http://skynet.campus.luth.se/~chosen/bam/spir/fitz0098.jpg
still happens, but what can you do... :/

Neatly subdivides into 256 blocks since I was using 256 grid. 8)
The new version is in the dir as zip http://skynet.campus.luth.se/~chosen/bam/spir/sispi7.zip 
After Briefly 
checking out the spi7 map, I'd suggest that you try to avoid sky brushes touching solids outside the map. Load up the map in my GLQuake, noclip outside and you'll see what I mean; huge textured faces covered in sky that probably generate a lot of lightmaps.

You should always avoid having visible faces outside a map, especially if they're big. 
Ok 
I wondered the same too... I only changed them to sky because the map didn't run, i might be able to avoid it now. 
Blitz 
actually i've found a palmtree prefab on fileplanet and the lefs of that palmtree i've tryed to use but when i use say 4 leafs qbsp gives many errors and i have no clue where to actually begin but the map still runs smooth no errors in fuhquake atleast looks nice to it's just that it takes much longer to compile than it's supposed to
heres the error i get so far the first one i understand but the second... well heh no idea
*** WARNING 12: New portal was clipped away in CutNodePortals_r near (-288 -678 347)

*** WARNING 08: Healing point (538 -950 250) off plane by -1.27
^ that one is driving me nuts

anyway it still would be nice with some leaf textures oh and i've actually tryed to use thouse uzul textures but on this map it dosen't fitt :/ 
Metlslime 
not fuhquake. i said worked in fitzquake. 
Third Take 
Now it works as intended originally.
http://skynet.campus.luth.se/~chosen/bam/spir/

No messing with sky brushes. Why are they treated differently by qbsp anyway? If a normal brush touches another outside the map, those faces are discarded by qbsp, but if a sky does that, they are not. Why? 
I Don't Know 
but sky brushes (or rather, leafs) are handled separately by the engine, e.g. for animation/skybox, lightmaps and rocket collision. I guess it would be more difficult for the engine to do this if qbsp didn't also handle and mark them differently.

Also, note that the default sky presentation in FitzQuake hides the outside sky leafs if not r_oldskyleaf is enabled. Having such leafs will increase engine lightmaps and prolong Light processing time if any ambient lights are used. 
Probably An Easy Solution 
I just set WC up for Quoth, made a test map.
when I tried to run it, things didn't go smoothly. Actually, things didn't go at all.
All the process window said was this:

** Executing...
** Command: Copy File
** Parameters: "C:\QUAKE\ID1\maps\smblood.map" "\smblood.map"

Does anybody know why? I don't. I'm probably just going to go to bed, because I'm too tired to try to figure this out right now.
Thanks. 
Drew 
That is quite possibly because you are using the map compilation front-end utility found in Worldcraft, which is known to be shit. Try using a *.BAT file. 
Nah 
"f9" can be bearable at least for speedmaps.
(aguirre's vis defaults to level 4 and the light works reasonably too on default settings) 
Uh Oh 
where did rorshach's textures go? Can anyone mirror or know the filenames at fileplanet?

The site at planetquake links to quakefiles.com which has a 404 error. 
First | Previous | Next | Last
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.