Reason being I want to build houses etc as ASE for Minas Tirith since I’ll need lots of rotated models, and we all know what fun brush-based models are when rotated in radiant 
Just interested if there’s a big speed hit (erm, ASE models may not be culled the same as brushes - dunno just hypothesising), or even a speed gain (cos ASE faces are non-solid and clip brushes will be simplified).
Performance for ASE’s can be measured in two ways, rendering performance and collision performance.
If the engine is rendering two exact same objects, one an ASE and another built with brushes, the two objects will have the exact same amount of polygons and both objects are compiled into the BSP. Both objects will have backface cull, and both will be affected by the vis/portals. So rendering performance is the same.
Collision performance is a different matter. While rendering objects occur in the GPU, collision is determined by the CPU. The more collison surfaces, the more work for your CPU. By default, all visible faces of brush based geometry are also calculated for collision. By default, ASE models are not (you can walk through a normal ASE model) so what we usually do is manually add clip brushes overlapping the ASE for collision. Typically, these clip brushes are simple, axial blocks - resulting in simple collision data. So if this is the method used, collision performance is better with ASE’s.
You can use the autoclip feature for ASE’s (spawnflags 2) where ‘magical’ clip brushes are automatically placed for every renderable surface of the model. This however can often be a larger performance hit, particularily with ASE’s with lots of non-axial surfaces. You can however set different parts of the model for collision or not since surfaceparm’s take precidence over the autoclip feature, thereby simplifying the collision data on small detailed parts of your model.
What you can also do is add ‘surfaceparm nonsolid’ to all your model’s drawing shaders and then create additional simplified colliding but non-drawing shader surfaces to simplify collision while keeping a tighter fit to the rotated models. Think of this as building your simplified clip brushes directly into the ASE’s instead of using brushes. This may be easier since you’re rotating your models.
good post obsidian, and well done ydnar for giving us those options 
Cheers, means ASE is the way to go \o/ (I love 'em, best feature ever. Well, vies with the new alphamod stuff for coolness, although the ASE is for me at least more of a practical thingy).
What you can also do is add ‘surfaceparm nonsolid’ to all your model’s drawing shaders and then create additional simplified colliding but non-drawing shader surfaces to simplify collision while keeping a tighter fit to the rotated models. Think of this as building your simplified clip brushes directly into the ASE’s instead of using brushes. This may be easier since you’re rotating your models.
Yeah I mentioned in my post I’d be using simplified clip brushes for the models - but if I recall misc_models are nonsolid by default? IE you need to set spawnflags for both lightmapping (which I’ll use) and collision (which I won’t). Hence, the nonsolid versions of the shaders shouldn’t be required I believe?
I second Ratty’s thanking of The Ydnar
Gerbil, does this mean I can make our trees for .ase`s?
Im still thinking of using radiant to start with, then learn to use milkshake if need be in the future... max is definitely out of my price bracket until Im earning.
Some clarification:
I never really said that ASE’s are any better than brushes, it all depends on the situation. I’m recommending ASE’s over brushes in your situation since you want to rotate them arbitrarily.
The point I was trying to get across was that simplifying collision data is much like simplifying your geometry with less tris for faster rendering performance. The less surfaces that need to be calculated, the faster the performance. The best situation is when there is no collision to be calculated (default models, brushes with nonsolid shaders). Next best is when you have simplified collision (manually clipped models and clipped brushes). Following that, brushes since they are relatively simple and axial. You shouldn’t ever have complex model geometry that is autoclipped since they are usually heavily faceted with all sorts of nonaxial faces resulting in complex collision calculations.
Note: don’t go crazy clipping your entire map or adding nonsolid to every shader now that I’ve said all this. Just simplify your clipping on really small surfaces like complex detailed brush/patches and on models.
@Go-Gerbil:
I think you misunderstood my quote…
Default models are indeed nonsolid. But since you’re rotating the models in arbitrary degrees, I thought it would be easier to bake your clip brushes directly into the ASE model, so that as you are rotating your models, the clip brushes are also rotated along with it. You do this by adding a simplified, invisible, solid clip surfaces around your actual visible geometry. Convert all your visible geometry into nonsolid surfaces. Then turn on autoclip so that the invisible clip surfaces are solid.
Note: I haven’t actually tested this technique to any great extent. It works for sure, but I’m not sure how well it compares directly with manual clipping. On the plus side, your clip brushes will fit closely to the arbitrarily rotated models (rotating your model by 33 degrees automatically rotates your clips 33 degrees as well). On the downside… well, it’s just not 100% tested but should work fine. 
@Go-Gerbil:
I think you misunderstood my quote…
Yeah I did indeed
Although I’m glad you clarified, because I’d tried to do something similar before and failed, and you’ve detailled how to do it.
I’m happy enough to build the clip brushes for things like buildings manually because they’ll more than likely just be boxes, and I can just drag the edges around close enough for my liking for that. Unless I get lazy, in which case I’ll explore your method
I would think autoclip is ‘dodgy’ as Ydnar says because it’s a hack. I don’t know exactly in which way it’s a hack, but I’d guess basically each ‘solid’ ASE face is turned into a mini-brush (presumably by creating a fourth vertex from the average of the 3 other vertices and extending a tiny bit in the opposite direction to the face normal - IIRC you can see this kinda thing if you decompile a map that used ASE misc_models). So more faces, potential inaccuracy (we’ve all have brushes create sparklies at some point that just shouldn’t be there).
So simplicity works both in this case for arbitrary rotation, and less clip brushes etc. Sounds like a good solution to me, so thanks
I mainly understood obsidians previous post, but can someone confirm that autoclip is the only way to have any solid surfaces baked into the ase model? although we then have the choice of turning some surfaces nonsolid through use of the models shaders.
also my question to Gerbil was about possibly combining the ase models with his idea of using et foliage to create low numbers of lod models… does anyone know if this is possible, or are we back to the clipping problems mentioned in Gerbils other thread?
I’m pretty sure you understood correctly what he’s saying. The ASE autoclip, when enabled, then goes down to the shader information to determine if parts of it should NOT be clipped (although I’d probably guess they still have brushes generated for them, just the faces aren’t used for collision).
You can’t use ASEs with et foliage, it only allows for MD3 use, and with ET foliage there’s no way I’m aware of making the models with automatic collision because it was never designed with that in use.
understood, so its back to designing models with enough detail to look interesting while not killing the fps, although Im still happy we can use .ase with baked in simple clip brushes.
May I ask a question? (not now…) thanks!
I have an ase model with this shader:
textures/crash/tunnel
{
q3map_lightmapsamplesize 64
q3map_lightmapaxis z
q3map_texturesize 512 512
q3map_tcGen ivector ( 512 0 0 ) ( 0 512 0 )
surfaceparm gravelsteps
surfaceparm playerclip
implicitMap -
{
map $lightmap
blendFunc GL_DST_COLOR GL_ZERO
tcGen lightmap
}
}
But it doesn’t show any signs of trying to stop me from walking through it…
Sorry for the rude invasion
to me your shader should be clipping, maybe its the spawnflags on the ase? see obsidians previous post for values to use.
Off the top of my head, I think for misc_models, spawnflag value of 2 is autoclipping, and 4 is lightmapping (and can be combined using spawnflag of 6).
If that’s wrong, it’ll only be I got lightmapping and autoclipping around the wrong way, so 1 test should be enough to work it out.
That’s correct,
spawnflag 2 == autoclipping
spawnflag 4 == forceMeta (lightmapping)
spawnflag 6 == autoclip + forceMeta.
That model does not clip because models without autoclipping are nonsolid despite what you add in the shader. Only after enabling autoclip will the shader’s surface properties be taken into account. Therefore, the need for my backward nonsolid/nondrawing clip method posted above.