Talk:Displacement: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
m (Reverted edits by DiscussionRepairBot (talk) to last revision by Equalizer5118)
Tag: Rollback
(automatically edit)
Tag: Blanking
Line 1: Line 1:
== Confused ==
Agg, I'm really confused. When I select two displacement surfaces and hit Sew, uh, they don't. I can't see what I'm doing wrong. Help please? --[[User:Solar|Solar]] 18:33, 16 Sep 2008 (PDT)
: Ah, never mind. I got stuff to work, just the rules of sewing are really, really finicky. --[[User:Solar|Solar]] 14:32, 17 Sep 2008 (PDT)


== Added from cache ==
Creating Holes in Displacements does not exist.
added it from Google cache, still needs pics. --[[user:mungo|mungo]]
== Bright seams ==
Is there anything that can be done about very slight, bright 'seams' which appear between sewn displacements when antialiasing is enabled? This is on an Nvidia GF6600 with the latest drivers - it's a bit distracting but disappears when antialiasing is switched off... --[[User:Cargo Cult|Cargo Cult]] 04:04, 26 Jul 2005 (PDT)
:No. It's AA artifacting, which is a card thing. --[[user:TomEdwards|TomEdwards]] 04:39, 26 Jul 2005 (PDT)
:: Nvidia, I curse thee!
:: Ahem. By the way, does anyone get the flashlight not working properly against horizontal, non-bumpmapped surfaces in DX9? I used to think it was my mapping at fault, but it works fine in DX8... --[[User:Cargo Cult|Cargo Cult]] 09:34, 26 Jul 2005 (PDT)
::The 6600 only does super-sample anti-aliasing (FSAA) in 8xQ mode. All the other modes are multi-sample "anti-aliasing" which only works on the edges of polygons, and doesn't work with pixel shaders.[[User:Zevensoft|Zevensoft]] 13:53, 26 Jul 2005 (PDT)
== Visibility ==
How does the engine determine whether a displacement is visible? Does it use the original brush, or does it create a convex hull surrounding the displacement, or does it use some other method?
:I'm leaning towards it using the original brush. There are some instances where if you create your displacement a certain way, and look at it at a certain angle, it will disappear - this is more noticeable in Hammer than in-game. --[[User:Daedalus|Daedalus]] 03:47, 8 Oct 2007 (PDT)
::To remedy this, you could make the original brush larger then use a larger size to sink down the whole displacement's face, then work from there—'''[[User:Ts2do|ts2do]]''' 07:31, 8 Oct 2007 (PDT)
:::Nope, it's based on the bounding box of the displacement, not the base brush. If you're viewing at an angle, the bounding box can be rather large, which may be misleading. --[[User:JeffLane|JeffLane]] 12:03, 8 Oct 2007 (PDT)
Is this bounding box axis-aligned, or aligned with the base face? If axis-aligned, it could result in some very nasty sized bounding boxes... [[User:Nhammen|Nhammen]] 22:09, 12 Oct 2007 (PDT)
== Displacement bug keeps happening ==
I have noticed in many games there are issues with displacements even in regular hl2 there was a command that fixed that problem before I can not recall that fixing command for displacements does any one know how? The problem is all physics entities and players fall through the displacements.
:I have the same problem! how do we fix it?! --[[User:Army dude|Army dude]] 09:53, 24 Jan 2009 (GMT)
::See [[Entities fall through displacements]]. If you really are still using HL2...please stop. :-P --[[user:TomEdwards|TomEdwards]] 18:32, 24 January 2009 (UTC)
:::thank you!--[[User:Army dude|Army dude]] 13:04, 24 Jan 2009 (GMT)
==brightness problem==
sometimes, the displacement gets super-light for no reason. like, at a specific point when I turn, it goes bright. like, if I look straight ahead, it's ok. look right, even by 0.000000000000001 degrees, and it isn't. and the same limits apply everywhere on the map.
can anyone help me with this? [[User:Kizzycocoa|Kizzycocoa]] 22:48, 27 June 2010 (UTC)
:You've applied a [[model]] material to it. Hammer is supposed to ignore them now so I'm not sure how you've ended up with one. --[[user:TomEdwards|TomEdwards]] 18:10, 28 June 2010 (UTC)
::I haven't. it's a grass texture. :S [[User:Kizzycocoa|Kizzycocoa]] 18:23, 28 June 2010 (UTC)
== Displacement Alpha Reversed in Hammer in October 2011 SDK Update ==
I noticed that the alpha is now reversed in Hammer for blend textures in regards to which texture shows. ANyone else seeing this? I saw another person post this in the forums... but someone else is claiming that it was always inconsistent between Hammer/game. Is this something that is a temporary bug?--[[User:Shawnolson|Shawnolson]] 08:15, 20 October 2011 (PDT)
:It looks like SDK updated again and already fixed this.--[[User:Shawnolson|Shawnolson]] 08:15, 20 October 2011 (PDT)
== Tutorial Request ==
I've been pulling my hair out for months now. I'm trying to incorporate antlion caves into my map, but I am boggled as to how Valve pulled it off *cough*Jeff Lane*cough*. I've been studying decompiled Ep2 maps and I'm in awe at how the tunnels were created. Curving, ascending, descending. I can create tunnels seamlessly, but it just doesn't seem practical to recreate the tunnels in Ep2 in Hammer without spending countless hours aligning vertices, edges, etc. Can anybody confirm if these were built inside Hammer, *cough*Jeff Lane*cough*or by some other custom tool? —[[User:Mattshu|Mattshu]] 20:56, 21 January 2012 (PST)
: I did not work on that particular section, but it was definitely created all in Hammer using displacements. It was done primarily using subdivision surfaces with all of the faces along the tunnels connected so there were no seams, then painted afterwards. Imagine creating a series of simple rooms and connected hallways with brushes, then selecting all of the connected interior faces, turning them into displacements, then subdividing them. It can be very CPU-intensive (read: time consuming) to subdivide that many faces. --[[User:JeffLane|JeffLane]] 13:34, 23 January 2012 (PST)
::With my luck, I'd have one single brush to ruin the entire subdivision, creating out-of-whack displacement surfaces. So, I guess it just takes a lot of time, motivation, and patience; three things I don't seem to have. Thanks for the response, it's nice to hear it directly from official mappers. —[[User:Mattshu|Mattshu]] 22:57, 23 January 2012 (PST)
== Maximum number of displacements? ==
This article states that there is a maximum number of 2032 power 3 displacements in a level. Why this limit, and what is the maximum number of power 2 or power 4 displacements? And how would these limits be counted when there is a mix of displacements with different powers? [[User:Greenhourglass|Greenhourglass]] ([[User talk:Greenhourglass|talk]]) 07:53, 1 June 2017 (UTC)
:I was just investigating this. I tried with power 4 displacements, and hammer didn't raise a problem until the compile was approximately 2244 displacements into the compile, where <code>MAX_MAP_DISPINFO</code> was reached. Looking in bspfile.h, this number is only 2048 though. I'm curious how whoever added that information figured that out. [[User:Pinsplash|Pinsplash]] ([[User talk:Pinsplash|talk]]) 23:54, 27 May 2018 (UTC)
== Bump/Normal Maps? ==
Maybe this is a dumb question, but for some reason i seem to remember somewhere some article saying normal mapping does not work on displacement surfaces. Am I making this up or is it just missing from this article? lol [[User:Greenhourglass|Greenhourglass]] ([[User talk:Greenhourglass|talk]])
Normal maps work on Displacement surfaces just like any other lightmappedgeneric surfaces &mdash;[[User:Stiffy360|Stiffy360]] 23:57, 3 August 2017 (PST)
== A strange edit ==
I thought this was a kind of weird edit: https://developer.valvesoftware.com/w/index.php?title=Displacement&type=revision&diff=238346&oldid=236880
I would consider the wording changes a little verbose on their own, but the "were" part confuses me especially, as almost every Source game and mod continues to use displacements as a primary mesh tool, especially for the ground or large natural objects. The edit summary about games from the past 10 years is false in regards to Valve's products, including Half-Life: Alyx. Can I get some clarification on the purpose of this edit? --[[User:Blixibon|Blixibon]] ([[User talk:Blixibon|talk]]) 08:07, 9 December 2020 (PST)
At the time of writing in 2005, BSP meshes were not used to build entire worlds. Only in the last 10 years in visual design has that become the norm. Up untill now displacement meshes 'would' of been used to build valleys, slopes, terrain etc, but the actual design element and data type of a drawn brush does need to be specified 15 years later. For example, every level in a game could be built out of these binary space meshes. Back then, it was for specific purposes, now Quake engines like Radiant and Source are able to be used to the full potential of a dedicated 3d software tool with regards to subdivision --[[User:HammerEditor|HammerEditor]] ([[User talk:HammerEditor|talk]]) 10:06, 10 December 2020 (PST)
:I'd like to point out that this article is on the Valve Developer Wiki, which specifically regards the Source engine, and as such it is definitely reasonable to describe displacements as they are used within the context of the Source engine, and Valve games specifically. Of course, displacement brushes are not limited to just terrain, so that could be clarified or expanded upon. Newer maps in [[Counter-Strike: Global Offensive]], for instance, heavily uses displacements for non-terrain purposes, including but not limited to hard surface walls and other structures. Still, since this article is specific to the Source engine, and not displacement surfaces in video game engines in general, this point should still be clarified. — [[User:Dr._Orange|<span style="color: #ffaa00">Dr. Orange</span>]] <sup>[[User_talk:Dr._Orange|talk]] · [[Special:Contributions/Dr._Orange|contributions]]</sup> 16:00, 12 December 2020 (PST)
In visual design, subdivison is the act of adding units of data between verts, for example, instead of having 1, 2, 3, 4, subdivision would equate to 1.1, 1.2, 1.3, 1.4, etc
The Source engine was the first open-source engine to feature subdivisional blocks after Quake's Radiant. We no longer in game desing full stop, as apposed to just Source, use subdivided geometry to create valleys, hills, slopes etc. These meshes are the foundation of level design, the meaning to amazing visuals and the origin of 3d real time scultiping. To say that 25 years after development in the binary space founding BIM module 4 (You probably need to google that), subdivisonal geometry is used for certain things is stupid. Absolutely stupid.
Please do some research and enlighten yourself to subsurface division as defined in the Blendr handbook, https://blendermarket.com/products/the-hard-surface-handbook-for-blender/docs
Also please do look at the world international visual design standard BIM, and their wording as to what subdivision brushes are used for in this catalog book, https://vercator.com/ultimate-guide-to-bim/
Finally to encompess my findings with your edits to this wiki's subdivision geometry type page, I would like to show you some modern day engines that not only use multi shaped polygonal meshes of subdivisional geometry (Known as planes, shapes, solids, brushes, theses are all the same thing with different termonology). See Unreal:
https://pinnguaq.com/learn/building-a-house-in-unreal-4/building-a-house-in-unreal-4-part-2 (Scroll down to the description that someone writes to explain these NON-differences)
https://en.wikipedia.org/wiki/Polygon_mesh (Unreal, Unity, Havok all render brushes as subdivisonal patches of world known as planes (we call them oldschool word brushes)
My game which I am making on Source is drawn nearly entierly out of displacements. It is nearly 2021, computers no longer have difficulty rendering smooth surfaces and lighting. 25 years we used displacement brushes (subdivided planes if you use auto cad or went to college) to create entire games. For example Skyrim is 11 years old and uses 100% subdivided geometry meshes. Simply watch a developer video in which they explain the terrain/ world generation.
Call of Duty black ops is over 10 years old, yet when I decompile the maps into autodesk meshes, there are power4 verts along every 16th spline, in Source this is power2 across 4 verts (a single spline).
We do NOT limit usage of subdivisonal model design in level design today. Meshes are no problem for computers as of about 17 years ago. CAD said in 2007 "Sub surface displaced geometry prudently shows us the future of [games visual desing] Page 18 and 19. https://www.cadmasters.com/pdf/civil3d2007largesubdivisions.pdf --[[User:HammerEditor|HammerEditor]] ([[User talk:HammerEditor|talk]]) 19:15, 12 December 2020 (PST)
:That's great and all, but the fact of the matter is that there are at least 200 professional and amateur Source projects out there, and maybe 10 of them use displacements or displacement-like meshes for most of their geometry. Many of the maps made for those games, including maps made in recent years, do still use displacements only when the art requires it. This is an objective fact. Ask any TF2, CSS, HL2, L4D, or Portal mapper. Non-Valve engines have zero bearing on this wiki. [[User:Loudslappingsounds|Loudslappingsounds]] ([[User talk:Loudslappingsounds|talk]]) 20:15, 12 December 2020 (PST)
Negative on that soldier - heaven forbid we regard ourselves as artists or game designers of any sort if we are going to pretend that we are entrapped to act as though it is 15 years in the past. Subdivisional geometry is not "non-valve engine" related. It is game design.
Please do try to argue your point rather than just saying 'no' to change, as that is known as a spectrum disorder. --[[User:HammerEditor|HammerEditor]] ([[User talk:HammerEditor|talk]]) 16:39, 13 December 2020 (PST)
:Sure guy, you're the second coming of Adam Foster, and starting by changing the word "are" to "were", you're gonna single-handedly convince every Source mapper they've been doing it wrong since, what? 2013? Hilarious. Valve would disagree, as even coop_autumn, which they released for csgo less than two weeks ago, uses almost 2000 brushes, and uses displacements exclusively for what really required it: terrain, a tunnel, and surfaces they wanted to alpha paint on. It's hardly worth taking the idea of using displacements 24/7 seriously in Source when the workflow is so much worse. Let me tell you the reasons for that I can think of ''off the top of my head'':
:*It's slower because you have to make a world brush anyway.
:*Sewing is finicky.
:*Displacements can't be used for entities. You still have to use regular brushes for brush entities.
:*Displacements are still slower to draw than brushes. A large scene using brushes where possible will run faster than one using displacements at every opportunity.
:*Displacements don't block visibility, so you have to place world brushes on the same plane or behind them anyway. They also don't seal the map, so that includes displacements you use for things like the ground.
:*Sometimes things just fall through displacements for no reason. Since Valve isn't fixing it it seems, all you can do is put a clip brush on the same plane as the displacement if you didn't already have a nodraw brush there. Good luck if that surface has any bumpiness to it when physics objects mere units thin are in play.
:*In some games light can bleed through displacements, and non-code solutions are "meh" at best.
:*LightmappedGeneric surfaces need to be artificially split up by VBSP to account for a limit of lightmap paging. Brushes can do this automatically, but displacements that are too big in one or more dimensions need this done manually, or have their lightmap scale increased.
:*Most versions of VBSP limit displacements at 2048, but brushes at 8192.
:And that's why nobody does it. Sure, some of those things you can just power through, and other things won't come into play when [[Media:2020-12-09.png|your geometrical complexity]] is hitting Half-Life levels tops, but for most of us, brushes are necessary. [[User:Loudslappingsounds|Loudslappingsounds]] ([[User talk:Loudslappingsounds|talk]]) 19:15, 13 December 2020 (PST)
I don't know who adam foster is, you have convinced yourself I am attempting to psychologically displace game developer's choices (get it?), and you linked to an image that I don't understand the context of. What does my [[Blood spray on weapons and hands|material proxy system]] have to do with subdivisional geometry? "split up by VBSP to account for a limit of lightmap paging" For any other noob out there that is drawing brushes at irregular sizes and then wonder why BSP can't assign a patch child to an uneven brush, draw the brush correctly and engage segmentation after squared 256 units in any 2 directions. ([https://irsa.ipac.caltech.edu/Missions/2MASS/docs/WAX/pWaxScanCov.html#scanBsp_s1 Duh]) --[[User:HammerEditor|HammerEditor]] ([[User talk:HammerEditor|talk]]) 16:41, 14 December 2020 (PST)
Oh, and a displacement brush is a brush, numbnuts
:Think my patience is at its limit. The backtracking, the playing coy, the back-backtracking, the unnecessary technical jargon (and obviously being proud of that thesaurus mastery), and the ignoring of almost everything I said, in that order, make me feel like you intend to troll, which is perhaps what you were [[User:Callum Sharp279|previously banned for]]. You aren't special for imposing a slower, less-stable workflow (in the context of Source) upon yourself. We absolutely do limit subdivision in this engine. The proof and reasons are plentiful.
:This wiki is essentially in anarchy. There is nobody to appeal to. This issue is now resolved, lest you wish to turn this into a revert war, which I don't recommend, given that you are currently 1 on 3. [[User:Loudslappingsounds|Loudslappingsounds]] ([[User talk:Loudslappingsounds|talk]]) 22:07, 14 December 2020 (PST)
I didn't know I had a valve developer wiki account. It's over half a DECADE old and I haven no idea why it has been banned. The contributions look legit, but anyway back to subdivisons.
We no longer use displacment brushes for valleys, mountains, terrain etc only. Verbose edit reversed.
:Seriously????? You made an alt over this? You've already died on this hill and now you have come back to life just to die on this hill again. [[User:DrMeepster|DrMeepster]] ([[User talk:DrMeepster|talk]]) 16:24, 17 December 2020 (PST)
== Triangular displacements ==
[[File:Triangluar displacement.png|thumb|384px]]
Putting this here until I can figure out how to insert it into the page.<br> It should be made very clear that this is a last-resort method; in many situations, it would be sufficient to just use one quad and jut out the extra corner by one unit (so that it isn't coplanar).<br/>— [[User:SirYodaJedi|SirYodaJedi]] ([[User_talk:SirYodaJedi|talk]]) 14:12, 7 August 2023 (PDT)

Revision as of 18:51, 17 June 2024

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Talk:Displacement&oldid=408357"