Sock: if you want to represent your mesh using the verticies and not planes in the map file, then a new format will be needed. I think this is what the others are getting at.

Kinn: Adding func_group support right now. 

Now that I think about it, three point plane definitions... are triangles. *facepalm*

So it could look just like the current map format, although the semantics would be completely different inside a "func_mesh" entity.
I.e. a compiler that was not aware of the special meaning of func_mesh would barf due to the wierd structure of the "brushes" contained within. 

It would just create planes and then recompute the vertices from those, with all the errors inherent in that process.

An aware compiler would just skip this computation and take the vertices from the plane points. 

Stage 1: Load all brushes into map, group them together and make them a special brush entity like for example "func_mesh"

So this still requires us to create a collection of tetrahedron brushes (or whatever) to represent this "mesh"?

I suppose this would work if all the unseen faces of the "mesh" brushes are flagged with a special texture that tells the compiler to discard them immediately. Then, the compiler will have a proper mesh of just the visible faces as a starting point, equivalent to as if it had just loaded in, say, an external .ase mesh. 

So it could look just like the current map format, although the semantics would be completely different inside a "func_mesh" entity.
I.e. a compiler that was not aware of the special meaning of func_mesh would barf due to the wierd structure of the "brushes" contained within.

Sounds perfect, all the brushes would be contained within the entity definition inside of the map file. So it can safely be ignored by editors/compilers that do not understand.

So this still requires us to create a collection of tetrahedron brushes (or whatever) to represent this "mesh"?

This is where a stage 0 would be needed. A compiler would have to triangulate all surfaces and then convert all marked surfaces into a tetrahedron mesh and save it as a map file. All of the back faces should be marked with something like terrainskip.

Another solution is to create the terrain from brushes and mark all non-visible sides with the terrainskip that the compiler can get rid of later.

The ultimate benefit of this system would be that the terrain brushes are treated like detail, they can be solid/clip and can cast / receive shadows. 

An example work flow:

* create terrain brushes (rough shapes)
* Group brushes into a func_mesh entity
* Use Trenchbroom to vertex edit the brushes
* Mark all backside surfaces with terrainskip
* Change spawnflags to suit application (solid/shadows)
* Pre-compile the brushes into a special mesh (faster)
* Or create mesh at compiler runtime (slower)

It would be good to have a pre-compile stage of the terrain brushes as this will speed up the final compile of a map.

Also could we have a compiler feature that has AI clipping? Brush surfaces that can be included in the later clip hulls but are invisible normally. 

Please let me think about how this would best be supported in TrenchBroom. Preferably, the method of creating a mesh would be compatible to creating Quake 3 meshes, because that would make it easier for me to add Quake 3 support. 

Surely the benefit of meshes is that you use a dedicated tool like Maya to model them (which is designed specifically for this kind of work), and don't have to worry about buggering about with tetrahedrons and manually flagging backfaces to be culled and whatnot? 

The process above is how I created my Q3 map Pyramid of the Magician and here is the source if you are curious to see what it looks like in an editor. (will probably need Radiant to look at it)

I think it would be easier for most people if the terrain mesh could be created from brushes and vertex edited into the shape they want. The real trick to this whole process is the compiler not the editor. 

more a response to sock than sleepwalkr 

Kinn

If the editor/compiler support for this is added, I think OBJ import will be absolutely essential to making it useful. 

Surely the benefit of meshes is that you use a dedicated tool like Maya to model them

The beauty of the Q3 ASE model format was it could be created from brushes or in a modelling package. Forcing the process to only work in a modelling package would shut out people who only have the editor.

Using the compiler to convert a mesh into a brush mesh (tetrahedrons) would bring all the terrains into a single pipeline. Plus the compiler could mark all back surfaces of the tetrahedron with a terrainskip. One other solution is the mesh is in a special external file (like ASE) which will require editor and compiler support.

The thing that is lacking from Q1 terrains is a detail flag, an optional clipping HULL and proper shadow support. 

If all the special compiler is doing is turning a mesh into a bunch of tetrahedrons anyway, then I'm not sure what real advantage you get from a special compiler.

Anyway, who here uses Unity? I'm wondering if there's any audience for this maya->quake unity project that i've made. 

