SS2 list of broken and lowpoly objects that need fixing

[6736ced859289Olfred]

Well, I could use the OPS10 texture to at least make it look a bit better.
Or if you want any other texture I could do that.

[6736ced8593ebZylonBane]

Yeah... I gotta think about this. I didn't fully realize how messed up they were until after posting them.

[6736ced8595efZylonBane]

Okay, now a real request. I'd like the metal grate models modified so that they actually have some depth. This would improve the visuals in two ways. First, it would make the grates look more like real, physical objects instead of just dimensionless flats. Second, by making the holes in the grates actual holes in the models, it would allow light to pass through them. The lighting engine doesn't understand texture transparency, so currently the only way to handle grate objects is to either set them to completely block light, or not block light at all. Both look weird.

To test how this could look, I built some brushwork to match the overhead grate pattern in one of the medsci1 hallways. This is how it turned out:

Very cool. And here it is with the lightmap resolution doubled:

For the simulated grates, I used a thickness of 0.1 DromEd units, which seemed to fit in well with SS2's chunky BSP aesthetic, without being too chunky.

Attached are the model files and textures. I've included versions of the grate textures with the transparent parts filled in, since the purple pixels would of course play very badly with a true 3D model.
[grates.7z expired]

[6736ced85973bOlfred]

Here's one for testing for now. It's a "quick" one without any polycount optimization, and it also got some sorting issues. But for now test with this one and report back. Oh, and it still uses Rgrate01.* for the texture, will be adressed later as well.

[6736ced859977ZylonBane]

It works!

It does need some tweaking. I'd like the height to be an even 0.1 units. That will make it easier to align with terrain. Also, the holes are a bit larger than the transparency holes. Here's an overlay comparison:

Red is the current model, green is the texture. I'd like the holes to be the same size as on the texture. On this grate the metal strips are already so thin that making them even more thin makes the entire grate look too flimsy.

[6736ced859b31icemann]

The only problem with all of this is that if we start changing the look of the game, will it be the same game after all the changes?

I'd be happy to try it out either way.

[6736ced859cb6JML]

I for one find that the red glow looks super cool and scary and well fitting to that hallway and the game.

[6736ced859e37voodoo47]

this may turn out to be one of the gratest additions to the SCP fixed object set.

sorry, couldn't help myself.

[6736ced85a1b4ZylonBane]

The only problem with all of this is that if we start changing the look of the game, will it be the same game after all the changes?

I see what you're saying, but...

Switching to 32-bit lighting already causes some pretty major changes to the level lighting, although we do try to make sure nothing TOO major slips through.

The light behind grates is almost all low-level ambient stuff, which wouldn't cause any significant change to player visibility when allowed to pass.

In the example area I've been using, I doubled the brightness of the lights to make the effect more apparent. Actual in-game won't be quite so dramatic.

More realistic lighting is better for immersion, even when it's something that you never consciously noticed as wrong before.

If Irrational hadn't taken a resource-saving shortcut when making the grate models, the lighting already would have looked like this.

[6736ced85a294icemann]

Fair enough

[6736ced85a4e6ZylonBane]

...and it also got some sorting issues.

Just so you know, all SS2's grates are in a hierarchy branch that sets them to render as having transparency, which causes them to be poly-sorted when rendering instead of using the z-buffer. These new models would need to be placed under a different branch.

[6736ced85a5caOlfred]

And that means exactly what for me?

[6736ced85a6d5ZylonBane]

If you're testing the new model in-game, there's a good chance of getting sorting issues. If you're using DromEd, you can work around this by removing the Transparency property from Grates (-1327) in the hierarchy. If you're not using DromEd, ummm... Voodoo could probably whip up a DML that would do the same thing.

[6736ced85a7aeOlfred]

I'm using DromEd for testing. All good, and thanks for the clarification.

[6736ced85a996voodoo47]

to make it it simple, transparency should be reserved to 2d objects like decals and plant leaves (and glass windows). using it on 3d, or partially 3d objects may/will cause issues, and should be avoided if possible (it did make your life difficult some time ago when you were trying to fix a bunch of plants, if memory serves).

//T2 trees are a good example - in Dark, you basically can't have a tree object that has a 3d trunk, and 2d leaves set to transparency 1 to get soft edges on the leaves while not causing sorting issues. the only way around this is to split the object into two parts - the 2d part which can have transparency, and the 3d part that can't, as far as I'm aware.

[6736ced85aab8ZylonBane]

If memory serves, the alpha test material property exists specifically to fix this sort of problem. Instead of soft blending transparency edges, which requires polygon sorting, it creates hard edges, so depth can be handled by the Z-buffer. That's how the rendering of SS2's small potted plants was fixed.

[6736ced85abc2voodoo47]

iirc, the final conclusion on trees (and other objects that combine 3d and 2d parts) was that if you want to have transparency based soft edges on the 2d parts, and no issues with the 3d parts, the only way that truly works with no strings attached is to split the object into two (and use transparency only on the 2d stuff).

[6736ced85acaaOlfred]

I was wondering.
Should I even go for a low polycount on the grates or should I stay with the current number for (more poly is better) lighting purposes?

[6736ced85adddZylonBane]

How many polys are we talking about? I haven't looked at the first grate model in VIEW, so I have no idea how poly-heavy it is.

I wouldn't consider making them high-poly for lighting a necessity, since the grates are small, immobile (mostly), and almost always lit from behind... but if the high-poly versions don't hurt the frame rate even when there are five or six of them on the screen at once, why not.

[6736ced85aedaOlfred]

The testing model does have 890 polygons. When I put in some extra work I could cut it down to maybe something between 2/3~1/2 of that.

[6736ced85afb9ZylonBane]

IIRC Voodoo has a low-spec rig he could test it on. No point bringing the poly count down if the engine can handle it.

[6736ced85b0d1voodoo47]

yeah, an atom based hp t5470 thin client with a noname half size ssd duct taped inside. just barely enough to run NewDark SS2 without significant slowdowns as long as the resolution is kept low, so ideal for testing performance impact of additional effects or custom objects (for example, the new SCP ghost stuff is ok, but the improved decontamination shower effects kill FPS almost completely).

[6736ced85b1daOlfred]

Well, then would you please test with the previous mock-up model to verify if I need to keep the count low or not.

[6736ced85b2fdvoodoo47]

running uncapped, vanilla 60FPS when looking at the three medsci1 grates, new model 48FPS. I'd consider this acceptable, but if it can be made less poly without compromising the visuals, I'd say no harm in doing it.

btw, did I mention how much I like that ND runs (and is playable) on everything including the kitchen sink? yes, I see I did, and on multiple occasions. so yeah, I like it a lot, in case anyone was wondering.