673faf4c34676

673faf4c3550a
7 Guests are here.
 

673faf4c35e59ZylonBane

673faf4c35ec2
Sorry for the delay. My computer broke down and had to get a new one plus some added unforeseen consequences added to the mix which just delayed about everthing that is important.

For now I just did one window. Tell me if this does fix the problems or if they still persist.
[tramcar_window_1.bin expired]
Getting back to the issue that we were discussing, uhh... three years ago  :omg: , I needed to verify that making the tram windows individual properly-centered objects did indeed fix the alpha sorting issue. I've just conducted an experiment where I took your windowless tram model, then attached a couple of standard window objects to it in place of its windows (since I've apparently misplaced the file you posted back then). I'm happy to report, success! Allowing the engine to z-sort the windows individually instead of as the single massive tram object provides glitch-free rendering, as illustrated below...

Vanilla:
https://www.youtube.com/watch?v=RhTeLjjWjDI

Windowless tram with attached windows:
https://www.youtube.com/watch?v=3-4IkGMuw5M

So, would it be possible to  get centered versions of tramcar_w_1/2/3/4.bin some time in the next... three weeks?
673faf4c3616b
I don't exactly know at what state we were. But this are the old files I could find.
[tramcar.zip expired]

673faf4c3625eZylonBane

673faf4c362ab
Thanks. Yeah, those are the window models where they still have the bounding box of the entire tram car, so the engine tries to z-sort them as if that was their actual size.


673faf4c36383
So, you want the windows without the bounding box?

673faf4c36452ZylonBane

673faf4c3649d
Well, they have to have a bounding box or the engine won't know how to z-sort them correctly. They just need to be like any other Dark Engine object model-- centered within themselves, and with a bounding box that includes only their visible polygons. Doesn't Nemyax's converter do all that stuff automatically?

Like, when you did the crew cap model that you cut out of a larger model, that came out perfectly.
673faf4c3656e
check windows 2-4, is that what you want?

673faf4c36692ZylonBane

673faf4c36719
Hmm. The other three models are better, but still not usable as-is. Their bounding boxes appear to be centered and the correct size, but the polygons are still in their positions from the original tram car model.





In both these screenshots the 0, 0, 0 point for the model is the center of the displayed bounding box.
673faf4c36863
That's because nemyax and I found out a way to cheat the engine and basically do stuff that wasn't intended. It looks like this in the editor. But once you are ingame, it is displayed correctly.
I used this on a few models to correct wonky looking brackets (those ingame brackets you get when you look at interactables)

673faf4c3692fZylonBane

673faf4c3697b
With these models, the visible part displays in the offset location both in game mode and the editor. If this was for some decorative prop stuck on a wall somewhere it might be fine, but we're specifically trying to fix a z-sorting issue here, so it's important to give the engine the most well-formed data we can. No tricks or cheats.
673faf4c36a74
Well in that case I can't make the windows have a location centered to the tram, but be centered in their "mass" so to say.
What this would entail is to align the window by hand to match the tram.

673faf4c36ba2ZylonBane

673faf4c36bf0
Yes, that's what I've been requesting this entire time-- the windows as independent self-centered objects, so the engine can z-sort them as independent self-centered objects. When a model's polygons aren't aligned with its bounding box, it's essentially lying to the sort algorithm, which would result in the same glitchy sorting we're tying to fix by doing this.

The necessity to manually align the windows with the tram model was always part of the plan.
673faf4c36d17
offsets in xyz (probably, I don't know how to test it in ShockEd)
1: 0.303389, -9.952996, 0.686576
2: -2.801378, -5.922553, 0.625504
3: -2.801377, 5.922554, 0.625502
4:  0.294966, 9.954241, 0.685729

[tramcar individual origin.zip expired]

673faf4c36dd5ZylonBane

673faf4c36e20
Almost there. I have the windows positioned within the tram and attached and it works great, no more z-sorting errors.

Last thing to take care of is an issue with the tram model. When the windowless version was exported back in 2019, apparently it was without gouraud shading, so it has some odd lighting artifacts in-game.
673faf4c36efa
is this better?
[tramcar_no_w.bin expired]

673faf4c37113ZylonBane

673faf4c37164
Not quite. It looks like it's not using the same smoothing group thresholds as the original model. Possibly the lighting normals might be messed up as well.

Here's are some comparison shots. Bop between tabs to see all the differences.
Vanilla: https://i.imgur.com/ermjEAC.jpg
2013 fix: https://i.imgur.com/4cz9xxr.jpg
Windowless: https://i.imgur.com/ePJOO7E.jpg

The lighting between the vanilla version and your 2013 fix seems consistent, it's just in this version that things have gone wonky. Even more strangely, your 2013 model is 32K, while the new windowless version is only 17K, which seems like a pretty big change for only getting rid of the windows.

I just noticed another issue (with both your old and current tram models). Near the front of the tram on the left side there's some glitchy texturing on the window frame:



Do you remember why the top of the door is sticking out so much in the updated model? I've been looking at this version for so long that I'd forgotten the original wasn't like that.
673faf4c37271
I believe back in the day I was still using another way of importing the model. And the tool gave out incorrect models sometimes.
I'm going to take another look at the model in the next days.
673faf4c378fd
Do you remember why the top of the door is sticking out so much in the updated model? I've been looking at this version for so long that I'd forgotten the original wasn't like that.
According to my 2013 me.
The border around the door was ugly and I changed the geometry a bit to lessen it. Still ugly, but better.
And looking at the original model I can see why. The frame is bend in a weird way on the inside. So I made the 4 surfaces of the frame be flat.
I could alter the frame to be more in line with the old look but without the ugly bend. But that would modify the original model even more and would take a bit to figure out a pretty way.

I fixed the issue with the glitchy texture. It was an error in the UV map.
Check if this model is good now.
[tramcar_no_w.bin expired]

673faf4c379d6ZylonBane

673faf4c37a25
That textured bit looks good now, but the important thing was the lighting, which is still messed up.

https://www.youtube.com/watch?v=xQudgnk5cYU
673faf4c37b2b
Can you give me the map name and coordinates so I know where to jump to?
I just spawned the tram on another map and it looked fine there.

673faf4c37bc9ZylonBane

673faf4c37c1a
It's used on command1.mis. Just a short jog from the elevator to the first tram platform. Tram is object 137, coordinates 950, 20, -40.
673faf4c37d0a
Thank you.

How is this one?
[tramcar_no_w.bin expired]

673faf4c37d93ZylonBane

673faf4c37ddd
Looks good! Thanks, I think we can all this one done.

673faf4c38007Xkilljoy98

  • Company: N/A
673faf4c38062
I don't have an exact list but IK there are a few weapons that still don't have mods for them

IK this is one of them (but not the only one)
https://shodan.fandom.com/wiki/Stasis_Field_Generator

Your name:
This box must be left blank:

A familiar door code with 3 digits:
7 Guests are here.
Its nasty in there. All those fleshy walls.
Contact SMF 2.0.19 | SMF © 2016, Simple Machines | Terms and Policies
FEEP
673faf4c3879f