Posts by Klems

Quote from laminutederire

That's what I was hoping to do, behind the curtains, working on the base of engines, in order to optimize them the most. Am I wrong to think that it could be kinda like the project I worked on this year, in which I tried to optimize an algorithm, which built bus lines based on statistics?

I think what he meant is that, regarding the code structure, simulation are very close to games. If you made simulations it shouldn't feel too different. I tend to agree.

Quote from laminutederire

you are saying that on the game developing part, there is not much to do, but in the development of engines game developers use there are some opportunities ?

With just your degree this is unlikely. You should know how to write good code first and foremost. If you know how to code, you can do anything. If you have a scientific background it shouldn't be too hard to code cool stuff (AI, advanced rendering, physics, etc), as you will have the tools required to do such things. Most coder struggle with simple maths, but you won't, and that's a huge plus.

Unless you're planning to be a somewhat specialized engine coder or consultant in some big company (or if you're working on the next Kerbal Space Program), I don't really see how a scientist/engineer background would really help. I mean sure, science is always useful, but that's true regardless of what you're working on.

Simple trigonometry and geometry will always help any kind of 3D artist, but you don't really need a math degree to do those. Having a physic degree would probably help a sound designer, but the most important part is actually being able to design sounds, not solving equations about sounds.

Unless you were to code your own engine... Even then, depending on your engine, there are several free and efficient physics engines available. Most graphics features of modern game engines are well documented. A math/physic level of bac+1 (first year uni) would probably be sufficient (as long as you know how to code of course).

Quote from laminutederire

Because curves sometimes cannot be either func_detail or models because you'd want them to seal the map, but your method allow that, so thanks!

So far I tried to place hints to fit curves, sometimes it has the effects that it does not create any unwanted visleaves, thus simplifying a lot visibility calculation, but it does not work every time. If I learn the logic I'll share because it could be pretty useful

It's important to keep in mind which curves and part of the map are supposed to block visibility. This is on radiant, pink is the equivalent of nodraw for the Quake 3 engine.

