HI Guys,

I had decided to take another crack at mapping, which is always fun. And I grabbed a version netradiant and found myself not wanting to throw my computer into the bathtub quite so much. Unfortunately, what has happened now is that when I build my map into a bsp, attemption to "map zazu" in console crashes nexuiz....

Also, along the way I encountered some building errors so I raised

#define MAX_POINTS_ON_WINDING (polylib.h)
from 64 --> 256

and also,

#define MAX_TW_VERTS (light_trace.c)
from 12 --> 256

and recompiles q3map2...

could this be causing the problems, or have I unknowingly created the first nexuiz virus?!
hopefully not.

also, here is a copy of the map to look at if you are interested... thanks again if you are able to help, if not, the computer will be going to the bottom of the river...

INDEFINITELY!

http://stashbox.org/353122/zazu.map

Well, maybe darkplaces has a similar limit. Simply don't use brushes with so many faces that you need this limit extended. Split these high-vertexcount brushes up into many.

Other than that, what is the crash message? Can you catch it in gdb?

i think i know what is causing the problem.

I subtracted a circle from another section resulting in many little angular pieces making up the circular cutout. I read somewhere about trying to use the CSG merge tool to reduce the number of vertices. However, merging causes a "would not be convex" error. Also, the method of making the cylinder was Prism-->100 arbitrary sides. I don't know if this could cause problems...

I will try it in gdb tomorrow.

Because you can only merge if resulting structure would be convex.

If your trying to make a circular cutout its probably easier to use an inverted mesh cylinder and build a patch ontop of either side. I'm not sure specifically what your trying to do, but that would probably work to fix the issue rather than using the csg subtract to make a hole in a brush.

Using CSG Subtract on a cylinder is probably the messiest, worst way of doing a making a circle in something. A better way, is to make a square, place a cylinder in the middle, and hit Invert so that the faces are on the inside.. Then select patch cap or whatever it is, and do cylinder outside.

I probably said some stuff differently then what its really called but im pretty sure you can figure it out..

thanks for the help revenant. i follow you upto the the last step...

patch cap or whatever it is, and do cylinder outside.

i can't find that. could you elaborate? please and thankyou.

zazu

Its called Cap Selection, shortcut is Shift+C

EDIT: I mislead you slightly.. You cant cap a cylinder the way you need to, so what you need to is either use 2 endcaps and cap them using inverted endcap, or use 4 bevels, and cap them using inverted bevel. You can even delete the bevels/endcaps once they have been capped, and replace them with a cylinder if you want.

thanx for the tip REV . this is so helpful

hey guys, thanks for all the help, however, i think i will put this in the "too hard basket".

unfortunately, mapping does not seem to be my thing, and to do the required changes would be tedious and almost require recreating the entire map

sorry if i wasted your time...

... however, hopefully my question and your answers might help someone else who is having a similar problem later.

Hell no!

This is not the attitude you need! Bad zazu, baaad baaad zazu!
I've checked your map in the editor, and I've found the concept very nice.
BUT!

The map is very poorly edited, but since you're a beginner, it's not faulty. You're just doing things wrong

1st: the bridge is ok, but for arched parts, one should use the so called "end caps" (it's under the curve menu option. To see how they work, simply open maps from Nexuiz, that use arches (farewell, final rage, stormkeep comes to my mind).

2.: First, I've only looked at the 3d window, and by selecting brushes, I've seen you've used the CSG subtrakt tool a lot. That is a neat tool, but only works well for simple geometry (that has either 90 degrees angles or 45, and snapped to grid). When I'e looked at the center tube, I've said "omfg" IRL too That tube could be easily done with cilinders, with modified matrixes (matrix is the thing that tells what's the inside or the outside of the patch mesh).

I'll have a hard exam tomorrow, but I'll correct your map after that at some parts, so you'll see what you should do differently, and learn from it.

3.: Also, the lack of "detail brushes" and "caulk texture" is disturbing (google for the stuffs)

thanks for being "brutailly" honest (hehe, i crack myself up! )

I will have another look at this in the morning tomorrow. i will investigate end caps as you said detail brushes and caulk textures... hopefully the map will look better and not crash nexuiz next time

Good luck with your exam btw.

This is what you should tell yourself, this way you won't be a failure ^_^
"I haven't failed! I just found out 10,000 ways that didn't work." - Thomas Edison

Detail brushes and caulk is for cleaner editing and better performance ingame, not for eye candy

From q3radiant manual:

Caulking

It is possible to even further reduce the number of brush faces being calculated by applying a special non-drawing, but “solid” texture called “caulk” (common/caulk) to surfaces that cannot be seen in the game. When seen in the editor, this texture is a bright garish pink. In the game, it does not draw at all. Apply caulk to any brush face that either doesn’t form the “shell” of the world or can’t be seen by a player during play. Doing this may not improve your map’s frame rate, but since your are telling the compiler that as many as five of the six faces on a square brush don’t have to be calculated, it should have some significant effects on compile times. As long as you do not have any brushes that “share” the same space, caulking brushes should help reduce compile times. However, if you use caulk on a brush that “shares” the space of another, your compile time and all file sizes will actually increase.

