UPDATE
- Last version now contains a proper optimizing of exported models, the same way plaything does it by merging nearby vertices that have similar uv data. Saves a bit of file size.

Download history

WIP release nr7 - 2015_01_29 - Model optimization integrated into the exporter.
WIP release nr5 - 2013_01_31 - lots of changed... it just better, but not done though!
WIP release nr4 - 2012_06_26 - added smashable setup and seperated noncar setup
WIP release nr3 - 2012_04_26 - quick edit. Added log file creation and more
WIP release nr2 - 2012_04_23 - you can setup your car now!
WIP release nr1 - 2012-02_19 - track setup in WIP stage


Changelog:

Changelog:

20180116
- fixed all links to the images and downloads.
- proper last version now deals with optimizing models

20120626

-added the smashable setup tools
-improved the noncar tools, making it seperate
-improved the minimap setup
-improved car WAM setup
-added spline export
-new icons!
-overall cleanup of the tools (code wise)
-fixed lots of small issues

20120426

-errorlog file creation on track tools
-faulty objects will be exported as dummy boxes
-updated the object handling section
-improved progress bar (more precise)

20120423

-added Car setup tool
-added Car export tool
-quick car setup tool added
-added progress bar to track export part
-added group support for track export
-added linked object support up to 4 levels
-optimized code pieces here and there
-hidden objects will not be exported (car and tracktool)
-removed export issues on missing sub-id's (tool can handle them now)
-made new icons!?!


--original post--

Carmatools
- A scriptpack for 3ds max designed to make the life of carma modders easier.

The pack currently contains the track setup and track exporter scripts. With it you do most of the track setup for carmageddon 2 and also export the track directly to ACT, DAT and MAT files, ready to be used by the game.

Unfortunately, preprocessing has not been scripted (yet) so pedestrians and smashables will not work.

The Car setup and Export scripts are still in very early WIP, not ready to be used yet, so they will be released in a later stage.

The scriptpack is compatible with max 2010 and up. First priority for the time being will be to bring back compatablility down to max 8.

Installation

Download latest version

unzip to your main 3ds max install directory. Run the "Carmatools_launcher.ms" via 3ds max. It will install the macro-script. From there, you can add buttons to a custom UI toolbar, found in the Carmatools category.

When the tool launches it will enable you to setup different object settings. The object settings will become part of the objects in max, or in other words, the objects will contain extra properties in the edit mode. The rest is rather self explanatory.

Creating the script has been one big learning experience for me. Off course this is a WIP and it is not flawless. Please report any error you encounter, perhaps with a screenshot, or a brief explanation of the situation. You can place your findings in this very topic.

I have uploaded a quick testtrack for you guys to check out. You can place this in your c2/data/races folder to play with. The max file will explain it all (max2010 file)

Testmap

The future

As I said, I will be focusing on compatibility and finishing the track tools part. After that, I will add proper car setup and export tools. This whole pack will be presented on it's own website, which will contain help files and possible tutorials.

Okay, maybe some images with a brief explanation of the functions will help to get this show on the road!

Main track setup rollout. Here you can set the properties to the global track model, or apply certain properties to specific objects, such as grooves or noncars, or to materials such as funks and pedestrian specifications.



Noncar Properties visible in editmode when applied to a noncar object. Noncars are the physics objects of C2, also knows as tippables by many. Noncars can do a lot more than just tip however...


Groove Properties visible in editmode when applied to a groove object. Grooves are the animated objects in C2. Their physics are not animated, so you cannot use them for funky contraptions.


Actor Render mode properties, which determine how the model wil be rendered ingame, for instance in wireframe mode... :p


Environment box properties. You know, the box in which you can set different gravity, sky color or sounds ;) The env boxes can be places with two mouseclicks. Simply change some variables, and you are done.


Funk properties. Funks are the animated textures in C2. You can make them do all kinds of funky things. You can add Funk properties to a 3ds max material and voila; animated material in C2


Ped Spawn properties. The basics for ped spawning are there. Unfortunately, the script cannot preprocess the track (yet). You can still use this, and do the preprocessing in PT2.


MAX vs PT2:



And last, some comparison and C2 shots:

Am no modder - but Harmalarm you've done an awesome job creating such tool !!

Well done mate

Any updates to the script? :P

And a question about the actor render modes:

One of the render modes is complete invisibility. If you do this for a mesh, does it still tax the frame rate, and can it be collided with?

