Page 2 of 2

Re: Carmatools Maxscript Pack [WIP]

Posted: Tue Aug 09, 2016 7:13 pm
by Trent
Uber necro post of destiny.

In the interest of simplifying porting C1 and SP tracks and cars to C:R I decided to modify your DAT import script script to add support for C1's file structure for loading cars and levels, including parsing a portion of the respective TXT files to get all the MAT/PIX/DAT/ACT files associated with the level and car as they're not always the same as the DAT file names.

Still got to finish off the car TXT parsing but levels are working. The only prerequisites are having the pix files extracted to data\pixelmap\[pix_filename\ (as Trixx does) and have the TXT files decoded with iwanttofiddle, other than that it's a one click operation without having to rejig folder structures or rename anything.


If anyone is interested and its cool with Harmalarm I will release the modded script when I've finished parsing the car TXT files :smile:

Re: Carmatools Maxscript Pack [WIP]

Posted: Wed Aug 10, 2016 4:52 pm
by Harmalarm
Oh sweet man, nice work. No problem with releasing it. I'm glad you made the time to improve it. It's also a well needed addition and I think Toshiba will be very happy with it.
The exporter already had some changes to fit c1's need, but I never checked it with tracks. I haven't done any work on the scriptpack in a long time to be honest.
Nice work trent. Very motivating also ;)

Re: Carmatools Maxscript Pack [WIP]

Posted: Thu Aug 11, 2016 10:06 am
by Toshiba-3

Re: Carmatools Maxscript Pack [WIP]

Posted: Fri Aug 12, 2016 7:54 am
by Trent
Thanks! I've learnt a bit more from your scripts after hacking around with them, such as how to keep 3DSMax alive and support progress bars during big operations like imports and exports and some ways of making my own scripts more optimized. Tosh has been a big help with explaining how C1 stuff is structured!

It mostly seems to be working now, it seems the ACT file of NEWANNIE seems to be causing some issues with it trying to parent one of the pivot points to itself, so I'll need to look into that but hopefully I'll have it sorted out to release today or tomorrow. Turns out the issue was with the DAT file not having 8 bytes of 0 after the HAWKWHL entry so rather than creating the model for that part, it just moved straight on to HAWKWHR, so when it came to sorting out the ACT file it couldn't find the model, so m was still set to the flpivot when it tried to parent to flpivot. Fixed that up now, if it hits a second name block it rewinds by 8 bytes, sets the chunk to 0 and continues as normal. Ill try to tidy it up to release tomorrow :)

Here's big old renders of all the cars and environments because posts need pictures! (edit: added thumbnails, click for huge versions!)

Question: When the ACT is imported what's the reason for the way it uses groups? I've not used groups before but it seems to be setting every parent node to be a group head and every child node to be a group member, but it doesn't actually define a new group for any of them to be part of and leaves it open? From what I've read the way to use groups is to collect an array of objects and create a group like so:

Code: Select all

group objArray name:"MyNewGroup"
Which would give you a closed group which contains all the objects as if it was a single object. Obviously if there's a reason for doing it then that's cool, but it makes the import procedure a lot slower for seemingly little benefit. I am now thinking of making use of groups for accessories in C:R levels in my scripts, though, as they seem like an ideal use for them.

Re: Carmatools Maxscript Pack [WIP]

Posted: Fri Aug 12, 2016 5:02 pm
by Harmalarm
When the ACT is imported what's the reason for the way it uses groups?
The sole reason for them is that they act as null nodes in the hierarchy. Pivot's of car wheels that should rotate the wheel when steering sometimes lack a model, but do have an act entry for rotation purposes. The group will act as that actor.
For tracks the groups are part of the bigger hierarchy for preprocessed tracks. Again these are null nodes, so no models but still actor entries. They contain the subparts of the track in the form of a tree diagram. Oh and the groups represent the dimensions of the track parts and where what will be rendered.

Perhaps there are faster ways to work with groups. I think I add objects to groups one by one, and yeah, that is much slower than the way you suggest. I'm sure that can be optimized.

Via maxscript you can do all kinds of tricks with groups, and you can totally wreck your scene. Objects can be turned into groupheads, objects can be children of groups but not be a real groupmember, objects can be groupmembers with a deleted grouphead so they remain members, unless you fix it by scripting. That sort of junk. Basically groups are quite dirty in max if you don't use them right.

If you are going to use groups, be aware that the group representation is a helper object, and when you have a lot of those on screen the fps will drop dramatically. Another thing that Autodesk should work on. For some reason, even though the helper objects are super simple to render, many of them will have a big impact on your navigation in the viewport. Then again, maybe they fixed this without me knowing it.

And nice post man, love those pictures. ;)

EDIT: after re-reading your question I think I should also clarify that child/parent behaviour is a bit different from grouphead/groupmember behaviour. I'm sure if you check out the help files you will find what you need, but setting an objects as a child of the grouphead isn't enought. You should really make it a groupmember to make it work properly.
Funny thing is that objects within a group are referred to as group.children, so I guess the guys at autodesk were a bit confused themselves... :)

