• Mapping Questions Megathread V7
    437 replies, posted
Im not trying to troll or something but... what's the problem ? whats wrong on that screenshot ?
I''m just showing what I'm trying to compile, it that would've been a problem.
Is anyone familiar with how Source calculates the fade distance for props? I'm curious what kind of overhead it adds. Is it just a straight distance calculation from player to the prop (which can get expensive pretty quickly) or is it using some kind of clipping plane? Is the calculation still done if the object is in an unrendered portion of the map? Also on a side note, it would be nice if hammer had an entity which you could link props to that could act as a singular reference for fading. For example, you could link all the props on a building to that entity and the fade calculation would only have to be one time for all the objects on the building. You'd just have to place the entity where you'd want the "origin" of all those props to be.
Great questions, I'm not sure how prop fade is handled "I think it calculates player distance", but I read on a tutorial that rendering a prop between solid and completely faded is slightly more costly to render. Simple Model Fade Optimization | Source Engine Tutorials
I tested a map where all props had a fade dist of 2,000-2,500. Got worse frames than I did with all props visible. Wasn't a thorough test by any means but these models weren't cheap either. I think models with proper LOD levels are better than fade distance.
I'm getting symptoms of a leak even though I don't seem to actually have a leak. https://files.facepunch.com/forum/upload/146362/66609f49-ddb8-45f2-91b2-10dc9a502d0b/20190505165443_1.jpg https://files.facepunch.com/forum/upload/146362/1d5430df-e18f-4af8-a5b3-84eff503b214/20190505165415_1.jpg The reason why I don't think the map has a leak is because I don't fall outside of the map like you normally would on a map that has a leak. Plus, Hammer didn't generate a pointfile for the map when it was compiled.
Are you running vvis on fast?
Yeah, I am. It hadn't done that before, though. Not that I plan on releasing a map that was compiled with vvis on fast, of course. I'm just worried that the same thing will happen with final compile settings because of some weird issue with the bsp.
I think the number of draw calls is probably more important than lods or the number of polygons. It's a pretty common misconception that poly count has a huge impact on frame rate. On modern hardware, polygons are actually one of the fastest things to render and are rarely the bottleneck of a scene. Draw calls and material complexity usually have the hardest hit on fps from what I understand. As far as I know, Source (or at least Gmod) doesn't have any proper form of instancing on identical props. Newer engines rely heavily on this process because it reduces the cost of rendering the same model over and over by a pretty significant amount. Instanced models only have to call the mesh data and the material a single time no matter how many times the model is used in the scene and then a list is fed in with the location data (position, rotation, scale, etc) of all the models. Essentially identical objects are rendered as a single group instead of being rendered one at a time. I'm not sure what else adds draw calls in Source because I haven't found a ton of information on how the engine handles rendering, but this lack of instancing means that rendering is very cpu intensive and there's a possible bottleneck in how fast the cpu can push data to the gpu. Even if you're using that same tree model 100 times in a scene, Source has to render each one individually. When I was making this post, I found out that apparently CS:GO has adopted a form of instancing called Static Prop Combine That wiki page also states that, "In Source, there is one draw call per model per material. By combining models sharing the same materials, less draw calls are performed, which greatly helps optimization. Valve has stated that Nuke runs 40% faster after they implemented static prop combine." With Gmod however, there's going to be some sweet spot where you can balance between the performance cost of fading a ton of objects in and out and the number of draw calls being performed, but I guess it'd be pretty difficult to determine since Source doesn't provide much debug information for rendering ingame. It's also hard to figure out without knowing how fading is done in the engine. I found this video a while back which gave an pretty in-depth explanation on how instancing works in modern engines for anyone interested: https://www.youtube.com/watch?v=oMIbV2rQO4k
Wouldn't this require changes to the rendering pipeline? I'm not a graphics programmer, but I know the scene is drawn back-to-front in Source and batching them up into a single draw call would mess with that order (probably?).
I don't believe so as it's just a more efficient method of packing information to be shipped to the gpu. I'd assume the gpu treats that information the same way it would if the models were separate or is aware of information sent this way and just has to unpack the data on arrival. From what I understand, the cpu has to process and send one draw call at a time before moving to the next one, so having things packed into larger chunks of data means dramatically less time spent preparing and pushing data across the bridge between both components. The gpu is insanely fast at processing this data, but the cpu just isn't able to supply the data fast enough, so larger packets are better. I don't think much changes on the rendering side because instancing is meant to address the bottleneck from the cpu's end when processing a lot of entities for a scene. Sorting could possibly be easier/faster if packets arrive presorted by the cpu, or if the gpu has to sort data again every time a new object arrives; however, I'd assume everything is calculated once the cpu confirms the gpu has all the data it needs and tells the gpu to draw the frame. I don't know a lot about how this process is handled though, so I'm sure I'm oversimplifying it. I guess you could compare it to putting a single box into 1000 semi-trucks and driving them in a line down a one lane road vs putting all 1000 boxes in one truck. It takes 1 day to send every truck and 30 seconds to unpack each box, so you're better off trying to put as much in each truck as you can to save on time and resources. This process is insanely slow if we're not even allowed to send the next truck until we confirm the previous one arrived at its destination intact.
Is there any simple ways of getting sort of hotkeys in hammer? Just looking for simple things such as rotating the selected brush/model by 90°/45° Other than making a macro to open the transform menu etc, I'm just looking for convenience
@Shrinker ?
It's best that you macro them. Mice with lots of programmable buttons are good for this like the G700s. I've got rotations in 90° and 15°, translations up or down by 8 and 32, the enter key, and delete key all programmed to mine. I can't work without it anymore.
How do I go about changing the zombie blood in Half-Life 2 to red blood instead of yellow? I've tried modifying the code in npc_zombie.cpp, but that didn't do it.
I have after a long time gotten a custom version of truenorth to compile but there are 2 problems I am having the first is there are these textures I have gotten off the internet and 1 texture I made that work and look fine but only if you look at them with a flashlight otherwise they are completely black, how do I fix that? https://files.facepunch.com/forum/upload/472853/81f919dc-83c9-436d-a4c3-c8fe6e4b3a79/facepunch6.PNG https://files.facepunch.com/forum/upload/472853/45490ebd-c813-4942-97d4-ddb3897a14a3/face punch 7.PNG 2nd problem is 2 spots where there is a block the top surface is just invisible? https://files.facepunch.com/forum/upload/472853/e90200dc-a4fa-4809-b7f0-06b93132ddad/facepunch8.PNG
one more problem, my map compiles fine like I said but now I try and add lights, light_spot and light and it will compile but everything that's missing when I press c is missing and the map is all dark why is this?
I never had a lot of questions, rather answers.
Sorry, you need to Log In to post a reply to this thread.