I was wondering if this could be used to separate visuals and collision, especially if you have a mesh that is both curved and sloped, and should be very, very round, in an already detailed surroundings.

No new releases yet, but still working strong on the pack! ;)

I've been working mainly on the car setup pack last weeks. Apart from the Smashables and funks, our cars can now be setup completely within max. The pack will generate an ACT/DAT/MAT file for the car, it's simple model and shell model. You can export your car's txt, with all the references needed and a Wam file. Both TXT and WAM files are based on the properties you set on the objects within the max file.

I've also added hierarchy support for the car export up to 4 levels. While at it I also fixed some things in the Mat export that I came across. I will put the hierarchy support in the track exporter as well. Still need to add group support though ;)

I hope to have some new downloads ready within the coming week, just to let you guys play with the new stuff I made.

about the render modes. Unfortunately, the invisible render mode also causes the models not to collide... This means they cannot be used in any way actually... I did once create a track boundary using the vertex actor render mode, making sure the vertices were out of sight

the hierarchy is setup with the link buttons in maxscript



in this example I linked box4 to box3, box 3 to box2, box2 to box1. The hierarchy tree will built itself up. It is a drag a drop feature of max. Click the first object, drag the mouse to the second object and release it to make it a parent.

to use empty parent objects for c2, you can use the dummy helper object. The script will recognize it and us it a s an empty parent. And yes, the car setup automatically adds dummies. Basically you set the main car object and the wheels, steerable or not. The script will build the hierarchy based on those selected objects. If you want to add extra wheels, suspensions you can do so in the groovyfunkref section of the script.

BTW, what do you guys think of my new logo's?



first is for the tracktools, second for the cartools. :D

Sounds/looks good. :)

I'd like to mention a few exporting related things:

- Groups handling, but you're aware of this already. :)

The following are about (still easily editable) object types, which do not seem to export well unless manually converted into editable polies:

- Closed splines with "turn to poly" modifier applied (e.g. grass areas of custom shapes).
- Editable polygon objects, that have symmetry modifier(s) applied
- Splines turned into three dimensional meshes with the sweep modifier

All three above will of course export fine when manually converted into editable polygon objects, but that means a few extra steps every time you want to export. I was wondering that if it's not too difficult, would it make sense to make the script handle these kind of cases too? This isn't really a top priority issue at the moment, but what are your thoughts? :)

I'm willing to look into it. Personally I'm a fan of working with editable poly objects and continuously collapsing them to editable poly's during my work process. I can imagine it is useful to not do this if you quickly want to edit a spline sweep for example. I wonder how tricky it is to get it to export properly. In theory the script should already do this properly, but practice proves different :( I will put this at the end of the to-do list though ;)

There are other issues with 3ds max that I came across in the last months. The box object for example. I encountered problems with it before when exporting to GTA-SA. For some reason, 3 of the 6 faces were missing. This seems to be the case again for the C2 exports (even when using ase-->ase2asc-->pt2). :o It makes no sense at all, but it still happens. I think the canopy object you were talking about earlier had this problem... Usually if you edit the box a little, move some vertices and the likes, the problem is gone though.

I feel I should definately release something new next week. I hope to spend some time on the pack tomorrow. Hopefully I can add group support :)

(also see updated post at top)

I have uploaded a new WIP version of the pack. The track exporter will now recognize groups and will export linked objects, up to 4 levels. Missing sub-mat id's are now allowed and the tracktool has a progressbar ;)

WIP cartools included in the pack!

tool is not failproof yet, but there are numerous errors fixed down the line.

The new exporter seems a bit more picky than the older one: I'm now getting the "x undefined" error (not sure yet which object is causing it), which I didn't get with the old exporter. I may have already asked this before, but is it possible to track the object it's trying to process when it faces an obstacle, and mention the object name to the user?

Also, the script now tries to convert cameras. :D

Here's an up-to-date max file (and exported track) if you want to do some testing:

http://c2s.toshiba-3.com/DLoads/MaxBlocks.zip

Sorry about that. I have been fiddling with the object sorting, and apparently forgot to exclude several objects.

I have already done some work on a export error log output. As soon as an object doesn't export properly, the script will output the objects name to the 'trackname_errorlog.txt' and it will export a simple box model as replacement for the faulty object. This way the track will always export, and can always be run, and it will tell you what went wrong.

