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

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 ;)

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:
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.

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... :)

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.

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

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!

Helppppppppppp!

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
[/URL]

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

Thanks Santa's

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 )

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.

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"

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

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