Re: Carmatools Maxscript Pack [WIP]

Posted: Sun Aug 14, 2016 7:08 pm
by Trent
Thanks for the details, it's been a big help understanding how groups work! I found the 3dsmax docs on groups seems a bit vague on the details of their use. After posting that question I realised the grouping happens even if the hierarchy is disabled so that would make it a lot more logical. The speed also isn't too bad on a single import, I think the main reason I was seeing such drastic slowdowns was due to importing so many levels at once. It seems to be a bit of an exponential slow down as more objects get loaded in, possibly due to the helper objects slowing things down.

Speaking of helper objects and their performance in the view ports, that's still an issue. I made a scripted helper plugin for handling route paths in C:R levels with each node and link being a helper, obviously this is a LOT of objects and it slowed the program down like hell. The reason for this is, at least with scripted plugins, SimpleObjects call have a BuildMesh event which builds it's mesh and then stores it in a Mesh property which is used for drawing it and only calls BuildMesh when necessary, while Helper objects just call the GetDisplayMesh event every time it needs to be drawn, so even if you set it to cache the mesh it still calls the event on every helper and runs through the logic for checking if the mesh needs rebuilding or not. I guess even just doing a simple check if properties have changed or not on hundreds of objects every frame is quite slow in MaxScript's single threaded environment.

Anyway, I didn't manage to finish tidying up my ugly code on Friday, but I did manage to sort a couple of things out like adding an option for disabling groups (default to on to retain the old behaviour but allows the option for disabling for quicker import). I had added a second button for loading C1 models via the TXT file but I think I'll change it so there's one button which gives a dialog with options to select either DAT or TXT.

Re: Carmatools Maxscript Pack [WIP]

Posted: Sun Aug 14, 2016 8:29 pm
by Harmalarm
That part about the helper objects makes perfect sense now, thanks. Also, importing many tracks instead of just one will definitely be the cause of the slowdown. It might be because I use 'getnodebyname' calls and those only get slower with a bigger node pool. But in general Max just gets slower and slower with more nodes in scene. At work we often collapse many objects into single big meshes just to make navigation do-able with our clients arechitectural models.

Oh and my exporter also uses the groups for putting everything back in place on an export. So you can import cars and tracks, do a couple of changes, and then export the whole thing back to the game. (never tested for cars though)

Interesting plans there. Looking forward to testing it on some models

Re: Carmatools Maxscript Pack [WIP]

Posted: Sun Aug 14, 2016 9:53 pm
by Trent
Yeah, with it set to use groups it took hours to import less than half of them and the computer crashed during the night so I've got no idea how long it would have taken to do them all. However, just commenting out the set group member and set group head commands made it import all the levels in like half hour or so with full hierarchy, so it was a really major difference. 3DSMax was handling the scene with all of them loaded really well and was still pretty responsive.

Ahh I've not touched the exporter code, only the importer. I probably should take a look to make sure I'm not breaking anything with it!

Re: Carmatools Maxscript Pack [WIP]

Posted: Wed Dec 21, 2016 10:44 am
by Pip the pest

Dear SantaTosh or SantaHarm,

I would really like for Christmas this year a tutorial on how to use these scripts which I imagine are really easy to use for most people except for me.

I got myself a version of 3ds max 2015, and Harms scripts as Plaything2 no longer wishes to work on my computer ( Including reinstall of windows8.1) And so far I have lost most of my hair.
When I exported first time from Max to C2 I got "Cannot find main body" now i have another

So if it is possible a quick guide to how everything works would be really appreciated :smile:

Thanks Santa's

Re: Carmatools Maxscript Pack [WIP]

Posted: Wed Dec 21, 2016 11:54 am
by Harmalarm
Ho Ho Ho, hello there Pip.

I understand you are already exporting models from max. I know I claim that Plaything2 is not needed anymore, and in theory this is true. However, PT2 can still be a good tool for checking your model in a fast way. So can you send me the files so I can check them here in PT2? (I still find it strange that PT2 is not working for you :sad: )

The error you are getting is material, or material reference related I think. Not much more to deduce from here. Can you therefore also send me the max files so I can have a quick look and see what is going wrong?

I have to admit, the tools were originally made for track making. In a later stage I added car-exporting and I think I made a total number of 2 cars with it. Tosh however is using it all of the time now.

Re: Carmatools Maxscript Pack [WIP]

Posted: Wed Dec 21, 2016 6:57 pm
by Toshiba-3
I can try putting a quick basic guide with pictures together after christmas. I use the scripts on a quasi daily basis, it is a godsend.

