SS2 list of broken and lowpoly objects that need fixing

[67e88a4c364b6ZylonBane]

Dark lighting doesn't care about level geometry beyond whether it blocks raycast from a light source to the model's center point.

[67e88a4c36a02Olfred]

I see. Then the change came from the changed position and not me moving it slightly out of the recess.
Well, just check the new model and tell me if it improved anything.

[67e88a4c36d4cZylonBane]

Didn't help much. Here's a screenshot of the locker and a vanilla object with an omnilight equidistant between them.

I suspect this lighting issue might be caused by the nonstandard export configuration imposed on this and the broken locker model, with the bounding box being very different from the actual size of the model. It also negatively affects visibility calculations, with the model sometimes disappearing before it's completely off-screen.

Well, these models were created back in the early days of SCP when we were trying to come up with drop-in replacements that wouldn't require moving the original models (much). These days we're fine with moving things around to accommodate new models.

I propose creating new (well, based on the originals) locker and broken locker models.
- The locker and broken locker models should be identical other than the light color.
- They should be exported with no weirdness-- centered and with bounding box same as actual size.
- They should have the back chopped off so the "locker" part is only deep enough to bring the total model depth to 0.5. This will be shallow enough so the frob brackets won't be huge (the original reason the small bounding box was hacked in), provide just enough locker depth to have them sticking out of the wall a bit, and by keeping the centerpoint in front of the model (since the stick-out part is 0.313 units deep) would allow embedding nearly flush in walls without disappearing.

SCP displays a static bitmap when searching lockers, so players would never see how shallow the model really is.

I'm tempted to also ask for recessing the "grill" part of the model if that's not too much trouble, but I'm not sure how deep it should be (not very, I'd think) or if it would even look good.

Anyway, does that all seem like a sensible course of action?

[67e88a4c36e87Olfred]

I can take a look at it, but probably will be in like 2-3 weeks as I'm away soon and still need to take care of some things.

[67e88a4c36fc9ZylonBane]

That's fine. I've been playing around with this and even the original model has the weird lighting issue. Still has it after running the model through bintoe/bsp. Something is cursed about this model.

[67e88a4c3744deldrone]

ZylonBane
Was playing around with this because the rendering issue had me confused too, so I imported the previously posted locker.bin and re-exported it, and I'm not having much issues.

This is with the old nemyax blender script and newdark.

( forgot to set emission on the green, so ignore that)

[67e88a4c376a1eldrone]

With that said, I almost always exclusively use these settings:

sort: by vertex group
origin: object origin
export only: selected

[67e88a4c3785bZylonBane]

Have you tried testing with the primary light source directly in front of it? For some reason it lights fine with distant sources, but at 6 units away the face abruptly becomes darker than the nub, and gets even darker as the light is moved closer.

I am bearing in mind that low-poly vertex-lit surfaces can have this problem when light sources get too close to them, but this model is lighting much darker than other boxy models.

This usually isn't a problem since most lights are far away from the lockers, but on some levels like command2 the mapper specifically put small brush lights in front of the lockers to help make them more visible, and they just don't work. At least, not in a visually coherent manner.

[67e88a4c37ccdeldrone]

Have you tried testing with the primary light source directly in front of it? For some reason it lights fine with distant sources, but at 6 units away the face abruptly becomes darker than the nub, and gets even darker as the light is moved closer.

I am bearing in mind that low-poly vertex-lit surfaces can have this problem when light sources get too close to them, but this model is lighting much darker than other boxy models.

This usually isn't a problem since most lights are far away from the lockers, but on some levels like command2 the mapper specifically put small brush lights in front of the lockers to help make them more visible, and they just don't work. At least, not in a visually coherent manner.

I think I know what's going on here: and it can be solved with adding more polygons.

Basically the vertices being lit up are not within reach or influenced by the light, while the nub, being smaller will be lit up by that light because those vertices are being influenced enough.

[67e88a4c37e96ZylonBane]

Aaaaahhhh it's the damn smoothing groups. Since the default smoothing threshold is 120 degrees, even the perfectly boxy shape of this thing doesn't force a smoothing crease, so the unlit sides drag down the illumination of the front. Changing the side material to flat shaded fixes it.

@Olfred if you haven't left yet, please re-export your original 2014 locker.bin and lockerb.bin with the "grey" material set to flat shaded and nothing else changed.

[67e88a4c37fedOlfred]

I made the box itself with sharp edges, and where the front thing meets the faceplate there is a sharp edge as well.

[67e88a4c381f5ZylonBane]

On the left is the model you just posted. On the right is the vanilla locker model, converted to E, all materials except LOKER changed to flat-shaded, then converted back to BSP. That version lights correctly, but isn't usable for SCP because it's missing the custom bounding box.

If I had to guess I'd say the Gouraud-shaded sides on your revision are somehow still clawing away brightness from the front even though there's a hard crease, but I don't really know.

[67e88a4c38354Olfred]

With the exporter I can't control if it's flat or gouraud. At least as far as I know. So I created sharp edges which should in theory behave like flat shaded. But this is the Dark engine we're talking about.
I set the front plate and the grey box to flat in Blender. Maybe it will export differently.

[67e88a4c38567ZylonBane]

Hold, up, frick, I messed something up with testing the previous model. What you did DID fix it!

If you could do what you did to this model to your lockerb model, that should be enough for now.

[67e88a4c386b6Olfred]

So should I do the thing I did with the last, or with the previous one?
And if I only need to do that, and not all the other (complicated) stuff, I can squeeze it in there.
Good eye with spotting it was a shading issue 

[67e88a4c38867eldrone]

It's essentially a falloff and vertex lighting issue when it comes to very small lights.

some vertices are outside the range of influence of that light, or might have their normal pointing out in the wrong direction.

Meanwhile the center of the surface has no vertex, so there's nothing to be lit, but this is for example while the nubbin' gets lit up, it has a bunch of vertices small enough to be inside the center of the thing.

Another case where per pixel lighting would've solved the issue.


But like with everything in original ss2, the other issue that the object is essentially a rounded box, not a perfectly cubic shape, which by splitting up edges and making every side its own polygon makes the normals be flat instead of gourad.

[67e88a4c389e9eldrone]

An example:

The light trying to hit that vertex will have a normal that is essentially perpendicular to the light, the angle is not correct for it to be lit up, so it wont.

But by splitting the edges suddenly this vertex has a normal that makes more sense to be lit up, and will be lit up more correctly.

[67e88a4c38e62ZylonBane]

So should I do the thing I did with the last, or with the previous one?

The one before the most recent one. Uh, this one: https://www.systemshock.org/index.php?topic=5970.msg158107#msg158107

[67e88a4c38fb2Olfred]

Did the lockerb the same way now.
(I included the locker.bin for completeness/archiving sake, no need to copy it again)