peter_spy

Gamma of 1.2 should be a good starting point, I use it all the time.

These are not bricks – it's tiles. Normals are automatic njob work, so I'll redo at least some of them later. The wall will have its proper paint as well. This is all with bloom on to take it into account, so it's kind of a bit brighter. I'm not sure I'll leave it like that, but going under 96 or 64 with texture levels seems to be too subtle in many cases.

A couple of new general-purpose textures for the project. Somehow everything I do turns into a Victorian asylum theme, I'm not sure this is a good thing

I loved BF 2 & 2142 back in the day, I even was in a "clan", with Teamspeak and all. But these days are over

This is a good place to start: This channel, along with Curtis Judd Audio, is very good, I learned a lot from this guy. At one point it basically saved my recording, it was a concert in very unfavourable conditions, and with constant hum from nearby lamps.

OK, CameraCubeMap is also a winner because it requires only two transformations, Up has to be rotated left, Down – right, and the rest is unchanged. As with TDS, brushes don't use the coordinate system well, so looking at them at different angles changes how cubemap sides are displayed, but that shouldn't be a problem with regular static meshes.

One of those is in my area, I've been there twice on photo shoots (4th picture, counting from the top).

You're right, I forgot about this one. I'm not at my full abilities, having a cold for over a week now, which makes me kind of restless. { maskcolor map makealpha (textures/do/base/wall02_s) //here I use the specular of the texture alpha 1 //this darkens the alpha by half, modify it as you wish } { blend gl_dst_alpha, gl_one maskalpha cameraCubeMap textures/do/env/test texgen reflect } Anyway, this seems to be a "default minimum". Alpha is working, and sure, if you leave it at 1, it looks like this, but alpha tweaking seems flexible enough for what I need. Also CameraCubeMap seems like the way to go for objects, as it automatically mirrors cubemap faces.

No biggie, that's the usual chaos of publishing something on the interhighway There will always be people who will tell you what they think your work "should" be, regardless of your goals or intentions. I was probably expecting some more educational material, like this one on CS GO. But these are two different things, I should have known this will be more like Obstorte's videos. Again, nothing wrong with that

Oh, if it's just a "dear video diary" thing, then nevermind

I must say I like your videos better when they're a bit shorter. I rarely have time for 1-hour videos, and it's easier to skip to the part I need help with, when the video is shorter. This way of presentation, with slight fast forward, is also nice:

Spent another hour figuring out the directions of both cubemap systems, because of course they are different. And of course North is neither +y, nor forward, that would be too simple.

Oh, since this is part of the code for glass and I'm using opaque material, I changed blend gl_dst_alpha to blend gl_dst_color, which works much better here. Not perfect, but better.

It's still fully opaque. I think Springheel's right. Surprisingly, it works with texgen skybox, but the effect is ugly. Look: Default setup with _d, _s, _n: Texgen skybox, it ignores normal and specular (well, it was for skyboxes) Texgen reflect, uses all previous stages but does not react to rgb value changes.

I'm using CubeMap with blend add (other didn't seem to work), but RGB does nothing. I use it after all image programs, should I use the diffuse stage instead?

Yup, that works, thanks. How do you tweak the reflection intensity though? The example on modwiki uses alpha, but it doesn't work.

Alright, now I see it, the image on modwiki is so small on 1440p screen I couldn't make anything out of it. So the cubemap is for a flat image reflection that has to be split between 6 surfaces, like an image for a window or fake mirror. Cameracubemap is for proper 6 sides of a cubemap and it should work better with 3d objects.

Testing basic cubemap reflections, it seems like there are two types of those: cubemap and cameracubemap. The latter seems to look better, because it hid the seams between textures? Not sure yet, but both seem to be using images differently (i.e. you can see there's certain offset or maybe it's mirrored?). One thing awfully confusing is that the first one uses _px, _py, _pz suffixes, while the other one uses _front, _back, etc. This should be unified, preferably to _px, _py, _pz, etc., because it's shorter and looks more organised in folders.

That never worked in my case. Ctrl+K is very useful though, I remapped this to just K to make it faster. Also, on various lists, you can start typing name of an item (command, property etc.) and use up/down arrows to move between matching items.

It's still about lego, but it's harder, because you have to model them yourself. And then you have to make them look organic and unique, with additional meshes, clever lightning etc. You need years of experience to do this really well, so no wonder it feels like a chore (but it's really rewarding in the end). Also, there's this one obvious but huge difference in making singleplayer and multiplayer maps. The latter gives you more time for improving your modeling and other skills, because you don't have to worry about the plot, any storytelling you do is background and environmental, you basically don't need scripting, readables, voiceovers, cutscenes etc. Good level flow, nice but unobtrusive graphic and sound design, and there you go.

Agreed, but that was more about the death of level designer (i.e. someone who needs a game system(s) and assets to create something). Indie and "AA" game world is more thriving than ever.

Btw. you can get rid of the static with Audacity noise reduction tool. Since it's a uniform noise, it will be fairly simple to get rid of. AFAIR, you just have to select the noise sample and then Audacity removes the noise automatically from the whole track.

That tread on Mapcore, this is basically what I think standard mapper should, or even has to be, these days: level and environment designer. Most screens are either environments or fully custom maps for UE4, CS-GO etc. This was quite common during my UT3/GoW days too, and it kind of goes without saying on sites like Polycount, which attract hobbyists and pros alike. This is also what I do for my first small mission, because my skills are more of env designer than level designer. I think there's no synergy between those communities and TTLG-related community because: A ) DromEd is super ancient right now, by any standard, and anyone having background in anything like Unreal Engine 2 and newer will consider DromEd a waste of time; B ) And this is mostly my personal observation: Thief-related community is very reluctant, I'd say almost hostile, to the idea that modelling and texturing skills should be a natural extension of mapper's abilities. People like using stock assets or stuff made by others, maybe to focus on level design itself, or to reduce time needed to release a mission. This way there's no common ground with people who can create almost everything from scratch.

Yeah, their question doesn't make sense, does it. Unless you're a one-man-army game developer with a game to create. Engines like Unreal and Unity are more suited towards environment designers, not level designers per se. You can use UE4 to showcase your texturing and modelling skills, but I always find it kind of sad. All you can do with it is to make a flyby movie and put it on YT, which will compress the hell of details you put in your work anyway. You can let somebody run around your scene, but what's the point without gameplay?

No, 2048 textures are for initial "nice to have" version and beauty shots (aka bullshots or Ubishots ). They will probably get scaled down in optimisation stage, although I'm aiming for hardware like 2 GB video card laptops. I think these are pretty common these days, but might need to confirm that. Also, I said I'm keeping in mind texel ratio / pixel density, so stuff like trims will have textures scaled accordingly to maintain pixel density across all surfaces and objects. The ratio I use is 1:8 or 0.125 (which is 0.5 in DR's surface inspector, because editor's default scale of 1 is actually 0.25 ratio, as demonstrated earlier). That means a wall that is 256 x 256 will have a texture of 2048. Everything else will be scaled accordingly. A trim surface of 256 W x 16 H will need a 2048 x 128 texture, although it's better to have several trims on one square texture to save on texture count and to use video memory in more efficient manner. Not sure I'll need 16 different trims, but who knows (Edit: page break, grammar, and typos)