Most important basic things from the top of my head:
- Basic hierarchy with the main component as its top parent and everything else its childs.
- Properly naming components (not exaggerately long, no space, etc.)
- Every component (esp. main component) must have its pivot on 0,0,0 (but groovy ones/wheels). (via hierarchy tab > affect pivot only)
- All components must have an UVW map (even planar) and at least one material (even textureless).
- If you rotated, scaled any mesh, it's better to apply Reset XForm (from the utilities tab) on them before doing the hierarchy (save before applying that modifier though, just in case).
- Parent dummies are generated by grouping the child on its own, then 'opening' the group. You can then move the pivot of the dummy or even transform it if you want to achieve an angled groove more easily. Example: having the steering wheel straight horizontal, grouping it, opening its group, selecting this new parent dummy and rotating it to also rotate its child (the steering wheel mesh) in proper place, applying the groove on the child (the stwheel mesh) (applying it on the dummy would reset the rotation).
Another example: placing the four wheels in place, grouping the front left one (already named FLWHEEL.ACT uh) on its own, naming the group FLPIVOT.ACT, opening it. Making sure the pivot is a child of the main component (it should be if the wheel itself was already a child). Doing the same for the front right wheel.

I might be mistaken as I've not seen this in ages but I find it odd how the error message halts at the car folder and doesn't mention a pix file. Maybe there's a space (or invalid character) in the main identifier, car name, or within a material identifier? Might also be the way that generic error is shout out though.
Could you also double-check that no texture has a filename longer than 14 char?

Re: Carmatools Maxscript Pack [WIP]

Posted: Thu Dec 22, 2016 6:07 am
by Pip the pest
Hi Santa's,

Thank you both for the quick response and trying to help me. "Harm" Yes being without Plaything 2 is a real pain in the backside but as I said even after reinstalling windows I still get the same message " A Problem Caused The Program To Stop Working Correctly. Windows Will Close The Program And Notify You If A Solution Is Available" :supercrazy:

"Tosh" Thanks for the guidelines, but I look forward to your guide with pics :thumbsup:

Anyway Merry Christmas and a Happy New Year to you both and all who still pops by CWA and devWAM :smile:

Re: Carmatools Maxscript Pack [WIP]

Posted: Sun May 24, 2020 10:43 am
by Toshiba-3
Bumping this thread as I believe it'd be nice to keep it up to date now and then. Discord is nice but when you think about it, despite the log discussions posted in there slowly get lost in time.

After being seriously confused with a handful of models, I figured the importer stumbles upon certain multimaterials. I know you're in the process of rewriting it but I thought I'd brought it up nonetheless just in case. A simple way to expose the issue: use the import script from either 2019 or 2020 CarmaTools releases to load the Supstucka in 3dsMax, you'll notice the following errors:
Annotation 2020-05-24 123750.png
No idea what's going on, I kinda shudder at the idea that I might have generated errors with many ports and mods because of this. Especially the Eagle3 for the GOG/Steam release :slol: (I doubt it though as I spent a lot of time fixing it all around).

Re: Carmatools Maxscript Pack [WIP]

Posted: Sun May 24, 2020 12:20 pm
by Harmalarm
Ok, this is quite bizarre as I have run into a similar issue with the new importer just yesterday. :eek: I noticed that some DAT models seem to have an unequal number of faces vs material id's, and when they don't match up I used to hard code the material id of those faces to be set to 1.

It seems there are some default cars that suffer from this, for example this one.

I would not be too afraid of all your mods being faulty. The exporter is it's own thing. I've never seen or noticed any issues of models coming out of max. Issues would only apply to imported cars that were modified and then re-exported back to the game, like your eagle for the Gog release maybe.
And remember, if your keen eye didn't see potential issues, then nobody else's will ;)

But I will investigate this and hopefully figure out what causes it. Thanks for the heads-up. I think it is true what you say that this thread is a better idea than posting on Discord. This will keep things on the radar and keep it manageable.

Re: Carmatools Maxscript Pack [WIP]

Posted: Mon May 25, 2020 9:45 am
by Harmalarm
So, another interesting notion:

The Junker, aka Supstucka, has a lot of material pointers in the ACT file, which I didn't use in the old importer. That's totally on me.
However, in the new importer I treat these actor materials as overrides for the ones in the dat file, and that leads to different problems...
So after further inspection, the game knows which part of a model should be using the ACT materials, and which part should be using the DAT materials.

For instance, the bomb at the bottom:
DAT file is pointing to material JKBFIN. (tail part of the bomb)
ACT file is pointing to material JKBOMB. (front part of the bomb)

Turns out, or so it seems right now, that the ACT materials needs to be ADDED or IN FRONT OF the DAT material in order for it to work. So instead of treating it as an override, I add it to the multimaterial of the objects, and voila, all looking good!
Act materials are always using face-Id's 0. Now as Carmageddon points to face-Ids from 0 up, 3dsMax works from 1 up. So when importing the 0 face id's from the games models, max converts these to Id 65535. (highest possible integer from a short) This is actually quite handy, because then we know which faces are pointing to the actor materials and which faces are pointing to the dat materials.

Hope that all makes sense to you guys, but at least it does to me ;)