Hi guys, as you may have noticed I have been doing alot of terrain experimenting. One thing I have found is that ase terrain models end up with approx the same tris as “thin mesh” brush terrain…ie; approx double the r_speeds measured in-game as “thick terrain”. This is partially obscured by the better tools in max to provide more optimized meshes. Ok, now to the request… the difference, as I understand it, between thin mesh and thick mesh terrain is the fact that the backsides of all of the brushes have a single normal, with “thick” mesh, as opposed to as many normals as the frontfaces have with thin mesh terrain. Now, I don’t pretend to know enough about this to say for sure, but could a spawnflag be added that could be applied to “TerrainModels” that would discard all backface coordinates and apply only one, to mimic the effect of “thick terrain”? Thanks for taking the time to read this, especially Ydnar, who has done more to extend the life of the q3 engine than anyone could possibly imagine a couple of years ago 
RC
ASE Terrain feature request?
Brush faces don’t affect r_speeds. The renderer does not draw brushes directly, it draws surfaces, which are created by Q3Map2 from brush faces, models and patches.
If you are compiling with the right settings in the BSP phase for ET (or ETUT):
-meta -mv 1024 -mi 6144 -v
Then your meshes will be as efficient as possible and there will be no functional difference in r_speeds between identical terrain created with brushes vs a model.
y
well, I think some of my confusion is clearing :)…The reason I started thinking about this was that my max model has approx 5k faces…but in-game max r_speeds were 10k. I was using the exact settings you recommended for the compile Ydnar, but found that if I used -notjunc i was able to significantly reduce r_speeds, in this case to a maximum of approx 6.6k with no effect on the look of the map. I am still plagued by black splotches in places, but have a couple more ideas for modifying my model that may help (I’m thinking the uvw mapping, in conjuction with optimizing the terrain, may be making the black mark problem worse)…
RC
my max model has approx 5k faces…but in-game max r_speeds were 10k
try compiling without -light and see again. probably cos each face has two passes; texture+lightmap
Torchy is correct.
MadJack is also correct. Using -notjunc can lead to problems like sparklies, seams, etc.
Have you tried adding q3map_lightmapSampleOffset N to the shader? Try values of 8-16 or so for N.
y
hmm, well, I guess I better explain my problem a little more…part of it is probably my own making, because my mesh is atypical…
As you can see, the mesh is using varying size polys to achieve a very low face count overall. It is the variable size of the polys that is cauing the tjunc fix to dramatically increase the number of faces drawn, afaik. I was going through the compiler log and discovered that I had a 50% increase in faces when using the tjunc fix. I was desparate for a solution, so I gave notjunc a try knowing full well that I could end up with sparklies…but I still have no sparklies whatsoever and the rspeeds are much better.
I have tried the various fixes for the black marks, such as q3map_lightmapsampleoffset in my shader with no success yet, but I have lots more work to do on the texturing and shading, so I’m not too worried about that.
Another question is would videocard type and drivers affect the visibility of sparklies? Because, as I said I have none now, but would others possibly see them with various drivers and video cards?
I must say, you guys continue to impress me with your knowledge and willingness to help others and I appreciate it greatly :). I will keep you posted with my results as I change the shader etc.
RC
Just wondering, since I’m working on something similar, but what switches would I use if I were mapping for Q3 and trying to optimize ASE terrain?
Seeing it from that angle, I’m extremely surprised to see you don’t have any sparklies but well… Good thing too I guess! 
lol
Ok, I must eat some words here. I just made a new mesh, based on the same heightmap, but a bit larger and the results are quite different. In this case there are only about 200 tris difference between the maps when using notjunc during compile. My earlier model apparently had a huge number of tjunctions, but this one, still made in max but this time a little differently in terms of the number of polys initially created and the amount of optimization used for the end product (more polys initially and more optimization later) must have far fewer. It still looks the same and I have yet to see a single sparkly on any version, with or without notjunc, so I guess its going ok
RC
Oh, btw, the black splotches are much reduced in this version, as well
Remove the ASE terrain and recompile with and without -notjunc. You’ll see the results are the same. Model surfaces do not affect nor are affected by the T-junction code.
Are you using hint/antiportal brushes to control visibility in the map?
y
Thanks for the advice Ydnar. I have now fully tested everything and realize I was wrong. I actually measured the doubled rspeeds, but there were too many variables involed to be able to say what caused it (I must have used 4 or 5 different builds of q3map2, not to mention changes in shaders and geometry added. Not large changes, but variables none the less).
I have not yet added any vis blocking to the map (this one is 8192x4096 in size). By manually tweaking the “optimized” max mesh, I have been able to drop to a max r_speed of 4200, looking diagonally across the map from the farthest corners (the mesh is just under 3000 faces). R_speed test was done with cg_drawhands 0 and cg_draw2d 0. Vis blocking will help, but the map is largely open and I knew I would have to make an efficient mesh to keep performance high. I will use hints and antiportals, probably in a sliced pie shape around the 3 distinct moutains…some areas will be improved, I’m sure, but by how much I have no idea. I’m just saving the computer power for the super dp2 alphamod volume stuff
RC