A good example: basically, you have the sky "box" around your map. Texture all the faces with caulk you don't see, so they won't be rendered ingame.

Detail brushes: I can't find a better explantaion, but detail brushes are what the name stands for: detail brushes don't block visibility, so it can save you compile time in the vis stage. BUT be careful: once a brush is detailed, it won't block visibility - everything that's behind it, get rendered by the engine, even tough if you can't see it Eg: make two rooms, and than detail the wall that divides the two rooms detail. Ingame normally you can't see what's in the other room, but if you add the command: r_showtris1 in the console, soon you'll see everything that's in the other room drawn in wireframes - the engine sees it, and draws it, loosing a lot FPS. So detailing a room's wall is not a good idea
Basically, everything, that hides something is structural brush. Every other, that's only for eye candy, is detail. Again, to get a better understanding: load up runningman, and hit ctrl+d (hide detail brushes). You'll see that almost half of the map will disappear, and only the caulk hull (that still blocks vis) will remain!

Hope this helps

q3map2 should auto caulk brushes you can't see.

It does, if it's absolutely guaranteed you can see it from nowhere. Caulk is for brushes you theoretically COULD see, but never WILL.

That's a nice feature of Q3Map2 but ever since div told me this was the case, I have not stopped caulking everything out of sight. Simply because it helps me hold a better picture in my head of where the map is going. Also, in Radiant you can press Alt-6 and the caulk will not be drawn, so you only see what will be drawn, which can be quite handy sometimes.

Yeah, but it's not necessary to caulk the face of cuboid if that face is hidden by other solid object next to cuboid.

Neither is it necessary if the face faces the void outside (like, the back sides of the skybox).

caulk is almost never needed. It however MUST be used well on brush models like func_train, func_rotating, but ALSO func_wall, as on these, q3map2 does not remove unseen faces, as it can't know where the entity might be put by the game code.

Note also: caulking the unseen faces of detail brushes (that lie inside another brush or touch it) is SAID to help, but q3map2 notices that they touch another face and removes them anyway.

Mappers often are guilty of overcaulking - of caulking faces of which THEY think they can never be seen, but they can. You find these caulk mistakes even in Nexuiz maps.

Evilspace for example is overcaulked - you can see caulk when you're falling down and looking up.

But the best example of an overcaulked map is kaznexctf2.

Caulk should NEVER be put on faces that the player can possibly reach. However, what one can or can not reach is often not known by the mapper. E.g. with hook you can reach many more places than without, and often you can get to see caulk by clever laser jumping.

But don't forget the second use of caulk: behind patches. As patches don't affect vis, you have to put extra caulk brushes behind patches.

To summarize:

Important uses of caulk are:

• Faces of entity brushes (like func_*, except for func_group which is not a real entity but gets collapsed into worldspawn when compiling the map) that cannot be seen because they are obscured by other brushes.
• Whole caulk brushes put behind patches. Do not put "real" surfaces behind patches but only caulk, as the engine would actually draw them and waste time!

Also valid, but mostly useless:

• Faces of brushes that SURE cannot be seen because they face outwards to the void or are obscured by another brush: q3map2 removes them anyway. Don't need to caulk them.

Good and gains some FPS, but very hard to do:

• Faces of brushes that SURE cannot be seen by players but that are not obscured by another brush (so they're rather unseen because a player can simply never get near them). Often, this is misjudged and leads to overcaulking. If not sure about these, DO NOT CAULK THEM.

divVerent wrote:
But don't forget the second use of caulk: behind patches. As patches don't affect vis, you have to put extra caulk brushes behind patches.

This was something I forgot to do on Effluent. Luckily forgetting it didnt really make much difference on the map's framerate. *wipes sweat off brow*

zazu: sorry for the late reply and the delay,but unfortunately I've failed my exam,so I have to retake it,so I have little or on time at all to map
Anyway,I've corrected some errors,but I'm not finished with it yet - I'll post the corrected map either today or tomorrow. Generally,it's still a big mass,so I have to suggest you to look at my corrections,and start over the map - I'll tell you more next time what else is bad.

EDIT:
Ok, let's see:

http://akion.planetnexuiz.de/nexuiz_maps/zazu.map

First off, notice the file size
I won't go now into detailed explanations, but I've corrected some parts of your map. It's really far from perfect (wo. redoing from scratch it never will be), but you'll get the basic idea.
Another problem: look carefully for the centers of the entities: they can be seen as little axes inside the entity model. Those can't be inside a brush, either your map will "leak", and you won't be able to compile it. I've moved all the entites a bit, probably broking the jumppads with it, but at least the map compiles.
What I'd tell "too difficult" to do in radiant are those glass bubles. They'd be better as models, made in a modeller app.

thanks for the help everyone. much appreciated.

hopefully i will get a chance to remake this map next time holidays come around!