My first map – questions & work in progress

[peter_spy]

Afaik is one drawcall per material it doesn't matter if that material uses more than one texture, but i'm not certain right now.

 

Judith don't know if you are saying you want to use 2048 textures but if so, i would not recommend, they take to much GPU memory and are heavier to render, specially for GPU's with 1 GB of RAM, if you want to get detail near a wall, then imo use materials with a detail texture stage, also imo 1024 is more than sufficient to most cases and in others a 32x128 (or even less) texture is sufficient, for example trims, railings, etc, using a 2048 texture in a rail for example is a total overkill, how many pixels does that take on screen? Almost none, but it's texture will occupy a large section of GPU memory.

 

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)

Edited March 2, 2017 by Judith

[peter_spy]

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.

 

Edited March 3, 2017 by Judith

[peter_spy]

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.

[nbohr1more]

The different naming conventions are based on the usage case.

The _px, etc convention is for native OpenGL orientation whereas the _front, etc convention

is an easier to use setup that Doom 3 used for post transform.

 

You can create both kinds in-game:

 

envshot == Doom 3 native

envshotGL == OpenGL native

[peter_spy]

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

[nbohr1more]

It depends on the blend mode you use. For additive blends use RGB.

[peter_spy]

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?

[nbohr1more]

It should be in your cubemap stage:

 

Example from one of our glass materials:

 

 

 
{
        blend gl_dst_alpha, gl_one
        maskalpha
        cubeMap env/gen2
        // tone down the reflection a bit
        red     Parm0 * .2
        green   Parm1 * .2
        blue    Parm2 * .2
        texgen  reflect
    }
 

 

The parm values aren't really needed as I can tell. I think that's there to make the material more

amenable to script events.

[Springheel]

I tried playing with those values in the past and couldn't confirm that they actually do anything. I had to manually adjust the texture files.

[peter_spy]

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.

[peter_spy]

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.

 

[peter_spy]

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.

[Spooks]

I already posted the code snippet you need to use to get cubemaps looking good earlier in the thread. You have a mask stage with a greyscale image through which you can tweak the intensity of the cubemap, I've even gotten to tint it in my tests. gl_dst_color's logic is that where there's higher luminance, more of the cubemap will show up. This will make the cubemap invisible in dark areas (which is pretty realistic) but it will also overbright light hotspots even more. Certainly you can still use that blending mode but heed its drawbacks.

[Obsttorte]

It should be in your cubemap stage:

 

Example from one of our glass materials:

 
{
        blend gl_dst_alpha, gl_one
        maskalpha
        cubeMap env/gen2
        // tone down the reflection a bit
        red     Parm0 * .2
        green   Parm1 * .2
        blue    Parm2 * .2
        texgen  reflect
    }
 

The parm values aren't really needed as I can tell. I think that's there to make the material more

amenable to script events.

The parm variables are set by the values specified in the _color spawnarg on the entity you use the material on. They default to zero. So Parm0...2 is rgb. You can use them to color the reflection.

[peter_spy]

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.

Edited March 4, 2017 by Judith

[peter_spy]

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.

[peter_spy]

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

 

Edited March 7, 2017 by Judith

[Bikerdude]

Assuming the above is all wip, just some feedback -

• the specular is a tad on the bright side.
• And the bricks looks plasticy, but I guess it depends on thier intended use?

[peter_spy]

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.

Edited March 7, 2017 by Judith

[peter_spy]

Quick question: is using symbols like these too much "Hammerite" and possibly copyright-infringing? I wanted to make something more like the original Builders logo, but this isn't half bad either.

 

[Springheel]

I don't think that's a problem. You can't copyright hammers or gears.

[demagogue]

It's fine, keeping in mind we have an order of Builders that might fairly use such a symbology that, in the end, has a different history and backstory than Hammerites so is a different group in a different universe. Just think if Builders could actually use this design. I think so.

[peter_spy]

These are fair points, thanks

[peter_spy]

I just had a few hours this month for editing, so I probably won't be able to solve this right away, but is it just me or IDTech4 doesn't like using overlapping UVs? The lightning looks pretty weird and the material looks metallic, even with proper specular. I'm guessing that's what's causing problems and those IES-like lights. After I fix this, I'm planning to write quick guide on how to design a basic flexible tileset for this wall panel. This is one texture and one mesh by the way, just split in sections and variants, to cover as many uses as possible. All with properly placed pivots, so you can place it in seconds. This was made with grid of 16.

 

Edited April 14, 2017 by Judith

[Spooks]

I'm out of my element on this one but just FYI TDM's lighting system has a default specular value that adds a little fresnel reflection even if the material is only lit by an ambient light. That is why your material might look metalic.