ACEfanatic02

I considered doing this, but the way night is done in-game is just by multiplying a color on top. Shadows are unchanged. We could deviate from that here, but I think it'd be pretty noticeably different from existing buildings. I've gotten sidetracked a bit lately (ADHD spun the wheel again and got me back into RCT2), but I am close to finishing up the updated light rig. Moving everything into an asset library is a good call, I'll take a shot at that as well.

FWIW, if you separate all of the windows into a _single_ object (not one object per window) you should be able to use the Random Per Island input in the shader graph to offset the noise individually per pane.

That looks a lot better! I like the blinds. A few more nitpicky suggestions: the bump noise on the glass is a little intense. I'd maybe reduce the scale on the noise texture a bit, maybe halve it, to reduce the noise frequency. If the panes are separated (i.e., not a single sheet of geometry), you can also play with the Random Per Island node to break up the noise per window pane. I'd also suggest playing with the coat roughness (assuming you're using the coat for tinting). By bumping that, you can soften/mute the reflections higher up the building without needing extreme noise in the normals, which looks a bit more natural. The advantage of doing this with coat roughness (instead of base roughness) is it will have less effect on the transmission, so you'll still be able to see through the windows correctly. Again, nitpicking, it looks great already. But prominent reflections tend to look a bit jarring in-game where they don't actually correspond to anything.

Unfortunately the light rig (and compositing setup) depends pretty heavily on driver connections to know the rendering state. AFAICT, drivers are very fragile and break as soon as you copy them, even within a file. So we'd need some alternative means of getting the data around. I've experimented with custom named properties for this, but annoyingly one of the fields I need to update (the rotation of the sun disk in the world lighting) does not support noodle-graph input and so can't be changed automatically without a driver. I do absolutely agree it should be better, and I hope we'll get there in time. For now, the expected workflow is to start by forking the light rig file and importing anything you need in there. Alternatively, use linking to non-destructively load your model into the light rig scene (this makes it a little easier to update to a new version of the rig.) Somewhat related: in an attempt to make emissive night lighting easier to manage, a new custom node: Work has been kicking my ass so I'm struggling to find time/energy to get this all ready to go, but updated rig should be out sometime this month.

I think the glass may be a little too reflective, especially on 1 S Wacker. Looks more like metal than glass on the shadowed side of each view. In street view you can clearly the offices through the windows, so they're not nearly that reflective IRL: The bands of opaque and transparent windows would break things up a bit, make the building look a little less... dystopian, IMO.

I disagree, actually. There's definitely some sharp edges remaining in the Blender workflow, but it's absolutely possible at this point to make models, light them correctly, and get them in-game. The bottleneck is learning to use Blender itself, which is... not the most intuitive piece of software out there. OTOH, the internet is drowning in tutorials on "how do I do X in Blender", which is emphatically not the case for GMax.

Hey, all! Figured it was time to start a thread of my own. This thread will focus on my active BAT projects as well as Blender tutorials to help folks getting into Blender for the first time for BATting. (Why yes, I am stealing Jasoncw's format.) Any work I do on BAT4Blender, or my light rig, will still be posted to the main BAT4Blender thread as well. Note that I do not intend to do basic explanations of Blender UI or modeling. There are tons of existing tutorials on Youtube that do a much better job than I ever could in that respect. (I personally enjoy Grant Abbitt's videos, for example.) Instead, I want to focus on more intermediate tutorials about how to setup materials, and procedural setups with material layering (and possibly some Geometry Nodes stuff?), specifically in the context of creating BATs. Table of Contents: [RESERVED FOR FUTURE USE] ----- STEX Releases: [RESERVED FOR FUTURE USE] ----- Works in Progress: BATs: Art Moderne building at Main & Water St. in Harrisonburg VA. (Name TBD) John P. Taylor Apartments (Based on building 3 of the Troy Housing Authority project in Troy NY.) Public pools pack (original / collage designs) Tutorials: Glass Materials in Blender [1/? complete] How To Use Downloaded PBR Textures [0/1 complete] Material Layering [0/1 complete] ------ A general warning / caveat: I have a demanding day job and ADHD. I make no guarantees about the frequency of updates or releases. For now, BATting is a nice outlet for my creative needs; if it becomes a stressful thing (or if the special interest wheel just happens to land somewhere else) I will stop. Please do not be a jerk. Asking for a status update about a project that has not been mentioned in a while is perfectly acceptable. However, demanding that I work on or release a particular BAT is not acceptable behavior and will be ignored. (Yes, I read other threads, I know how things tend to go here.) (Mods: preemptive apology for the impending double-post; I want the first tutorial to be separate from this intro.)

Yeah, I think the sims are sort of the "original sin" of SC4's art direction. (In terms of consequences, I'm not actually sure it was the wrong choice.) I was actually doing some tests this weekend to see if I could match the scale of the sims in Blender (using the human base meshes Blender released a few years back). Turns out the sims are about 1.5x larger than they should by (after accounting for the 136% vertical scale to compensate for the perspective.) AFAICT cars are not scaled up the same (they're closer to realistic sizes), which makes things even weirder. I assume the sims got scaled up just to keep them visible out to Z3 (which seems to be the sort of 'default' play condition), but some subset of buildings are scaled accordingly and others are not -- for example the rowhouses I showed a few posts ago are too small, the sims are taller than the doors. I'm guessing the decision to make sims bigger happened mid-development. Or maybe there just wasn't consistent art direction around it, who knows? Maybe a thing to do would be to replace the various sim sprites with reasonably scaled versions. For Science.

Didn't do a whole lot this weekend, but I whipped up another variation of the shotgun house: Both variants will come with a bunch of color schemes (I have about 6-8 setup right now), but rendering all of those out and lotting them is kind of a pain so I haven't bothered yet. And because I cannot focus on a single thing (ADHD wooooo), another experiment tonight: Playing around with a modular kit and seeing how reasonably you can fit a suburban school into a 4x4 lot. Answer: not quite. Missing a place for a library and doesn't have quite as much classroom space as you'd want for a realistic capacity. It's more plausibly scaled than the Maxis elementary school, but that's not saying a whole lot. From measuring references in Google Maps, this _should_ be somewhere between 5x7 and 8x10. OTOH, this is much nicer than the Chinatown building I did earlier from a workflow perspective, because everything here (with the exception of the sign, roof and interior floor) is modular. So it's totally reasonable to take the same kit and build out a few different schools of various sizes. I like the general feel of it though. Aiming for the sort of generic institutional architecture that almost every school I ever attended was built with.

And now for something completely different: Did a wiki-walk from reading about NY tenements and ended up at Shotgun house, and these seemed quite charming and also simple to model. Ideally a competitor to the Vanilla R$ stage-3 duplexes. This particular one is loosely based on some in Mobile, Alabama.

Reexported 35 Elizabeth St. again with a reduced scale (133% instead of 136%). I think it feels slightly better in-context now relative to Maxis R$$: Not sure if this is a matter of floor heights or just the inconsistent scaling on the Maxis side (lol, look at the differences in stairs between those rowhouses), but this feels better even if it's less 'correct'. My windows are also just generally larger than on Maxis stuff, which I think contributes a lot. Still overly enthusiastic and grows too much, so will need to redo the modding, but I think it's getting better.

Instance texturing: yes and no. UV maps are the same between all instances, as are many of the procedural coordinates (generated and object-space, in particular.) However, there are shader tricks you can do to produce unique coordinates from these. For example, in the case of 3D texture sampling via object-space coordinates, you can instead use a vector transform to sample with world-space coordinates: In the more general case with UVs, you can potentially use an Object Info node to offset your coordinates according to the object position (which will be unique for instances placed in different locations). This one takes some care to avoid misalignment for structured textures (i.e., not splitting bricks in half), so I don't really bother with it. Overall I think you can just get away with not doing any of this in the majority of cases. Where an area is visually dependent on unique texturing, like the sides of this W2W building, you usually don't have much geometric detail. In that case, we don't need to build it from modular pieces, and we can give the entire wall unique UVs. OTOH, where the modular pieces are useful you tend to have a lot of geometric detail. Those hide some of the repetition, and they also are where procedural layers of dirt will show up, further disguising any issues. Being careful with the contrast of these textures also goes a long way. This BAT has some texture repetition if you know where to look for it, but it doesn't really stick out, and it's no worse than using a tiling base texture to begin with. Pools: agreed, we need more of these. Especially up here in the northeast they seem to be everywhere. Interestingly, the caustics are the easier part of water shading. Blender has approximate directly-sampled caustics via MNEE that you can turn on (it's sort of a pain, though, you have to enable them on the light source, the caustic caster and all of the caustic receivers for them to work.) Use a subdivision and ocean modifier on the water plane to model waves, and it will generate plausible caustics for you. Where this is a problem, though, is that these caustics are incompatible with volumetric rendering. So if you want proper water absorption, you have to fake it in the shader: This just uses Beer's law to compute the absorption and multiplies it into the base albedo color. Which is not correct, to be clear (it does the wrong thing for specular light off the base of the pool), but is close enough. I did a couple days of research trying to find the 'correct' absorption coefficients to use, but while there is some data out there the actual color varies wildly depending on what's in the water (chlorine or dirt or algae, etc.) So really just want the absorption to kill most of the red light, some of the green, and eyeball it from there, hence the reddish-orange extinction color. All of this is a massive pain, and my hacks only work in specific cases. Refraction and volumetric rendering are one of the areas Blender is really lagging behind in, relative to a lot of other renderers. (Which is not really a complaint; I'm a graphics programmer, I know exactly how really goddamn hard this problem is.) Fortunately BATs make it easy enough to cheat.

Exported, lotted, and testing: Apparently PIM-X has some rendering errors around sliced models, which made me panic and export repeatedly trying to fix it. (I've got a decent gaming laptop but that's still ~15m each time.) They don't show up in-game, so all of that was unnecessary. ¯\_(ツ)_/¯ Immediate thoughts: it feels a bit over-sized relative to other mid-rise buildings. I don't think it actually is, though, but the only comparable Vanilla buildings are 3-story rowhouses. (Which actually line up reasonably well.) It's currently a stage 6, but it doesn't have any other stage 6's in the 1x2 footprint to compete with in Vanilla so it grows very enthusiastically. Will need to tweak the filling degree, and I might even bump it up to stage 7 just so it doesn't completely wreak rowhouse neighborhoods? I'm excited! I've never gotten this far with BATting before.

Night lights for the back, and some water damage decals to liven up the walls a bit. (Might still be a bit too intense, could lower the opacity on those...) This area doesn't have full interiors, just walls and floor; I don't think the windows are large enough to justify it. Put a Voronoi texture on the walls to give some amount of fake detail, but very little of it is really visible. Looking at this now, I maybe want some exterior lights around the patio. Otherwise, I think this is... done? Maybe? I dunno. Am I missing anything?

A bit of quality-of-life feedback, after doing a fair amount of actual BATting now. None of these are that critical, just things that would be nice to fix: - I'm not entirely certain how important the model being exactly centered is. However, assuming it is important: recentering a model built up of multiple pieces is a massive pain in Blender. Could we instead translate the camera according the LOD's center during rendering? Even being careful to block things out centered, it's easy to end up with an uncentered model just because the depth of detail is different on different sides. - The automatic LOD generation doesn't seem to work correctly with collections. Currently, a collection that is hidden (but whose children are not) will contribute to the bounding box. Additionally, the generation only seems to account for explicit objects; instances of collections do not count, which is a bit of an annoyance with modular techniques. - The Day/Night collections for controlling lighting are nice, but it'd actually be quite useful to have multiple collections for each. (For example, if you build out a lamp with geometry + lights in a second scene, then instance to the first, AFAICT you can't put just the lights in the Night collection. Ideally you'd have another Night collection in the other scene to hold those lights and hide both.) I think checking for all collections with a prefix of `Night_` or whatever might work? (Or maybe `B4BNight_` to avoid naming conflicts.) - Minor bug: Day / MN / DN setting is not persistent in a file; if you render a night preview, save the file, reload, and preview again immediately, you will get a Day render with night lights on. (This is easy to work around, just toggling to MN and back works.) I don't know if this affects actual exports, but it's a bit of a footgun if it does. To counterbalance the criticism: 95% of the time B4B Just Works and stays out of my way, which is maybe the highest praise a tool can get. Good work, @memo! Still iterating on the next version of my light rig. Found out you can get a significant quality boost by denoising the extracted night lighting separately from the base image before compositing them together again, so need to backport that to the rig. Also working on cleaning up the compositor graph in general; I want to pull out some tweak values so you can do things like adjust sharpening and disable alpha clip without digging through tons of nodes. Hoping to make this easier to work with for people who are not me.

First pass at the rear side of the building: Modeled a nice little modular kit for the fire escape... and basically all of it is hidden. Oh well. The bounce light in that area is really neat though. The little outdoor patio is real (although I've changed the layout), but the windows on the extension building are completely nonsensical IRL and not clearly visible from satellite view anyway so I've just made something up. Floor plan doesn't make a whole lot of sense but... eh, it's fine. This is pretty close to done, now. Some lights for the back, and a few decals to liven up some of these bare walls and I think it'll be good to go. (Which means I need to learn how to lot in PIM-X, ugh. Anyone want to do that part for me?)

@Jasoncw: Yeah, one of my hopes is that a combination of instancing and geometry nodes can make this process less painful. (Like, model ~4-8 room layouts--or at least the bits near windows--and then have a random layout instanced at each room in the building.) Still requires thinking about the internal floor plan a bit more than just modeling facades, but I don't think that's always a bad thing. @IDS2: Thanks! Ironically, your note about "floor to ceiling windows" really nailed what was bugging me about them. They're large windows, but they're not supposed to be that large. Double-checked, and in addition to making the beams a little too narrow, I completely forgot to model the lintel/cornice (I don't know architecture terms) detail above them. Fixed those, modeled an interior sill, and I think it looks a lot better. (Chalk up another point for modular buildings in that fixing this was easy.) Went and looked up this building on Zillow. Turns out there aren't any apartments IRL, the entire thing is medical office space. (I knew the second floor was a dentist office, but I assumed the upper floors weren't.) Does explain why the layout doesn't work very well for apartments, though. All of the ones I modeled are basically 1400+ sqft which is a little ridiculous for Manhattan. (And also just really big in general. My apartment's ~750 and it's pretty spacious.) Oh well. Not gonna change it now. Bunch of material tweaks. Wood floors have a bit less contrast. Added dirt layer to a bunch of the exterior. Really helps sell the wear and weathering in a way that AO alone does not. Made night lights in the apartments brighter. Don't want them to be completely washed out, but they should be overexposed if we're able to see details on the exterior. Did a bit of work on the side walls and started blocking out the back part of the building. The sides deviate from reality a bit; IRL they're covered by a thin / damaged layer of paint or plaster, but every time I attempt to imitate that the results look too busy and distracting. So: plain brick. (Different material from the facade brick, less even with wider mortar.) May throw some subtle leaking stain decals on these later just to break it up a bit, though.

Night lights for the front facade, and started on the roofjunk. (The little AC unit farms on renovated old buildings always look funny to me...) Also started a grime pass, you can (sort of) see the results around the edges of the roof. Using AO to blend in a procedural dirt material (which is a really fancy way of saying a noise texture fed through a color ramp.) Really just there to ground things a bit, will make a bigger difference when I add the same layering to the other materials. I think the interiors worked out well, but I'm not sure if it'll be too out-of-place in the game. Will definitely look weird next to Maxis stuff, might look okay together with more detailed BAT4Max renders? I dunno. Thoughts?

How many consecutive posts before I anger the mod team, I wonder... Finally modeled the shops (exteriors at least) on the first floor, along with the awnings on the second. Only major detail missing from the facade now is the exterior lamps on each of the piers; will need to see if those actually look good at night though, if they cut off at the edge it may be better not to have them. And because I think it's interesting, here's all the modular pieces so far, separated out (the ground floor didn't have a whole lot of reuse going on): Front row here are some low-poly props for the apartment interiors. Might be a bit overkill, but if these end up working well they'll be reusable for later projects as well.

Fleshed out the basic roof structure (this is all unique geometry instead of modular pieces.) Still need to do the ground floor, roof junk, back wall, and a lower extension filling out the back of the 1x2 lot. This is loosely based on a real building, BTW, 53 Elizabeth St. in NYC's Chinatown. Taking a few liberties to keep things better suited to SC4. (Also modeled the windows in the arch incorrectly and I'm too lazy to fix it.)

Experimenting with a different, hopefully better way of building facades. Instead of directly modeling everything in-situ, this is modeled in parts and then instances of those models are assembled into the final facade. Slightly better for workflow because you can solve the modeling / texturing issues (like those arches, which are a pain to UV) at small scale, then reuse them. Also means that there's only a small amount of 'real' geometry in the scene (despite the detail there's only actually ~6000 triangles in memory for this render), which means both the editor and render run faster. Might write this up as a tutorial at some point, it seems really promising.

Pretty well, actually! Here's the same building rendered with SSAA and downsampling. (Caveat: I used Catmull-Rom because I apparently have an older version of ImageMagick.) This is without changing the render samples, so it's effectively 4x the samples of the other render: (I did also try a version where I reduced the sample count accordingly; there's no appreciable difference between the two unless you zoom in a lot.) And the RCAS version again for reference: The RCAS version is sharper, and traces only a quarter as many rays (not terribly important here, but potentially a big deal if you have a large building with expensive materials.) A proper Lanczos downsample might do a bit better, I dunno. It's also pretty clear that RCAS oversharpens (particularly around the bricks in the front facade), but it does so in low-contrast areas and effectively 'hallucinates' extra detail.

I've been experimenting with improving the sharpening in the compositor and I think I finally have a good result. Compare these two Z5 (SD) renders (open both in new tabs and flip back and forth for easy A/B): Getting sharp results without introducing severe artifacts or aliasing is a bit of a challenge. I eventually settled on an implementation of AMD's RCAS. This computes the sharpening amount per-pixel that can be performed without clipping (going below zero or above one), restoring detail in soft areas but avoiding over-sharpening around edges. There's an additional factor that identifies 'noisy' pixels and reduces the amount of sharpening to keep them from being highlighted. While that's optional in the original, I have it always turned on because the output from Cycles will usually be a bit noisy, particularly around glass. It's about 80 lines in shader code, but unfortunately makes a bit of a mess when expanded to nodes in Blender: I'll include this in the next version of my light rig.

The "Fit Z*" button for each LOD level just rescales that particular LOD box to fit the currently visible meshes. Mesh fences are hard to render correctly in general, _especially_ at a distance. Looking at this, I'd say you probably want slightly wider spacing between the wires of the fence mesh, which will keep it from going completely opaque so early. The wire across the top is too thin to show up at lower LOD; with binary alpha you can't really have a silhouette feature smaller than a pixel that shows up. You'll need to exaggerate the thickness if you want it to show up. (Or this may be a case that merits using actual alpha blending instead of DXT1 so you can have subpixel features? I'm not 100% sure how to set that up though.)

Glass Materials in Blender (Part Two): This tutorial picks up from the end of Part One. Make sure you've gone through that first, as this part will build on what we learned last time. Additionally, from this point on I will be assuming you are using a recent version of Blender (at least 4.0) as there have been some important changes to the implementation and interface of some shader nodes (particularly the handling of Coat layers in the Principled BSDF.) Background: Last time, we covered how to create a basic, clear window glass material, and how to properly model window panes to avoid excessive distortion. While this is an important building block, it doesn't quite match up with real-world window glass. Especially in modern, International Style skyscrapers, windows are highly reflective, often with prominent tint colors. (Most often green, blue, or black, but sometimes gold or even red.) There are multiple ways that this can be done IRL, but they all come down to some kind coating placed over the glass. We will look at one of these in detail: a tinted plastic film coating (which helps reduce the amount of heat entering the building through windows). Afterwards, we'll talk a little bit about how to handle more metallic coatings, however my implementation there is a lot more ad-hoc. (Caveat: I am not an architect; I make video games, not buildings. So I may be getting some of the details about this wrong.) Looking at many skyscrapers from ground level, you might assume that these windows are effectively mirrors and completely opaque: (Google Maps screenshot of One East Pratt Street, Baltimore MD.) However, if you look closely, you can see the lights on the internal ceiling. In other instances, you may notice that windows suddenly look more transparent when a shadow is cast on them. And of course, all of these look more transparent at night. So, what's going on here? These are examples of the one-way mirror illusion. When looking at the window, you see both a reflection and a refraction. However, because the interior of the building is so much darker than the exterior of the building, the reflection dominates and you can't see inside. This is why only lights seem to punch through, and why the windows look transparent at night (when the exterior is darker.) From the aerial viewpoint of SC4, a few things make this effect less pronounced. First, when looking through windows you're seeing the floor, not the ceiling, which is usually directly lit by windows and light fixtures and therefore may be brighter (although this is countered in most office and residential cases by darker materials on floors.) Second, the windows reflect the ground when viewed from the air, rather than the sky. This will generally mean the reflections are darker, and the windows more transparent. Between these effects, fully mirror windows are not really realistic. Even metallic window coatings are still transparent (otherwise you wouldn't be able to look out of them), they just look more opaque because metals reflect a higher percentage of light. With that out of the way, let's get started. Plastic Film Tinting: Most window coatings, particularly in residential high-rises AFAICT, are a polyethylene terephthalate (PET) plastic film. These are designed to filter and reflect infrared and UV light, and typically have some color tint to them as well. The glass shader we created last time has a base color of 100% white. That is to say, it passes all light through. While this is mostly true for plain glass, in practice the glass does absorb some light. Reducing this to 95% white slightly darkens the interior without being too extreme: The checker pattern has been restricted to the area in front of the windows here to more clearly illustrate the differences in reflectivity between improperly-modeled one-sided glass (left), a single pane of thick glass (middle), and two panes of thick glass (right). Notably, the additional surfaces cause more darkening of the interior, which in turn causes the reflection to appear brighter. It may be tempting at this point to set the base color to blue or green to mimic a tinted window. However, this doesn't quite do the right thing. The window color appears too saturated, even with the tint limited to 50% saturation: Instead, we want to use the Coat layer of the Principled BSDF to apply our tint. Starting with the node group we made last time, drag out new inputs for the coat tint, weight, and IOR. Setting the tint to a nice cyan (HSV: 0.5, 0.5, 1.0), the weight to 1.0, and IOR to 1.575 (the IOR of PET), we get this result: Well that doesn't look right! There are two issues. First, we don't have any colored shadows like we do when we set the base color. Second, we've got the same extreme saturation issue that we had with the base color tint. The shadows are easy enough to solve: blend the base color and coat tint together with a Mix Color node set to multiply, and with the coat weight plugged into the factor. When we turn the coat weight up, the shadows will now respond correctly. The saturation issue is happening because the tint is being applied on all of the faces of the window. So, when light hits the window, it goes through the coat layer on the outside, then the outside glass, then the inside glass, and finally through the inside coat layer. The tint gets applied twice as a result, making it darker and more saturated than intended. (Worse, there are more IOR transitions, meaning more reflections, which make the glass appear more opaque than it should.) To fix this, we want to apply the tint material only on the exterior surface of the glass. If you've directly modeled the panes of glass, this is as simple as selecting the outside face and assigning it to a different material slot. If you're using the Solidify trick mentioned in the previous tutorial, you can use the Material Offset option to select a different material slot for the extruded face. Note that for this to work, you must make sure you have two material slots on the object, and their relative positions in the material list need to stay the same: In this case, since the tinted and untinted material slots are next to each other, assigning the tinted slot to the window and setting the Material Offset to 1 will assign the extruded face to the untinted glass. With these fixes, we now have a robust PET tint: A few things to note: there are multiple reflections occuring here. The primary reflection is off of the coat layer, and it will not include the tint color. The secondary reflections occur off of the glass, and they will include the tint. This causes the reflection to take on a bit of the tint color, which is part of why using coat for tinting looks better than base color. To make the windows appear more reflective and opaque, simply lower the value of the tint color. The (untinted) reflection will dominate. For example, setting the tint to 20% grey does a very good job of creating the one-way mirror effect: This window is still transparent, though, and so things like night lighting Just Work: Metallic Coating: Sometimes windows have a distinctly metallic appearance. There are two properties that sort separate metals from non-metals. (Visually, that is; obviously there are a lot of differences in the rest of the physics.) - Metals have extremely high base reflectance; looking at glass or plastic or really any non-metal straight-on, it will reflect somewhere between 2-8% of light. Metals, on the other hand, tend to have reflectances in the range of 50-90%. (Both approach 100% when looking at a shallow angle. If you don't believe me, go look at a piece of cardboard edge-on and be amazed at how mirror-like it can be.) - Metals have strongly tinted reflections. Non-metals can usually be separated into a specular layer with untinted, relatively weak reflection, and a diffuse layer with strongly saturated color. If you shine a white light on an apple, the apple will look red, but the highlight will still be white. Metals, on the other hand, tint their specular reflection and don't have a diffuse layer. So if you shine a white light on gold, it will appear... well, gold. These result in noticeably different behavior as a window coating. The high reflectivity means that metals do a much better job of making a window appear opaque in sunlight (while still allowing them to be transparent from the inside). It's also not uncommon for these to use colored metals. For an example, see the Market Square Center in Indianapolis. PBR renderers typically assume metals are opaque, so there's no real 'correct' way to simulate this effect. What I've landed on instead is a bit of a hack. By using the Layer Weight node to blend between our glass material and a metal material based on view angle, we can maintain a consistent mirror appearance (because at oblique angles the reflectance from the glass is also quite high.) The resulting node group is... a bit of a mess. In hindsight, it'd probably be better to have separate node groups for PET and metal tints. I'm not really happy with it, but here it is if you want to replicate it: The results are pretty nice, though: As opaque as it looks during the day, when backlit at night it is appropriately transparent: That's an awful lot of words about glass. This concludes the glass tutorial. Hopefully this was useful!