SS2 list of broken and lowpoly objects that need fixing

[673447f75d2efZylonBane]

I'll throw the SHTUP model into the SCP model folder. All it does is fix the side texturing.

[673447f75d488voodoo47]

if that's the case, no fixed model is necessary. edited.

[673447f75d985Olfred]

I'll throw the SHTUP model into the SCP model folder. All it does is fix the side texturing.

That's what I was thought when you mentioned it was fixed, hence the suggestion to throw it into SCP.
As I haven't taken a look at it I thought there might a an upgraded version as to what voodoo47 said.

So I've made a fixed version based on the original model, you might as well take a look at it, maybe it's better than what you guys already have since I made some modifications on the model as well, not just the texture bug at the side.

About the pipes, it's not really pretty how I sealed them off, but I don't think it's necessary to look and throw in another texture just for this.

And I am rather busy at the moment, so I would like you to also update the list in the first post as well, else I might miss out on something.

[673447f75db0dvoodoo47]

thanks. and yeah, I will go through the first post and make sure everything is up to date.

[673447f75dcd4ZylonBane]

I've noticed that not only are the turret corpses vertically shifted compared to the undamaged turrets, they also have a slight horizontal shift. And, Irrational textured them wrong. Instead of using both the damage textures that the artists created, they only used one and tiled it, so all turrets sprout new text on one side when destroyed.

tu_sdam.bin should use tu_shelb.pcx and tu_she2b.pcx (currently unused).
tu_ldam.bin should use tu_lshb.pcx and tu_ls2b.pcx (currently unused).
tu_fdam.bin should use tu_fshb.pcx and tu_fs2b.pcx (currently unused).

You can tell these damage textures weren't used anywhere, because they have a completely different palette from the other turret textures, and have palette #0 transparency issues. tu_she2b.pcx will also need its text mirrored (it's not legible on the other two). I can take care of all this.

[673447f75ddecOlfred]

The texture thing already bothered me the first time I fixed them, didn't know they already had matching textures.

please test
Or do you also want me to make them "taller"?

[673447f75df14ZylonBane]

Texturing and horizontal alignment looks perfect. If you can make the shorter damaged turret appear in the same place as the regular turret when they're swapped, that would be even better. If not, there are a couple of things I could do. Either way, it needs to appear shifted down by 0.9864 game units.

[673447f75e00eOlfred]

Well, I will try out to do something about that, but can't guarentee it.

But should I make the bottom of the model match the original one, or should it stay like it is now?

[673447f75e0e7ZylonBane]

Hold on... trying something...

[673447f75e1d4ZylonBane]

Okay, trying to translate it with a BINTOE/BSP round trip didn't work. Object got totally mangled.

Bottom is fine. It'll never be seen anyway.

[673447f75e4a5Olfred]

Bottom is fine. It'll never been seen anyway.

I was talking about the bottom part of the turret.
Like in the attached tu_fdam2.bin, I can make it taller to match the "alive" turret.

I tried to jiggle a little bit around with the model but couldn't get to a pure model only fix.
Either you use the model which I already posted, but somehow make the corpse spawn with an offset. (But I doubt that is possible)