I will expand this error-log function to do some other helpful things. For instance:
- bitmap-names cannot have more than 14 characters. I can make it so that the script will not inlcude the bitmap as soon as it breaks this rule.
- I can log which objects will be skipped. Hidden objects, helpers, noncar setup objects, collision box object etc.
- As soon as an actor has the invisible actor render mode set I will log that is will not collide.
- ... and more according to what we seem to need

In your track, I noticed the errors occurred on the sewer curves and curb walk curve objects. These objects had a stack of modifiers applied to them, which apparently makes the object unsuitable for export. It caused them to lack certain texture vertices, hence the error.

I also hope to work on a spline exporter tonight, as toshiba suggested to me that C2 can render polygons using only 2 vertices/line objects. It will make your telegraph line creation much easier ;)

The log should prove useful, I'm always scratching my head when I receive an error message from the script. :)


I don't know if it helps, but when exporting objects like these, I usually just add a "turn to poly" modifier on top and then collapse down from it, which seemed to work fine at least with the old exporter. Converting multiple objects into editable polies simultaneously (using the viewport right-click menu) apparently breaks the instancing in Max, although this shouldn't be a problem for the script if I've understood (as long as the object names stay identical before the numbering)

as long as objects have similar names before the numbering AND an "&" prefix yes ;)

double post! :p New quick release with proper object handling and errorlog file creation! Check the first post.

The group handling seems to be working fine, and objects with symmetry modifier(s) are now exported correctly as well. :)

I still have to fiddle with the line types though, so maybe that's something to look into at some point. In Maxblocks.max for example, I have to delete the line objects without "&", and convert the remaining line objects into editable polies. Not that the "&" character makes any difference here, it's just my naming convention where I put "&" in line objects which become actual 3D meshes after the modifiers do their magic.

Otherwise the game complains about some objects having no faces or vertices (brmodelupdate error).

And here are some additional observations:
- The coloured plane linked to the traffic lights in Max seems to be missing in the game. Did this work on your own export tests?
- The curved concrete tubes are exported, but in the game, there's at least one of them located inside the parking hall, which is where the world origin is also located. I'll see if I can find anything useful about this.

Anyway, thank you for the progress so far. :)

Ah yes, I found out about the traffic lights. I didn't add any hierarchy support for objects within a group! :( I'm on it!

The 'brmodelupdate' error is awkward. To be honest, most of my testing is done in pt2. I should also do my tests in c2 as it shows, as it doesn't show in pt2.

about your line model with the modifiers. It is hard for me to tell, from the script, whether a line object should be a 3d object, or a 2d line. In your case, the line has modifiers added, making it a 3d object, but in other cases it shouldn't be. In both cases, the original object is a line, which makes it hard for me to tell what direction to take... I will have to look into that also...

I will do some work on the script today. The model of the curbwalk showing up in the origin is part of a method I use for model exporting. I will need to change that method. I also hope to add spline/line to '2d line' model support today.

btw: how do you get c2 to spit out error messages properly? It only does it randomly 10% of the time on my system, which is very annoying

I understand the problem you describe about the line type objects, it's more or less what I was thinking too. Separating the 'exportables' from 'non-exportables' with the "&" character works at least when sorting it out manually, but I'm not entirely sure yet if it would work in general.

I assume the line rendering in C2 is different from the wireframe render mode. :) Does it really show up as a line, or does it have thickness (and if yes, what about the colors/materials/UV mapping/smoothing)?

As for the error messages: I don't know if this helps, but I'm still using Windows XP, and running C2 with Zeckensack's glidewrapper. If I recall, Direct3D wouldn't show error messages, no matter what (but it let you alt+tab, which was often handy when constantly making adjustments to cars/tracks/etc)

Spline rendering == CHECK!

the splines/lines will render as wireframe thin polygons. I think they are always 1px width in the viewport. I cannot test at higher resolutions though (crap laptop)

Most objects export great now. Still having issues with the sewer curves though...
I will update the pack soon. First need to double check everything ;)

Interesting. The thickness could be just right for most cases, I think. :)

What about curved sections and the number of steps in Max? Do these carry over too?

no, the splines will exported based on their points and segments only. As I said, it basically is a mesh with very thin faces, the number of steps are not taken into account.

good work harm :)

Thanks mate!

I haven't just been sitting around. I've almost finished the 'Smashable setup' part of the scriptpack. I'm really happy that big hurdle is now almost out of the way. There should be an update real soon. ;)

I have a drivable vehicle related bbox tip (originally shared by Chevy II) which I think isn't very widely known. I thought I would mention this here since you're constantly improving your car exporting script.

