New C2 tricks + C1 crush data (Eagle MK4)
User avatar
Toshiba-3 created New C2 tricks + C1 crush data (Eagle MK4) on Thu Apr 21, 2016 8:48 pm
Post
Hi guys,

I know TTR did a C2 version of that car 10 years ago but here it's an exact port of the TDR2000 model extracted with Flummery :sbsmile:

Image

It was done two months ago but I wanted to crush a bug/understand a feature more properly. Looking at the mod again today it seemed like the bug has vanished..? Good.

- main model, shell model, simple model are all compiled into a single DAT file.
- same with materials, all in one.
- all textures can be smashed without the game crashing (just have to remove the impact effects to make it stable apparently).
- I don't know about you but I only finally understood how CAMERA TURN OFF MATERIALS works. You set the materials that are affected by the feature (and update the amount above accordingly) then for each material you can set exception(s), for example the totally smashed glass can be turned on as you see through it.
- it's possible to set full lit textures on cars (here used on rear lights). Just have to use the material identifier of a REG material (here engblowb and engportb from one of the powerups) but use FUNK and/or WAM to set another texture to that material.
- you can customize some elements of the HUD for a car. Just create a 64x48x8 folder in the addon car's folder and duplicate DATA/CARS/64X48X8/eagle3.txt into it and change stuff. New pixelmaps go into DATA/64X48X8/PIXELMAP/tiffrgb. I'm not easy to follow? Just look how it's done with this car :)
- I don't remember why I listed "ACT/DAT identifier problem" on my list anymore. Though I vaguely remember wanting to rename the model identifiers properly (like I do with C1 cars) and C2 not liking that. And thus the model identifiers end with the .ACT extension as usual.
- noticed that the more geometrically dense your bbox is the more solid and tough your car is.
- if you apply a smash on a material and you use that very material as its own shrapnel material, then the effect of shading are doubled or something like that. Makes for a more contrasted look.

I think that's all.

You can download it there: http://rr2000.toshiba-3.com/carmageddon-2 (refresh if you don't see it)
I'll try to put it in C1 later. I'd like to be able to make the detachable parts disappear in C1 upon damage.
Image / carmageddon add-ons at road reaction
User avatar
Pip the pest on Fri Apr 22, 2016 4:14 am
Post
You've raised the game yet again :sbsmile: well done :thumbsup:

Image[/URL]
User avatar
Toshiba-3 on Sat Apr 30, 2016 5:32 pm
Post
Thanks for testing, Pip :sbsmile:
I thought the new little features would get a bit more attention (esp. full lit materials for cars); ah well.

Now here's the same car for Carmageddon 1... with an actual crush data for the main model!
Image

This took time as it was done manually (or rather mentally) but it was a good exercise to verify Jeff and Errol's take on that crush data system. I elaborated the documentation:

Code:
// CRUSH DATA: MAIN MODEL.
0.700000         // DAMAGE MULTIPLIER AKA SOFTNESS FACTOR.
0.150000,0.400000   // \
0.050000         //  \
0.050000         //   > THESE ARE ALWAYS THE SAME. UNKNOWN PURPOSE.
0.000000         //  /
0.000000         // /
12               // TOTAL NUMBER OF TRIGGER (PARENT) VERTICES.
   // BUMPER PART (ID RANGE: #0 -> #29)
   // FRONT RIGHT IMPACT
   11   // TRIGGER VERTEX
      // TWO FOLLOWING LINES ARE RESPECTIVELY THE LOWEST (-X, -Y, -Z) AND HIGHEST (X, Y, Z) ABSOLUTE COORDS.
      // THAT THIS TRIGGER VERTEX CAN MOVE TO (OR TOWARD).
      // THEY ARE TAKEN FROM THE DAT MODEL (NOT IN ACTOR POSITION).
      0.038, -0.0787, -0.397
      0.088, -0.0787, -0.20
      // AND NOW MULTIPLIERS FOR EACH +/- AXIS.
      // MOST EFFECTIVE AXIS TO DEFORM THE PART MAINLY DEFAULT AROUND 0.25~0.3.
      // MAX VALUE ENCOUNTERED SEEMS TO BE 0.45.
      0.0, 0.15, 0.0      // LEFT, TOP, REAR IMPACTS
      0.45, 0.0, 0.15      // RIGHT, BOTTOM, FRONT IMPACTS
      29   // TOTAL NUMBER OF CHILDREN VERTICES THAT FOLLOW THE PARENT TRIGGER VERTEX BEHEAVIOUR. LIST FOLLOWS.
         // FIRST VERTEX IN LIST IS THE ONE WITH THE LOWEST ID.
         // HERE IT'S VERTEX ID#0. THE GAME STARTS COUNTING FROM -1 SO I HAVE TO PUT 1 INSTEAD OF 0 (-1+1=0).
         // IF THE FIRST ID HAD TO BE 165 THEN 166 MUST BE WRITTEN (-1+166=165). YOU GET THE IDEA.
         // !! PAY ATTENTION THAT THE FIRST VERTEX ID MUST NEVER BE ABOVE #254~255 !!
         // THE GAME JUST GOES BACK TO COUNTING FROM -1 AFTER 254~255.
         1   // #0 (-1+1)
            // THE NUMBER THAT FOLLOWS EACH VERTEX ID PROGRESSION
            // DEFINES HOW FAR THIS CHILD VERTEX IS FROM THE PARENT.
            // IT RANGES FROM 0 TO 255. 0 IS CLOSEST AND FOLLOWS THE MOST THE DEFORMATION OF THE PARENT.
            // 255 IS THE FURTHEST AND BARELY DEFORMS LIKE THE PARENT VERTEX.
            64
         // THE SECOND VERTEX ID IN THE LIST IS SIMPLY ENTERED AS A PROGRESSION FROM THE FIRST CHILD.
         // HERE THE SECOND ENTRY IS #1 SO I JUST WRITE 1 AS IT IS #0+1.
         // EX: IF FIRST CHILD IS #47 AND SECOND IS #101, THEN PROGRESSION IS 54.
         // THIS LIST IS VERY ORDERED SO PROGRESSION IS ALMOST ALWAYS 1.
         1   // NEXT VERTEX IS #1, SO +1
            64
         1   // AND FORTH
            128      // FURTHER FROM THE PARENT - THESE NUMBERS DON'T HAVE TO BE POWERS OF 2 BTW.
         1
            128
         1
            64
         1
            64
         1
            64
         1
            64
         1
            64
         1
            64
         1   // #10
            0      // VERY CLOSE TO THE PARENT
         // I DON'T NEED TO LIST #11 AS IT IS THE PARENT VERTEX
         // SO THE PROGRESSION FROM #10 TO #12 IS 2.
         2   // #12
            64
         1
            0
         [...]

For the whole thing, you can check the car's TXT file :swink:
It might induce an error upon quitting the race. The same as the Mini's, no idea what triggers it but it can be ignored.

You can download it at RR2000 yay!

Also the thing I had forgotten about ACT/DAT identifiers in my previous post is the fact C2 formats seem to dismiss the identifier block size d-word which would explain why Harm's script doesn't write them. Apparently C1 doesn't care much either but I'm pretty sure C2 crashed when I tried to add them. Ok that was a boring bit.
Image / carmageddon add-ons at road reaction
User avatar
Deep_Blue on Sun May 01, 2016 4:58 pm
Post
OH HOLY HELL YES! Nice work! :rockon:

Yes, we *need* a generator... Or perhaps an addon to Carmagedit?
***When I die may I be surrounded by scattered chrome and burning gasoline***
User avatar
Harmalarm on Tue May 03, 2016 8:03 am
Post
:cool:

Epic work tosh. Yes we need a generator and I'm more than willing to make one in maxscript. I'll try to work with what you have written here, it seems clear enough for a first try. Coming week will be busy but I'm sure I can make some time next week and start fiddling ;)
Perhaps we can work with an editable_poly modifier on top of the original model. Make the proper damage crush limits by moving the vertices of the car in this modifier. As in the way they could as a maximum when deformed. Then from there compare the original model to the crushed model to calculate the vertex behaviour? Just thinking out loud here, but that seems like the best way to do it right now.

Yes I skip the length identifier block in the exporter, as c2 doesn't use them. Saves me having to calculate them in the first place. But just to be clear, when you added some of them the game crashed? Are you sure you did it right? I think the C2 vanilla cars have proper length identifiers and work just fine.
User avatar
Harmalarm on Tue May 03, 2016 8:22 am
Post
new reply to get your attention:

Let me see if I have this right: You predefine a certain amount of trigger vertices. These are vertices in the outmost positions of the car, like front_left_top, front_left_bottom, mid_right_bottom, mid_right_top, etc.... And from these points you create your crush data sort of like a soft selection in 3ds max?

Or does EACH vertex of the car need it's own crush data for it's neighboring vertices?
User avatar
Toshiba-3 on Wed May 04, 2016 4:34 pm
Post
:moved thread to devWAM as it is more fitting:

Oh you already had all my attention, just had to reply properly.

I'm pretty sure this might be an overal easy job. The way you understood it in your second post is correct. There's a set of trigger vertices, each has its own set of children vertices (usualy located around/near it) and these children will mimic their parent's beheaviour as much as their falloff value let them (the closer to 255 the less they conform). So yes, moving a hundred of trigger vertices within an edit poly modifier and using a specific soft selection to move each trigger vertex and its surrounding childrens sounds good. What I suppose to be the hard task is guessing the vertex IDs properly, especially as they are split and all.

About the identifier lengths I don't remember exactly. Doesn't matter really.
Image / carmageddon add-ons at road reaction
User avatar
Harmalarm on Tue May 10, 2016 2:57 pm
Post
Ok. I will give it a first try tomorrow evening.

I've re-read your first post for the eagle mk4 and noticed you mentioned compiling all models into a single dat file. I was sure we tried this way back and never got it to work, but I guess I must have been mistaken or I did something wrong back then. This is pretty neat.

Same for the custom HUD elements. That's real neat. It overwrites the default stuff when you put it in this custom folder?

What do you mean by more geometrically dense bboxes? More subdivisions?
User avatar
Toshiba-3 on Wed May 11, 2016 6:32 pm
Post
Also keep the first child vertex ID limit in mind, it can't be higher than 254 or 255. Which is pretty constraining.
About HUD, yes using a custom hud text file has priority over the default one without replacing the file which is neat. And it allows you to load pixies from the 64x48x8 folder etc.
And yes, more subdivisions in a BBOX somehow seems to make it thougher.
Image / carmageddon add-ons at road reaction
User avatar
Harmalarm on Thu May 12, 2016 11:49 am
Post
Did a little try yesterday but didn't manage to get far at all. The first hurdle of finding the vertex index has been overcome, but now I'm still figuring out how to make it easier for you and other modders to set the maximum deformation for the trigger vertices. I made a quick try with an editable poly modifier and then making some deformations and comparing them to the original but that didn't get me anywhere yet. I'll have to bend my mind to it a bit more...
User avatar
Harmalarm on Tue May 17, 2016 7:19 pm
Post
I have made a script that will convert your max-vertex selection to carma's vertex indices for fire points etc. This will serve as a basis for the rest of the crush data scripts I hope to make.
I haven't figured out yet how to update on the fly, so it works with a button right now.

Image
Get it here

This script got me thinking about another issue. As we know by now carma cannot have a vertex with two texture vertices, so the game simply draws two vertices in the same place. One for the first face with a certain mapping coordinate, and one for another face with yet another mapping coordinate. So often you will find two vertices in the same place. My latest export script optimized this somewhat, and the script above takes this into account. Still it happens (a lot) that vertices are in the same place. This is the way the game engine works.

So my question is now: If we take a trigger vertex and it happens to share a position with another vertex, do they both need to be processed as trigger vertices, or can I assume one of them is the trigger vertex and the other is a child that follows it 100%? Have you seen this before in the txt files of the original cars of carma1 tosh?


Last edited by Harmalarm on Wed May 18, 2016 2:44 pm, edited 1 time in total.
User avatar
Toshiba-3 on Tue May 17, 2016 7:51 pm
Post
Nice start! :sbsmile:

And that sounds like a question for Errol as he investigated crush points more thoroughly than me: http://www.toxic-ragers.co.uk/news/2011 ... rushville/ but I doubt he remembers anything :grin:
But if you ask me, I'm pretty sure setting the duplicated vertices as 100% childs is the way to go. That's what I did with the Eagle MK4 and it worked nicely.
Image / carmageddon add-ons at road reaction
User avatar
Harmalarm on Wed May 18, 2016 8:17 am
Post
If that is what you did and it worked nicely then I have my answer :swink:
User avatar
QTZ on Thu May 19, 2016 2:19 am
Post
It working, but fixing the car crashing the game (Win 95 version) on race exit (as described by Toshiba-3), so not everything is OK (selecting 'ignore' allow to keep playing, but anyway it stuck after quitting the game).