Or you can take the model I attached on this, which makes it spawn at the right position, but does have a fucked up physical dymension.
So what I did was go to "Blast Turret Corpse (-1421)" in the Object Hirarchy and added "Physics/Dimension" to it. Then changed the "Offset 1" Z to "-0.989845" (yes, this number, it's calculated).
Now it spawns at the right place.
But I don't know if this lies in the capabilities of your DML editing or not.

[673447f75e87dZylonBane]

I was talking about the bottom part of the turret.

Ah, the lower part. I thought they already matched. Well, if they don't match 100% that's fine, it did just blow up.

No DMLs will be involved, at least not with SCP. We can take care of all that at the gamesys level. There is an easy way to spawn an object with a specific offset from the parent object, that doesn't require messing with physics params. So I think that will be the best way to go. If you could do for the other two turret corpses what you did here, that should give me everything I need (for the turret corpses).

In the future, when I have time to start working on SHTUP again, I may be requesting from you some upgraded turret models where the top isn't just a couple of stretched-out texels, and with an actual cavity in the turret for the mechanism to sink into when it's closed.

[673447f75e991voodoo47]

yeah, but should the new turret corpses be part of the fixed objects pack, they will have to be drop in replacements, as dmls do not work when physics are involved and having a custom gamesys is not an option.

[673447f75eaf1ZylonBane]

Right now, SCP is my number one priority. Even if these new corpses still "bounce" when spawned with a vanilla gamesys, at least they'll have better texturing.

Hmm... looking at the normal-to-destroyed transition, now that the model doesn't shift it can be seen that they squished the texture down a bit on the destroyed version. I'm guessing they did this so the blacked-out parts of the texture would match where the damage was modeled. Not sure if it would be a good idea to correct this or not.

https://www.youtube.com/watch?v=ACoLdjsh7mc

[673447f75edb9Olfred]

Hmm... looking at the normal-to-destroyed transition, now that the model doesn't shift it can be seen that they squished the texture down a bit on the destroyed version. I'm guessing they did this so the blacked-out parts of the texture would match where the damage was modeled. Not sure if it would be a good idea to correct this or not.

It's just because they squished the whole lower part of the turret. When you make it taller, it looks better.

But apart from this, the "new" texture on the side still doesn't fully match the undamaged one.

[673447f75f074ZylonBane]

It's just because they squished the whole lower part of the turret. When you make it taller, it looks better.

Okay, let's try that.

But apart from this, the "new" texture on the side still doesn't fully match the undamaged one.

That's fine. It matches it an order of magnitude better than it did before, and it can be made to match perfectly by editing the texture.

[673447f75f56bOlfred]

yeah, but should the new turret corpses be part of the fixed objects pack, they will have to be drop in replacements, as dmls do not work when physics are involved and having a custom gamesys is not an option.

It's still the same behaviour than the old model, just the model itself shifted it position a bit and inside SCP it won't jump anymore.
ZylonBane, can you tell me what you did so it spawns with an offset?

And I kinda bugged my original source file, so I had to redo some part of it. Sorry guys, but you have to test again.
Also made a tu_fdam2.bin which is with a taller lower part of the model, so it matches the alive model a bit better (still a bit smaller, but not as significant as before, and this reduces the texture stretch).

Tell me which one you want for the final models.

In the future, when I have time to start working on SHTUP again, I may be requesting from you some upgraded turret models where the top isn't just a couple of stretched-out texels, and with an actual cavity in the turret for the mechanism to sink into when it's closed.

I already have a high res turret model, I even posted a picture of it somewhere on here.
But that would need a complete new retexturing.


EDIT:
Also something completely different.
I was further looking into fixing the alpha sorting thing on the railings.
It happens when you enable the "Tranparency Alpha" on a model, no matter if it does even have transparency or not.
Now when you simply delete the "Transparency Alpha" from the object it doesn't bug out anymore. But now you get the problem with stuff not getting rendered through the transparent parts.
But here's the catch, if you use a png with transparency now it does render other objects without a problem as long as they don't have any "Transparency Alpha" set.

So one would simply need to create appropriate models and textures for everything with transparency alpha set on it (yay, fun).

[673447f75fa81ZylonBane]

ZylonBane, can you tell me what you did so it spawns with an offset?

Instead of spawning with a Corpse link, spawned with a Flinderize link, which among other things allows specifying an X/Y/Z offset from the parent.

Also something completely different.

What you're exploring is a classic problem with all 3D engines. As long as you're drawing nothing but opaque objects, a simple Z-buffer works great for ensuring that everything is drawn at the correct depth. But as soon as transparent objects enter the picture, the Z-buffer alone isn't adequate, because you can draw a pixel, but still want to draw additional pixels "behind" it. In these situations, you have to use per-object depth sorting to determine the correct order to draw things. In Dark, you tell it that an object needs to be depth-sorted by giving it the Transparency property. As you discovered, it will still draw textures with transparency specified at the texture level... BUT, the engine doesn't know it's dealing with a transparent object, so it only uses the Z-buffer, and it basically becomes unpredictable whether objects behind the transparent region will be rendered or not. It has nothing to do with whether the other objects have Transparency or not.

[673447f75fb7fZylonBane]

tu_fdam2.bin looks good.

[673447f75fd1bOlfred]

Apparently the NewDark Devs have build in something which checks if a texture does have an alpha channel and therefore the engine knows it's transparent.
One would assume that they just pass this information on and kinda quirk it together with the alpha transparency. But strangley enough, they don't, it uses some kind of it's own transparency "setting".
So as long as you don't render a model with alpha transparency set and/or translucency set inside the model, it renders just fine.
If you want to test it out, I created two railing models which don't have any translucency settings and made the texture be transparent (It doesn't match the original setting of the glas, I've just thrown in some transparency without looking at the values).

Look at the screenshot. Here I removed the alpha on the railing.
On the left side, alpha is still enabled on the window and it won't get rendered. On the right side I removed the alpha from the window and it get's rendered properly.

[673447f75fe2fvoodoo47]

a quick note - the tacticool shotgun will need to be vhotted as well to stay fully compatible with SCP.

[673447f760035Olfred]

a quick note - the tacticool shotgun will need to be vhotted as well to stay fully compatible with SCP.

I wanted to do this when I know everything was working.

[673447f76033cZylonBane]

So as long as you don't render a model with alpha transparency set and/or translucency set inside the model, it renders just fine.

Olfred, think about what you're saying. If it was possible to render transparent objects correctly without using depth sorting, I'm pretty sure the guys who wrote the engine would know it. You may have found some particular combination of settings and views that seems to look right without depth sorting, but I assure you it's not a robust, general-case solution. You can't trick your way around a fundamental operating principle of 3D renderers.

[673447f76069fnemyax]

You can't trick your way around a fundamental operating principle of 3D renderers.

But you can. You just use a different principle.