Page 1 of 1

A bit more of Carmageddoom: whole environment swap

Posted: Mon Jan 25, 2016 3:56 pm
by Toshiba-3
Video description:
Extensively exploiting a texture swap trick, going through the chimney in the Splat Pack castle will change the environment to a Doom-like area. This is just a visual trick as the collisions sadly don't change.

At first I wanted to reproduce this effect seen in Doom: (non-euclidean geometry) but it's very difficult to trigger properly in C1/C2 as the player can always respawn away and break the magic.

Ah well, at least it makes for a little video...
It looks cool, but at the same time it isn't what I was after. So I'm a bit unhappy. I have other ideas to try to replicate correctly (as in: respawning wouldn't break the effect) but it takes a lot of time to test.

Other things I didn't mention, if you pay attention you'll see the car has little flames all around it when it goes through the fireplace. I replaced the watersplash with a fire/expl animation.
If you have a translucid material in a chunk of mesh, other nonsolid materials will share the transparency (annoying, here the pillars shared the transparency of the blood streams).
Because of what I just wrote in parentheses, I turned these pillars in instances. I'm not sure but it seemed to me like they kept both their different sizes (I'm sure on that end uh) but also their solidity (before I applied the ! flag). Very interesting. Must do more tests myess.
I encountered a lot of strange beheaviours with actors, materials etc. as I tested and tested ideas but I forgot how it all went.

But really, I'd like to reproduce the exact same effect as seen in that Doom video. But it would have to be perfect...

Couple of stills:

Re: A bit more of Carmageddoom: whole environment swap

Posted: Mon Jan 25, 2016 4:35 pm
by Harmalarm
Very interesting visual effect there. I almost started to believe you invented teleporting in carmageddon.

So now you are swapping textures via a smash trigger? Wouldn't it be possible to swap models instead?

I believe the collision is variable between instances to a certain extend. I think I tested this before with a little house model. Somewhere in the range of 10% you can safely change the size and the collision goes along. Anything above that and the collision goes wrong. But again, not sure anymore.

Re: A bit more of Carmageddoom: whole environment swap

Posted: Mon Jan 25, 2016 6:17 pm
by Toshiba-3
This is C1 so no smashables. I used funks with lastlap to trigger the change. Just thinking about C2 replacemodel fonction now that you mention it and I think a lot can be achieved with it as well, once again not sure about collision.

It's possible to force the player to teleport back via the !! trigger in materials but you can't choose where the player respawns :tongue:

I'm going to do some simple tests in C1 with these '&' instances.
[edit] Just tested and indeed collision doesn't follow the scaling, too bad!

Re: A bit more of Carmageddoom: whole environment swap

Posted: Tue Jan 26, 2016 10:12 am
by Harmalarm
Yes I wonder if the collision will be updated when switching models using the replacemodel function of funks... Perhaps it doesn't work properly as these replacemodel objects are always used as props and not driveable surfaces... but who knows. It's worth a shot.

Re: A bit more of Carmageddoom: whole environment swap

Posted: Thu Jan 28, 2016 1:13 pm
by Toshiba-3
Spent two more days trying to find a way to get that non-euclidean trick working. No luck at all. Actually I noticed how much more primitive C1 physics actually are in comparison to C2 and it's a bit of a bummer... :ssad:

You can't include bboxes into one another (tried to make a chain for example). With that min/max coord defined bounding boxes plus a handful of additional coords, you can't achieve interesting stuff at all. There's no keyword at all like TUMBLE, DRIVEABLE_ON, etc.
Seems like noncars might have crush datas though. Haven't tried yet. Could lead to smashable-like effect if it proves true.

Also C1 seems to have a hard time staying consistent with pivot position within parent-children hierarchy. On that note, Harm, I struggled to try (and failed) to have proper parent-children actors/noncars in C1 via your script. The children would always appear at the track's origin (plus the initial offset from its parent's origin) in PT2 and then C1. Inserting a child via PT2's function worked however. I don't know, maybe I did something wrong. I heavily rely on hierarchy when I make cars so I don't know what went wrong here or if it can even be compared to what I do with cars.

Played a lot with grooves as well and here I noticed something very nice IMO. The two trigger values 'constant' and 'distance' are a bit misleading (or at least *I* have been misled). I always expected 'constant' to do its job and make the actor move constantly no matter the distance from it. And well 'distance' was supposed to animate the actor only when you were approaching it closely.
Well when it comes to visual animation it's the opposite. Sure 'constant' makes the game keep track of the state of the animation constantly while 'distance' will only resume processing the animation once it's in view. But 'constant' also displays the animation at a very short distance, something like 5 or 5.5 BRU, 'distance' triggers the animation as soon as the actor is drawn (which can be 35 BRU by default, or more if you increased the YON).
This 'constant' anim display distance is awesome. By the way, it's the distance between the camera and the actor's pivot. Using the 'flash' movement attribute with -1 as cycle-per-second, it's possible to make solid assets pop up in front of you or behind you. Disappear too. (It's also possible to make objects teleport via 'straight' path I think, by completing the three coordinates of the movement offset)

Example: imagine a tunnel leading to a small arena with the Suppressor, as you advance toward the room you don't realise you pass over a fence as it's hidden above the ceiling. However its pivot is placed much further along the tunnel (like 7 BRU further) and approaching that pivot triggers the groove which places the fence in the tunnel and blocks the escape (as collisions are updated), you're trapped! End.

Ah yes, noticed as well that scaled-up/down noncars regain their original size once triggered (both C1/C2). Can be useful for creative effects too.

Re: A bit more of Carmageddoom: whole environment swap

Posted: Fri Jan 29, 2016 1:04 pm
by Harmalarm
Hm, I would have to look into the parent-children hierarchy stuff then. As far as I know it works in carma2, as I have tested this feature, but perhaps things are different in carma1. I assume you set the export switch to track, and not to car?

I always forget the exact differences but from my experience c1 cars are more picky when it comes to the pivots of the wheel positions and such. The confusing thing is that the wheel positions are described in the txt files and in the models by their pivot. C1 gives priority to the models pivots, C2 to the txt file's given position... OR it's the other way around :confused: And each time I work on this I seem to fix it for one case, and break it for the other... And on top of that pivots for models in tracks seem to be working yet in another way, especially with parenting stuff!

I dove into the scripts again yesterday evening, and hope to do so in the coming days to get to the bottom of this once and for all. I will simply take a c1 and a c2 car and compare them and I will assume pt2 sets all pivots correctly for track models, so that should help me.

Interesting find about the 'constant' keyword. I didn't know it could pop up solid models this way.