of Unity, though I'm not currently working on anything with that engine.

The power of it is that it's free, if you include the logo at the start.

Have you tried throwing it at your phone or a browser yet? 

It's currently just some crap i bashed together as a script i can use via the unity editor.

So that others can use this, I think the best thing then would be for me to turn this into a standalone app that you can just run without needing to install Unity. I'll try to get on this asap.

Of course it's overkill doing something like this through Unity. I just did it like this for my own convenience at the time because it imports almost any mesh format already, already has an interface for me to input settings, options etc... 

I won't be able to use unity's mesh importers at run-time, and I ain't writing my own (I'm too busy right now). It'll have to stay as editor-only. I can make it a bit more user-friendly though.

The Unity editor is free to download and use though, so anyone can use it if they don't mind installing it. 

by the way, if anyone wants to have a gander at the .map of that terrain shizzle, to see what it looks like, here is that cavey test thing:

this one has all the brushes as worldspawn and doesn't seem to leak:

https://dl.dropbox.com/u/61424391/Quake%20Stuff/bdwtest07a.map

This is the same geometry, but the terrain is in a func_group for convenience. Leaks in txqbsp currently. (yes I am using -group).

https://dl.dropbox.com/u/61424391/Quake%20Stuff/bdwtest07.map 

When I wrote above I was thinking of just using the triangles of the mesh in the .map format, not having full tetrahedrons. Anyway, a few good ideas here. :) 

I was thinking about messing around in mapping for Quake. I last played around with it about 2002 or so and was discouraged by the engine limitations and the communities (then) general disdain for newer engines at the time and the maps that required them (I was using TxQuake I think but don't hold me to it, it was a GLQuake spin off) so I stopped trying as everything I was doing was going to kill the original engine in R-Speeds alone and so many comments here were purist in nature that I didn't consider it worthwhile to go on. I see now that that opinion has changed considerably so I'm willing to look into it again.

The problem that I am facing now is that I've forgotten pretty much everything regarding spawnflags, triggers and the like (I still have a what I consider to be a firm grasp on the basics of brush manipulation and r-speeds and all of that).

Is there a basic guide that is still out there that covers the basics? Consider me as a newbie that needs everything spelled out in excruciating detail.

I searched through this entire thread and what I am seeing is a lot of dead links (For example using "triggers" or "guide" as search terms).

Google isn't much help as just about everything seems to be sending me to USGS type sites regarding earthquakes.

I have already installed Hammer 3.3 and the Quake One configuration utility, have the wads and have refamiliarized myself with the software changes from 1.6 although I haven't as yet bothered with the more recent tyre-tools 0.5 as I'm not getting that far into it as of yet.

Any suggestions would be appreciated. 

Baker's quake adapter have a mini-guide? For WC you can also search the Forge tutorials which were beginner things on setting up stuff like doors, keys, counters and so on.

Might well be 404 though. I'll have a search once I get to a computer. 

I seem to remember WC 1.6a had some docs included inside for Quake. 

I didn't see a guide for Quake adapter that addressed the entities in detail but I will look again. It assumed a basic knowledge of flags IIRC. I used to have that written down or remembered but after over a decade I've forgotten much of that.

Quakeforge.net is pretty sparse and really seems to also assume a knowledge base that I currently don't have anymore.

I didn't think of WC1.6 but I suppose that I could install it and see what's there. I'm pretty sure that I have a copy buried somewhere. 

The PQ stuff is now gone, which was my first idea in this search for information. Many of the dead links went to things like Necros's guide which is what I probably was going to reference first anyway. 

that you need can be found in The Forge -
http://www.quakewiki.net/archives/worldcraft/index2.shtm

For Entities -

http://www.quakewiki.net/archives/worldcraft/entity/standard/standard.shtm

I'd say that's fairly comprehensive.

Also QuakeAdapter is good for getting you started, though I think at this point jumping into TrenchBroom is the best option (but I know you had trouble getting it to work). 

Yeah. I just came across that on my own after trying different quake and forge combinations in Google (and adding archives to the search). I'll use that and play around with it to try and re-familiarize myself with it.

I still expect to put up some dumb questions though. I'm "Special" like that sometimes. Thanks for the reply though.