Appropriate uses for displacements?

[Urser]

This has been something bugging me for a while. I've heard that displacements are cheaper to render than normal brushes, yet they do not seal the map. So what's wrong with simply turning everything that isn't used to seal the map into a displacement? I know there must be something wrong with it, but I'm not sure what it is from a performance perspective.

Also, what do you guys consider appropriate times to use displacement brushes? Things like cliffs and terrain are obvious answers, but from what I've seen in some .vmf files, they're also used for tunnels and worn-out roofs. So does this mean displacements should be used wherever there is some geometric imperfection?

 

[tarmo-]

:O
basically you want to turn whole map in to one big box and source engine isn't fan of big open areas... it would render whole map at the same time.. it wouldn't work

 

[Randdalf]

Displacements can't be tied to entities, and they don't block visibility, so doing such a thing will only make your map perform worse.

 

[Urser]

Oh well, I didn't mean it like that. Obviously things that are used to separate the map into visleafs would also remain world brushes, but let's say I have a brush-based hand rail that would normally be a func_detail. What's the problem with turning it into a displacement? Not only would it be better for map performance, I could also displace some parts to give it a "rickety", broken appearance.

But I just feel that there's some unwritten holy book of mapping that would condemn you for displacing anything that isn't part of the terrain.

EDIT: Or am I just uninformed? Are displacements harder to render?

 

[Dr. Spud]

I think what Urser is getting at is along the lines of: what if you turned every func_detail into displacement.

 

[Urser]

Basically.

Also, could anyone enlighten me on how lighting is different between normal brushes and displacements? I heard that changing the lightmap of a displacement is not recommended, as they handle lighting differently, but how so?

 

[Rexy]

I don't know, the mapping gurus will have to answer you on that, but I think turning func_details into displacements isn't a good idea, because you'll end up with a great number of triangles, which is more for the engine to render.

 

[Freyja]

Yes, thats right.

Brushes are lightmapped, while displacements are vertex lit, like models.

Rexy's right about the triangle thing. it would also be a pain to mess around with, imo.

 

[Urser]

Okay, so after doing some research on vertex lighting and lightmaps, I think I have a much better understanding of how they work, and how they determine the lighting of an object.

Let's say you have a brush cube with a light in front of it. The front face is entirely lit. The smart thing to do would be to tie the cube to a func_detail and give that face the highest lightmap value you can. If you were to make it a displacement (and therefore use vertex lighting), then the cube's face would be divided into more polygons (dependent on the power you give it) and therefore have more vertices, thus making the lighting unnecessarily complicated for such a simply-lit face. Right?

Also, after looking at the Valve developer wiki, I noticed that displacements are cheap because they're rendered in batches. What does this mean exactly?

 

[FaTony]

Well it's about graphics programming.

 

[Psy]

Brushes are lightmapped, while displacements are vertex lit, like models.

Wrong. :facepalm: Displacements are lightmapped as well.

 

[grazr]

Ultimately, If you're going to attempt to increase performance by turning your geometry into displacements you might as well turn them into models. func_detail's are used to increase vvis performance by reducing visleaf counts similar to how mappers used to utilise func_brush and func_wall pre-source. It's not necasserily a way of improving how an object is rendered, where as models do come with a rendering performance benefit in addition to not effecting vvis. I can't say much for displacement rendering, i could only hazard a guess as to the context of "batch rendering", that it is rendered in groups somehow (although again, how this actually improves rendering performance is lost on me). Whilst i can say that models are more efficient in terms of how the game pulls them from the cached memory for rendering, as the wireframe mesh is only stored once, even if the model is used 1-100 times. Lowering visleafs increases map performance slightly ingame, but also reduces over all file size.

Vertex lighting is supposedly more efficient than lightmapping. I suppose it's a matter of applying tone per polygon rather than lightmap. Essentially shadows are another layer applied to a texture for rendering so you can see how this would effect performance positively for models in comparison to lightmaps (depending on polygon count of course), in fact shadows are usually the number 1 source of system demands in most 21st century games, especially dynamic ones (which the source engine kinda fails horribly with as they don't blend with lightmaps and they also overlap causing a shadow stacking effect).

 

[Freyja]

Yes, your right about the cube.

Also, nodraw doesnt work on displacements

 

[Icarus]

Displacements also take up more filesize and take longer to compile

But you aren't restricted to using displacements for terrain. Take a look at Hydro. They use displacements for rounded structures, floors, and walls.