So, similar polyhedron bbox shapes can have a slightly different effect on physics, depending on which order their vertices are listed. For example, let's take a simple box of the following dimensions:

Width: 4
Height: 1
Length: 10

Typically, the bounding shapes section would then look like this:

Chevy II / Small Block suggested this instead:


That is, listing the vertices of the right side in reverse order. I've noticed that it does make a difference in the game on the vehicle physics. Thinking of your script, I guess it could be easy to handle this with bboxes created using a closed spline + extrude, but dealing with more exotic shapes might be too difficult.

Anyway... FYI, food for thought, and all that. :) You can try it yourself if you like, and then decide whether it's worth investing any time into.

Sorry about the lack of updates lately, but I have been awfully busy with real life business.

I did however make some progress and still plan to put out a new wip release soon.

About the bbox's;

I did notice before that it makes a difference in what order the points are written down. Especially on objects more complex it becomes tricky. I believe the bboxes written with my script are still correct though.

I also noticed that for noncars you can use all 4 types of bboxes (polyhedron, box, sphere and wire bboxes). However on the cars main bbox, the box type doesn't seem to work. (game crashes) Not sure about the sphere and wire types yet...


I am currently almost done with integrating the smashable setup into the track and car tools. I just have to do some more testing, especially on the parts where the smashable uses external act/dat and mat files as shrapnels etc.

After that I will have a go at the preprocessing! I already took an in depth look at the way the tracks are processed and I think I know how to approach it script wise, so keep your fingers crossed! :)

Yes, the bboxes created by the script work fine 99% of the time... I've used it a lot. :)

In some cases though, at least for me, the script randomly writes the .99999 decimals. If you're unlucky, this can sometimes cause WOAS errors.

Sometimes you get WOAS no matter what, until you make a change that makes C2 happy.

I accidentally found out that the script creates a box bounding shape if an object's name starts with "box". :D

UPDATED new WIP version uploaded. Probably one of the last WIP as I am aiming to go for a final next release!

check the first post for download link ;)

I've recently been licking up the exporter script. Currently, I am testing the new preprocessing function. It seems to do a good job, but every so often the track becomes unsolid beyond a certain boundary. Odd thing is, the same exact thing happens with pt2 preprocessed tracks! :o (Which means my scripts are working fine)

It seems when I use a division of 16 rows/colums thing are a lot more stable. Is this something generally known to happen? I haven't meddled with the preprocessing in a long time, so I could use some refreshment. It seems the game likes to handle similar track chunk sizes, so a big track needs a bigger division, a small track less divisions? The newsumo for example has only 2 rows/2 colums, while the airport map has 16 rows/columns. For now I will assume this to be correct.

I also discovered that big noncars (bigger than a track chunk) still cause issues ingame :( I am afraid pt2 cannot preprocess these situations, simply because the game cannot handle it either... will test some more though!

Hah, great to hear! I always thought the track could do with a better terrain, as it was 'blocky' as hell. I will give it a try this weekend.
Did you need to drop some noncars back onto the terrain? You know there are scripts that can easily do this right?

Did you preprocess it? I don't see any peds.

Harm, I wanted to try your preprocessing script (preprocessingV1.ms) on blocksburg, but I can't seem to make it work. Here are the steps I took:

1) Delete the temporary objects not contributing to map geometry
2) Convert the rest to editable polygon type
3) Remove the "&" from the names of several grass field objects
4) Run script

At this point, Max freezes. Is the script able to preprocess my map on your system? Or are there additional steps required to make it work?

Uh yeah, that's an old one sadly. I have uploaded the latest WIP stuff here.

http://www.harmsollie.nl/files/Carmatools/Carmatools_20130131.zip

Preprocessing is now done in the Race setup tool.
I'm not sure what version you were using before, there might be some changes that are new, so better to back up everything you worked with. It seemed to do a good job till now (apart from the prerpocessing then ;) )

Even so, the preprocessing doesn't seem to work propper on your map just yet. It does arrange a lot, and does a partial job, but there are still object that remain outside of the preprocessing tree... so you will have to be a bit more patient.

I will be using your map as a test case here, to get the preprocessing flaws out of it, but it will take a little time before I manage to poop out a new version. I have too many projects, ARGH!

404: File not found. ;)

But it doesn't matter, since you say it doesn't work yet. Sorry to hear you're busy, but don't worry, and take your time.

Ah crap, bad url. Fixed!