I hope this project will grow and you will finally find out how to use Crush Data :)
User avatar
Harmalarm on Tue Jul 12, 2016 7:50 pm
Post
Just posting here to let you guys know I have done a little work on the crush-generator for my tools. I can use max's soft selection to figure out which vertices will be affected by the trigger vertices. The rest of the setup is just a bit of a headache at the moment :crazy:

I'm not sure if I quite understand how the progression works in the crushdata. You basically run by all vertices that will deform along the trigger vert, and you make jumps bigger than 1 if they are not subsequent? so for instance, vertex 20 and 25 are influenced by a certain trigger, so between them I make a jump of 5? And then 21-24 are basically uninfluenced by the trigger?

I've seen a couple of 0's in the crush data which means the original cars follow the same trick we discussed earlier, that when trigger vertices share a location with another vertice, the influence becomes 100%, in other words, we give it a 0.
I did however see quite a couple of 255's, which means that vertices that are almost uninfluenced are still being referenced a lot in the original files. That seems a bit weird in my opinion. I mean, they are there a lot...

The game seems to start with an empty crush data entry and then follows with the main model, the car's body? Sometimes there is another empty entry at the end again. How does the game know which model entry it is using? I guess this is also subsequent according to the model order in the dat file.

Thought I'd share those thoughts for now ;)
User avatar
Toshiba-3 on Wed Jul 13, 2016 12:34 pm
Post
Hell Harm, I'm glad you're still on it :)

You basically run by all vertices that will deform along the trigger vert, and you make jumps bigger than 1 if they are not subsequent? so for instance, vertex 20 and 25 are influenced by a certain trigger, so between them I make a jump of 5? And then 21-24 are basically uninfluenced by the trigger?
Correct.

I did however see quite a couple of 255's, which means that vertices that are almost uninfluenced are still being referenced a lot in the original files.
Not sure about this but I guess it is the lowest amount of influence and thus has to be set (it must start somewhere!). As the original crush datas were generated by a tool, I suppose vertices set to 255 must have been close to each other or around the same distance from the trigger vertex and also be the furthest ones. So instead of discarding some of them, as they were selected the tool set them all to 255? Not sure if I make sense here, but it's not important anyway.

There are always three crush data entries: first the simple model, the complex model, then the bonnet model. The bonnet model crush data is often empty. As the simple, complex, bonnet DAT models are respectively loaded as such ; and the crush datas always have the same order, the game doesn't mix them up :)
Image / carmageddon add-ons at road reaction
User avatar
Harmalarm on Wed Jul 13, 2016 2:26 pm
Post
Cool, thanks! Good to know about those 3 crush data entries, that makes sense.
User avatar
Harmalarm on Sun Sep 11, 2016 3:21 pm
Post
Found a little motivation to work on this today, and got the first (though not very sexy) results out of max!
Attachment:
crushdata_1st_attempt.jpg
crushdata_1st_attempt.jpg [ 148.63 KiB | Viewed 1344 times ]

This works by selecting a vertex in max and then generating a crush data based on that selection. It should work on a multi-selection, however, it doesn't' :ssad: I'm still having crashes on certain selections, so I haven't quite ironed out all the issues yet.
But at least we are getting somewhere...
User avatar
Toshiba-3 on Mon Sep 12, 2016 10:58 am
Post
Very nice!! Taking shape there :beer:
And yes, random ingame crashes that seem to happen for no logical reason show that the whole thing isn't as simple as how I broke it down up there in this topic.
Image / carmageddon add-ons at road reaction
User avatar
Harmalarm on Tue Sep 13, 2016 9:49 am
Post
Yeah, I'm afraid so. I will go and study one of the original cars again. Hopefully I can find a solution for the crashes that way.
Pages: 1



Extra information
It is currently Tue Apr 25, 2017 12:27 pm,

Please Register a username.
In total there are 2 users online :: 0 registered, 0 hidden and 2 guests
Users browsing this forum: No registered users and 2 guests
Moderators: coffeycup, Toshiba-3

Powered by phpBB :: Hosted by n3wton :: Molested by goats
CWA Links
Facebook