editing levels directly in polygons (not polyhedrons)

[DeathRock]

Is it possible to create a level, operating with BSP faces, but not any brushes?
What tools are required?
May it be better than just using flat bezier patches + invisible solid brushes in any radiant-like editor?

I'm just asking this because i'm afraid on many unnecessary or non-optimal face splitting that sometimes occurs (and it's hard to avoid it) in maps built with brushes
And i remember that in end form a BSP level consists of polygons (brush faces) that are rendered and they are stored independently from other stuff like collision map, visdata, etc., so why we can't work with them for the better r_speeds

[obsidian]

As long as you caulk properly, you shouldn't end up with anything visually different than if you had used polygons. Q3Map2 calculates spaces based on convex brushes so you can't rely on just polygon faces.

[DeathRock]

yes, it is visually the same, but... sometimes we need to choose between extra drawing faces (q3map2 doesn't merge any faces) or intersecting brushes (but with no intersecting faces, of course)
as i know, all 2 choices leads to no good

of course, we can build more complicated brushes that do not intersect and do not have more faces than needed, but in some situations it's really brain kicking

if it is not easy to understand, i can make some example pictures

[obsidian]

If you are trying to do something specifically, then post up an image of what you are trying to do and maybe we can figure it out.

Brushes and patches are good for most things and if you can't do it with those, then you can always import models.

[Silicone_Milk]

Another thing to keep in mind is that, unless you're running a computer from 1999, a few extra drawn faces doesn't matter.

Maps have been being built for Quake 3 with brushes for over a decade now.

The compiler has been improved by an incredible amount since it's first iteration released to the public.

[DeathRock]

Models is a good thing
and i know, it's even possible to make models from map brushes - compile them to bsp, then decompile to ase
but it's a sequence of too many dumb operations, maybe i just need to know a simple and noob friendly model editing program

[^misantropia^]

(q3map2 doesn't merge any faces)

If by face you mean brush side then I think it does, actually.

[monaster]

maybe i just need to know a simple and noob friendly model editing program

Like MilkShape 3D?

[obsidian]

Well, if you find building things in Radiant to be difficult, moving to a modeling program isn't going to be any easier.

[DeathRock]

(q3map2 doesn't merge any faces)

If by face you mean brush side then I think it does, actually.

really? what version? what command line?
i always saw all splits where they were in map when toggle r_showtris in quake 3

Well, if you find building things in Radiant to be difficult, moving to a modeling program isn't going to be any easier.

build is easy, but it's sometimes not easy to optimize stuff (merge all similar complanar brushsides in the way that produces minimum number of triangles after compile)

[Kaz]

My intuition tells me that there is a valid reason for the splitting up of coplanar faces (aside from the compiler not being able to make "human judgments"), and that the most "optimal"-looking configuration might not account for all the things the engine needs to do with the geometry. Of course, I could be completely wrong.

[Silicone_Milk]

Did some quick tests and co-planar faces are not merged together by the compiler.

Not sure why this is. Might have something to do with mapping textures?

[^misantropia^]

Yeah. I think it only works when the brush sides can share the texture and UV coordinates (and perhaps not even then, in all cases. Not sure how smart the algorithm is). It's the MetaTriangles and MetaSurfaces bit you see in the q3map2 log.

[DeathRock]

Yes, i see it in the log, but it does nothing in any case i tried. If somebody knows, please show an example map & compiler version & command line, where q3map2 DOES merge some brushsides (with exactly the same textures&texcoords, of course)

[DeathRock]

My intuition tells me that there is a valid reason for the splitting up of coplanar faces (aside from the compiler not being able to make "human judgments"), and that the most "optimal"-looking configuration might not account for all the things the engine needs to do with the geometry. Of course, I could be completely wrong.

sorry, i don't understand you

[Silicone_Milk]

Yeah. I think it only works when the brush sides can share the texture and UV coordinates (and perhaps not even then, in all cases. Not sure how smart the algorithm is). It's the MetaTriangles and MetaSurfaces bit you see in the q3map2 log.

Looks like I have another thing to add to my to-do list on q3map3

[jal_]

Yes, i see it in the log, but it does nothing in any case i tried. If somebody knows, please show an example map & compiler version & command line, where q3map2 DOES merge some brushsides (with exactly the same textures&texcoords, of course)

bsp -meta

It does when they are coplanar, have the same texture and texture coordinates are continous, lightmap fits all together in a lightmap texture and does't fall inside a blocksize split. It's nothing I would try to control, tho, too many factors out of our hands.

Using bigger _blocksize might help, but won't if you are scaling the lightmap anyway.

This is an example of a place where q3map2 has clearly merged them (It is a wsw map which has bigger lightmap textures and still this is a spectacular case. Don't expect it to be the norm):

[lvlshot]http://www.foopics.com/showfull/545d568fa37049808dff1ce041700784[/lvlshot]

[Lunaran]

q3map2 isn't as good about lightmapping big mesh faces either.



I wanted to model and uv a whole map in Maya and that tanked the idea pretty early.

(unless there's a fix for this I never found ...)

[obsidian]

Is there caulk behind the .ase? I'm assuming you properly caulked behind the brush version since you're usually suitably smart with mapping. It looks like an issue with Q3Map2 not being able to properly determine the edges of the lightmap, so some caulk solids might help.

Give q3map_nonPlanar a try, it should help with merging non-planar triangles so that lightmaps can be properly cast on them. q3map_lightmapMergable might be able to force the lightmap onto a single page, though the down side is with large surfaces it may end up being too large of a surface to fit on Q3's limited 128x128 lightmap pages. In such cases, your lightmap may end up being really low resolution. You can compensate with q3map_lightmapSize and -export for larger external lightmap dimensions.