[Blocked Image: http://image.noelshack.com/fichiers/2015/25/1434432443-visibility.jpg]

Without the brush highlighted in blue, the room a might be rendered from the room b, and vice-versa. Adding other brushes to fit the curve more closely is completely pointless in this case, only 1 brush is really needed. It's easier to think about sightlines, which part of the map can you see from somewhere, etc.

Almost all of your map should be either func_detail or nodraw/sky brushes. Textured brushes are for big/cube-shaped/straight buildings only.

Rather than using a direct path to a sound you need to use a "game sound", which are handled via script files. The point of using a script file is so you can specify a random pitch range, several differents sounds to be used randomly, and also the volume and power (in decibel) of the sound. Volume and power isn't exactly the same thing, volume is how loud it is, power is how far you can hear it.

There are already a few you can use, when you search for a sound look around and you'll see "game sounds", check that and filter with "door" or whatever. They should use . rather than / for the path, look for that and it will be fine.

Otherwise you can look up inside the game files, these files are named "game_sounds_xxx.txt" inside the scripts folder.

Looking up on google has never harmed anyone by the way.

This map still has some problems:

The model distance fade here is very apparent http://image.noelshack.com/fichiers/2015/…06-04-00001.jpg This isn't the only case, it's very visible in the whole map (especially on trees).

The door prop become slightly translucent from here, could give an unfair advantage to CT http://image.noelshack.com/fichiers/2015/…06-04-00003.jpg

Occluders are vastly misused here http://image.noelshack.com/fichiers/2015/…06-04-00005.jpg Faces textured with occluder will occlude, faces textured with nodraw won't. There is no point into using these faces, they're too small to be really useful, players can't see them and there is additional CPU cost with each occluding faces you add. In this particular occluder, because players can't see these faces it probably doesn't matter, but this isn't the case everywhere. Faces that are directly above or below shouldn't be textured with occluder either, unless you can of course go above/below.

Same here http://image.noelshack.com/fichiers/2015/…06-04-00006.jpg you could extend your occluder far below the ground and put it closer to the wall, for the same cost while more models would be occluded. Remember occluders add additional cost PER FACES only, and are more efficient when they occludes many models, so try to make the most of it. In general, try to make the biggest occluder you can, the closest possible to the wall.

http://image.noelshack.com/fichiers/2015/…06-04-00007.jpg You made a pretty skybox but it's basically completely hidden from inside the map. There isn't much point into making these walls, you could remove the wooden plywood and show the skybox behind it, it would be prettier, less costly, more atmospheric, etc etc.

There isn't any areaportal usage in your map, and I suspect you don't really use hints either. There is still more work to do on optimization. I know this can be a nightmare to optimize such an open map. Don't rely on occluders to optimize your map, they should be avoided as much as possible.

Man you need to tweak your fog, it's so fucking ugly. You can have "early morning" without having to set your fog to some kind of weird fluorescent purple. As a general rule it's best if you keep your fog color similar to your sky color, otherwise you'll get strange stuff in your background such as this one https://migrationtest.mapcore.org/uploads/monthl…f302d42fafd.jpg.

On top of that your sun pitch isn't steep enough, it looks like late morning, at best. You can calculate the ideal pitch here http://www.esrl.noaa.gov/gmd/grad/solcalc/azel.html. The pitch is the "solar elevation" value (+- 90°).

Also don't forget you can use color correction.

Well, light is a complicated thing, you know CS:GO vrad is only an approximation.

Light_env has only 2 light configurations, the sun and the ambient. It doesn't take the varying brightness of the sky into account. You can tweak the SunSpreadAngle value, but if you want a realistic simulation you need to set it to the angular diameter of the sun (which is around 0.5°).

One thing you can try is to use several light_directional on top of your ambient light. The best would be to add a bunch of them and copy their orientation/color/brightness from pixels on the 2D skybox (that would look so good on a sunset skybox), but doing it by hand is probably good enough. More recent Quake 3 skies are handled like this.

For a start I would just copy the sun configuration into 3 or 4 light_directional, desaturate their color slightly, make it a tenth of the original brightness and randomize the orientation by a few degrees. See where it goes.

EDIT: also, if your reflected light isn't bright enough, you can manually tweak reflection values inside the VTF (not the VMT). This is used for radiosity, not cubemap/phong.

Quote from Puddy

I think an interesting approach would be to make an inverse hostage map where CT's spawn with the hostage and have to move him to safety. In fact, I know someone already did this but I've actually never tried it. This would give a map roughly the same flavour as as_ but remove some of it's volatility.

I think it would make it too similar to the bomb/defuse mode, except there's no bomb timer, so no retakes. One other idea I had was to put one rescue zone near each hostages, except the rescue zone itself is available ~40 seconds after the hostage is captured (aka rescue vehicle ala L4D).

Or a variation of both, CT spawn with an hostage and need to get to one of the two rescue locations and wait for the rescue vehicle. This mode is actually easily doable in hammer. It would be even more similar to de_ maps, almost the same with a few variations (the vehicle leave after a while, rescuing the hostage once the vehicle has arrived is instant, terrorists can cover vehicles entrances from afar, you can call both vehicles at once, etc).

I don't see any differences to be honest, it's not like you changed the time of the day or setting or something like that. You're going to need more than that if you want to fix your color palette.

You can use post-processing for such small changes anyway

I prefer the last two screens, brighter is better. I'd use small constant lights to simulate radiosity if it's getting too dark in some places.

I'm making a CTF map at the moment so I'm curious about this topic too, if anyone have more links to share?

Personally I try to keep the map centered around these rules:

- Keep a main route between both flags, this is the most important route where most of action will happen.

- Add a few flank routes, these should be simple and a bit harder to get into.

- Litter the main route with shortcuts (with a trick/rocket/double jump etc). It should be hard and fun to run the flag properly. Don't do too much because it shouldn't be unfair to run after the flag capper.

- The flagroom is the most important part of the map, make sure it's easy to hold with a few chokepoints (around 3/4), with enough variation in heights for defenders. (well, badlands, gorge)

- Make a well defined middle with the two ennemy "bases" clearly visible and distinct from each other. Sometimes if the middle isn't too well defined, it can be confusing as to where the boundaries of your team are. It should be open, fairly simple, probably set on the outside. (2fort, well, facing worlds)

- It's best if the flag can be capped in a swift swooping motion from your spawn all the way to your capture point. This is more true on Quake/CPMA or Tribes style of games, at least a game based on momentum.

- It's best if defenders can see incoming attackers, to prepare their defense. You can add a window near/in the flagroom/spawnroom which overlook the main route. This can lead to optimization issues, so be careful. (sniper nest in well and 2fort, thunder mountain spawn)

It's shaping up nicely (and fast too!).

On this screen http://i.imgur.com/8hHx6Hu.jpgmaybe the windows can be opened so you can throw grenades?

It's a bit dull and grey, there are no dominant colors, but that's because of the theme. The theme itself is a bit too classic.

More variations in height (3D skybox and on buidlings) would be nice?

On this screen http://i.imgur.com/49DrfXj.jpgthe communist prop seems out of place, your map doesn't look "russian" at all.

I'm nitpicking, I don't find much to say about it, I think it's great.

Also, why cargo?

I always take Extra Credit with a pinch of salt, it's a hit or miss show. Usually there isn't any argument or proofs for their claims, this is the case here. Common sense isn't proof.

Sadism can be found in lots of games and can be a fun and rewarding experience. Removing your portal in Portal 2 Coop so your friend drop to his death. Insta-killing an ennemy in CS at the start of a round so he have to wait for at least 2 or 3 minutes. Watching in delight an ennemy ragequit in any multiplayer game after you killed him. Crushing any ennemy in any competitive game in general. Playing in god mode. Being so good at a game no-one can do anything. Pissing on a dead body in Postal 2.

When you're winning in Worms and you have 4 or 5 worms against a single worm. How satisfying it can be to watch him beg for mercy and to hold the power to crush him as you wish.

You can select multiple faces on an overlay. Go into the overlay properties, click on Pick face in Brush faces, and use CTRL to select several faces.

Overlays are basically super decal, you can change their scale, fade distances and orientations (not only rotate around the surface normal, this is useful on corners), change the rendering order (if you want an overlay to render over another one, useful for markings), change the textures coordinates (if you have a texture atlas, which save memory, file size and is a bit faster to render) and tweak the 4 endpoints into any trapezium.

Overlays are a bit more expensive though, you should use a decal if you can.

To be honest decals are a bit finicky, usually I use an overlay.

Port was probably one of worst map of CS:S, along with compound, it's a good thing you tried to make it competitive. I kinda miss the boat and silo from the original version, now they're replaced with boring warehouses. But then again port was terrible so I guess that's a necessary evil.

Your map is a bit noisy, it seems like you tried to stuff as many props as you could. There are accessible yet unclimbable ladders, ammo crates in a harbour, pipes coming out from anything, the CT boat doesn't fit your map.

There's too many colors in most areas. I'd avoid using props if their colors doesn't fit the scene. It can help to take screenshots and apply heavy gaussian blur so you can see the dominant colors.

It was hard to find my way through the map, probably because of the lack of radar and the fact that most areas looks the same. Add more landmarks in your skybox, more cranes would be nice.

You can see behind some props in some places, add black brushes inside so you can't see through. This is especially important in bombsites, I'm thinking about the ammo crates from mirage here.

EDIT: also lots of breakable glass doesn't work well. Either there's no debris or the glass becomes black.

My post came off as negative but overall it's a very pretty map, lots of details, interiors especially are great. With some work it can be a great map.

Quote from dsillman2000

I predict this won't be easy with such an elevation-varying map...

Bind +moveup and +movedown and use it when you're making screenshots for your radar. You can use it to move up or down during noclip (also ladders?), which also change the plane at which things are rendered when making the radar.

Quote from TheGuma

Correct me if I'm wrong, but I think the world lights are rendered in lightmaps?

Of course! They just happen to be rendered in cubemaps as well.

At least, that's how I think it is. When you build cubemaps you can see some glows where lights should be, and you can actually see lights in some reflections in-game. It wasn't like that in previous version of the engine by the way.

Quote from Muffin

How does phong exactly work and could you give a Noob explanation

https://developer.valvesoftware.com/wiki/Phong_materials

https://en.wikipedia.org/wiki/Phong_reflection_model

To put it simply, envmap reflect world, while phong reflect lights. You don't need cubemaps to use phong, so there's no artifacts related to cubemap resolution. The reflection is pixel perfect. I know world is essentialy light and lights are actually rendered in cubemaps, but I think you get the point.

There's a bit more to it, phong shading is per-pixel lighting, goureaud is per-vertex, and flat is per-triangle.

I'm not sure how source handle models lighting. I guess phong is used if you put $phong in the VMT, otherwise goureaud is set by default. World surfaces are not lit per-pixel, or even per-vertex, because they use lightmaps. Only the reflections matters here.

Quote

Added support for Phong on world materials. See Train for examples of such materials.

http://www.reddit.com/r/GlobalOffens…date_for_42815/

Just wanted to let you guys know.

EDIT: here's the VMT from the modified texture in Train.

"LightmappedGeneric"
{
	"$basetexture" "metal/hr_metal/metal_grated_d"
	"$bumpmap"  "metal/hr_metal/metal_grated_d_normals"
	"$surfaceprop" "Metal"
	


			    "$phong" "1"
                "$phongexponent" "105.0"
                "$phongMaskContrastBrightness" "[.5 8]"
                "$phongAmount" "[4 4 4 1.0]"


		"$normalmapalphaenvmapmask" "1"
	




	//"$envmap" "env_cubemap"
	//"$envmaptint" 		"[.3 .3 .3]"	
	"$detail" 				"detaildetailconcrete001a"
	"$detailscale" 			"[4 4 4]"
	"$detailblendfactor" 	"1"


}

I have no idea what "phongAmount" or "phongMaskContrastBrightness" stands for. Hopefully we'll get some doc soon.

de_bourg BSP file for tonight https://drive.google.com/open?id=0B4foV…clZWVzFmNXdTVjQ

EDIT: oops, now it's fine

Well, that was quick

To be honest I'm raging when I look at some comments, some players are so entitled to free stuff. Especially when these people have zero experience in the industry and assume any developper can get paid. Anyway, nothing new here. To play devil's advocate, it does seems backward to pay for stuffs nowadays.

As a side note, it's comforting to see Valve is listening to their customers.

Quote from spence

You can get into microbrush territory if you scale objects too small or go below 1u when translating with the alt key so you have to be careful with this...

Quote from RaVaGe

Going smaller on the grid should always be avoided that's why I didn't talked about that trick

Yeah, that's what I said. To be honest I never had any issues working off the grid.

It did happen on goldsrc, but never on the source engine. As long as you don't do something stupid, like using world brushes.

I don't know the exact data structure used for brushes. Usually polyhedrons are caracterized by their faces, not their vertices. If theses faces are cut on the grid (= stored as integers), then it's fine. It doesn't matter if vertices are off the grid.

Even then, I don't know if rotations are stored as "rotations" or as "geometry changes". Same for translations. If it's the former then everything is fine, as long as you don't re-clip your brush after the rotation.

To put it simply, as long as you:

- use a cuboid brush first

- keep the clipping tool on the grid

- don't use the clipping tool after a rotation/translation

your brush SHOULD be valid and will show up in-game as it is in hammer.

Remember it's all theory, I can't know for sure.

What are you afraid of exactly? You can backup your map, there's autosave, instancing. The horrors of worldcraft are long gone. If all of this fails, the worse you have is an invalid brush or an invisible face.

Mind you, I will still avoid that as much as possible.

Quote from Muffin

I would never go below 8 units on the grid unless you have stairs. You could probably find a rope model online

Well that's just weird though. How do you make thin metal panels? Plywood? Vents?