World Collision Entry alterations

**makanyane** · November 14, 2009, 04:39 AM

EDIT: 9 Jan '10 : Tutorial amended to include use of the Integrated World / Terrain Editor released by wilddog. The IWTE tool incorporates most functionality from KnightErrant's WCEditor v1.2, which he kindly allowed to be used, and also allows collision entries to be automatically generated from individual .world objects.

WCEditor v1.2 functions not included in new editor are;
A). the ability to view collision entries in Mayavi (because we haven't managed to get Mayavi to pack to .exe file) - you may wish to load collision files in WCEditor v1.2 to use viewer function if searching for entries to re-use
B). the ability to write and load ms3d files direct to the collision file (instead of loading derived file from .world into collision entry) - If you want to ammend the shape of a collision entry that you know is used for multiple objects you need to use WCEditor v1.2a as before to do that.

Tutorial only covers the .worldcollision file part of battlemap buildings, this provides the invisible element of the information, that allows game to tell when building has been hit, and stops camera going through buildings etc.... Some preliminary information on the collision file is written up here: https://wiki.twcenter.net/index.php?...on_file_-_M2TW most of the information contained in that comes from the work of Argantonio, KnightErrant and friends in the World Modified thread.

To usefully change the .worldcollision file you need to have changed or added an object in the .world file (by using the WorldEditor or IWTE tool to change an .ms3d structure file) and you need to know the object number for the item you changed.... that can be found by looking up the complex/structure/group number from the .ms3d file in the cheatsheet produced by the v0_9 WorldEditor, or by reference to the gameobjects tab in the IWTE tool.

Adding a collision entry has now been automated to an extent, but you're still likely to need to understand some of the background information to this.

Index:
Overview
Using the WCEditor 1_2
---Changing an Existing Collision Entry with WCEditor
---Removing a Collision Object with WCEditor
---Collision Volume Location and Orientation with WCEditor
Adding a New Collision Entry
Bounding Boxes and Spheres

****************************************************

Overview
The world collision files control the invisible bits of the settlements and battlemap buildings. If an object e.g. a part of a wall or a roof, has a collision volume entry then missiles will hit the object instead of passing through it, damage can also be done to the object if it has damaged states it can change to. A building or object needs to have a collision volume in the right place for it to be recognised as a building or tower when you hover your cursor over its position in game. The position of the collision volume also determines where the objects animation (if any) appears, see experiment on: https://wiki.twcenter.net/index.php?...es_file_-_M2TW

The .worldcollision file is made up of five different types of table:
Table One defines a structure of bounding boxes, some lines define only bounding boxes that contain a series of smaller boxes. The lines containing the lowest level boxes 'contain' one of the lines in table two.

Table Two assigns each object from the .world file into one of the bounding box lines in table one.

Table Three lists each object from the .world file in turn, and specifies which 'Central Entry' collision volume they use, and give it's relative position, rotation, and individual bounding sphere coordinates and radius. Objects that don't use a collision volume have -1 as the Central Entry volume number.

Central Entries these tables give the information for each individual collision entry volume. They may be made up of multiple groups (in the same way the .world objects can be made up from multiple groups). If a .world object has two groups representing an undamaged and a damaged state then the Central Entry it uses should also have two corresponding groups.
You'll find there are less Central Entry tables than objects in the corresponding .world file, that is because CA's system re-uses the same collision volume for multiple similar objects in different locations. I’ll describe this re-use of the same collision volume as a different ‘instance’ of the same volume.

Last/Final Table this simply lists all the bounding sphere dimensions for each object in the .world, there's one row per object. Objects that don't use a collision volume have four +0.0000 entries in their row.

****************************************************

Starting to Use the WCEditor
To use the WCEditor you need to have a specific type of python installation on your computer see
https://wiki.twcenter.net/index.php?...n_Installation
for details. You should also ideally have the mayavi2 element working so you can preview existing volumes.

EDIT: The WCEditor is still has useful functions not yet included in IWTE but as they're for more advanced use (and you need python installation) I've spoilered this bit.

Spoiler Alert, click show to read:

**makanyane** · November 14, 2009, 04:40 AM

Adding a New Collision Entry
The IWTE tool has a button on the gameobjects tab which says "Add Object Collision"

(I'm very tempted to leave tutorial as that as its so refreshingly simple....)

Anyway.... to use the IWTE tool just copy and paste the IWTE_1v2_beta.exe somewhere, near / in same folder you're working in is easiest so you don't have to navigate far to files. Double click the .exe to launch, you don't need python installation or any thing else to make this run... When program starts you get interface screen and .dos window launched - don't close the .dos window it a). contains useful info you need to keep an eye on, and b). will shut the program

Click 'Read binary world file' from any of the last three tabs to load the .world file you've been working on. If you don't already know the object numbers for the elements you've added you should be able to work them out from the 'gameobjects' tab.

The screen example shows that the first object in complex 3 - structure 2 (in IWTE numbering) is object number 89. The 1 in the third column shows it only contains one group. To add a new collision entry for this object simply click the 'Add Object Collision' button while its line is selected. You'll then be asked to load the .worldcollision file that is to be amended, and asked for a new file name for the revised file. It should then write file - keep an eye on the .dos window to see when its finished.

If you want to add a collision entry for another object you'll need to remember to load the revised file when it asks you for the file to be amended next time! You'll end up with a lot of intermediate files if you add collisions for a lot of objects.... once you confirm that the last one is functional you can safely delete the intermediate files.

Note: that the IWTE editor doesn't currently delete un-used collision entries from .worldcollision, so I'd recommend only adding collisions once you know you've got your structure fairly well finalised, otherwise repeatedly adding new entries will expand file size a lot.... ! - a clean up feature might get added later, but WD isn't promising anything...

*******************************************************************************

For the technically minded and 'world modified' thread followers, what the IWTE tool does is to extract the vertex information from the objects' groups' information in the .world file (that's why you need to have loaded correct .world file first) and then moves all the vertex co-ordinates to produce an identical set of groups centred on 0,0,0 origin, and writes them to a new 'central entry' section. (All entries added by the tool use the simplified one line small table entry, we've not yet found any problem doing this, please report if you notice any odd effects.)

The tool then uses the amount it moved the co-ordinates to populate the table three entry and re-position the collision model for the object back to its in game position. The table three entry follows the

Code:

 1  0  0  x    1  0  0  -x
 0  1  0  y    0  1  0  -y
 0  0  1  z    0  0  1  -z
 0  0  0  1    0  0  0   1

pattern which effectively means keep model in same orientation and move it from origin by x, y & z
(y is height as in milkshape, x is -x compared to milkshape).

Although the IWTE editor does not support the re-use of existing collision entries for other objects you can still opt to do this manually via the 'Collision Binary to Text Conversion' found on the 'World' tab of the IWTE editor - and conversion back on same screen.

If you've added say a wall shaped object and you know that another object you've added is same shape, just relocated, you can re-use the collision model for the second & subsequent objects by changing the displacement / rotation for its table 3 matrix, and make it use the same central entry as was added for the first object. To find matrix values for rotated objects use johnwhile's excel sheet, attached here: http://www.twcenter.net/forums/showt...07#post6504307

CA set up most of their objects to share collision entries, we don't know yet if there would be any performance problems in deciding to have unique collision entries for each object (it would obviously enlarge the .worldcollision file sizes substantially but other side effects are unknown)

EDIT: Spoilered previous content as it contains some tech information relevant to tool development but not now required for normal use.

Spoiler Alert, click show to read:

**makanyane** · November 14, 2009, 04:40 AM

Bounding Boxes and Spheres
If you add a collision volume and you don't see any effect in game (unless you simply ended up with the collision volume at the wrong co-ordinates) its probably because the new/revised collision volume is outside one of the bounding boxes or spheres and therefore not being used. The bounding boxes and spheres control which bits of a structure the game 'renders' and save processing power by allowing the engine to ignore any coordinates outside the bounding areas.

The bounding spheres and boxes in the .world file also control whether or not a collision volume works properly....

EDIT: Wilddog's IWTE tool calculates and adds bounding spheres for objects that you 'add object collision' for, and includes those spheres in table 3, the Central Entry header, and the Last Table. It selects the useable bounding box in table 1 with the closest centre to the object, and if necessary adjusts the size of that box and it's parent boxes in table 1.

you therefore shouldn't now need to know the rest of this, but I've left it incase you decide to fiddle with something manually / need to bug hunt / or for further tool development.

Spoiler Alert, click show to read:

World File Bounding Boxes and Spheres
EDIT: The IWTE tool updates bounding spheres for structures when they are added or replaced, it does not at the moment update the complex and world level ones (that feature will be added in future version). If you've tried adding collision entry and its not appearing - and your new structure is larger / moved, then problem may be that the complex and world level bounding spheres in .world file aren't big enough, if so refer to info in spoiler. (Note: textrep examples are from WorldEditor, IWTE output is slightly different in terms of comments / layout)

Spoiler Alert, click show to read:

Table One of the .world file has a very similar structure to the collision file as described above, the bounding boxes in that table control if the visible structure is rendered properly and don't really effect the collision volumes.

Annoyingly if the bounding spheres in the .world file are too small your collision volume won't work.... that was something I'd overlooked for a long while and couldn't figure out why changes I was making didn't show up.

There are bounding spheres for each individual structure (a structure contains multiple groups/objects in one .ms3d file), then there are larger bounding spheres that cover each complex, and there is one overall bounding sphere which should be large enough to contain all the parts of a settlement at the end of the complexes section.

Viewed in the textrep version of a .world file generated by the WorldEditor the bounding sphere for a structure looks like:

4 174 120 180
130 174 119 181
255 130 211 151
0 0 0 0 39 0 90 40 0 89
0 0 0 0
-0.2923878 +4.3469734 -38.0206947 +27.6362915
0 0 0 0 19 0 91 20 0 72 20 0 92
# ============================================================
# Structure 2
# ============================================================
23 0 93 3 # Structure number 2
27 0 94 0 0 0 0 0 0 0 0 88
155 156 157

again it's x,y,z coordinates of the centre and radius, that's the sphere for Structure 1 of the complex. The one for the last structure in a complex will appear just before the textures section for that complex:

255 138 239 191
255 143 223 191
0 0 0 0 39 0 112 40 0 111
0 0 0 0
+0.9098927 -0.4163971 -34.7492523 +9.8374634
0 0 0 0 19 0 113 20 0 92 2 0 0 0
49 0 114
12 buildinglod0
17
50 BlockSet/Textures/walls_castle_large_stone.texture

The sphere that covers all of an individual complex, is written at the end of the textures section of a complex eg:

18 buildinglitterlod0
17
40 BlockSet/Textures/NE_litter_pass.texture
47 BlockSet/Textures/NE_litter_pass_normal.texture
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
48 0 2941 49 0 2940
+3.5611148 +1.0839137 +46.9186592 +18.7703285
15 0 2942 16 0 2801 605 625 1 0 0 0 4 0 0 0
472 226 96 44 31
69
416 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270
1
# ============================================================
# Complex 24
# ============================================================

The sphere that covers all the complexes is the line just before the list of files at the end of the complexes section:

2164 32
66
145 146 147 148 149 152 153 154 155 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 341 343 345 346 348 350 352 353 354 355 356 357 358 359 360 361 362 363 364 365
None
-13.7802124 +10.7251711 +6.0081201 +102.0638657 0 0
52 settlements/pkh/Hill_Fort_C/hill_Fort_C.worldTerrain
56 settlements/pkh/Hill_Fort_C/hill_Fort_C.worldPathfinding
55 settlements/pkh/Hill_Fort_C/hill_Fort_C.worldVegetation
0 0
# ============================================================
# Many Tables
# ============================================================

even if you don't understand much of the rest of the file the bounding spheres with their characteristic 4 floats are reasonably easy to pick out.... they can be changed by amending the textrep version of a .world file and then reloading the textrep in the WorldEditor and writing a new .world file.

**King Kong** · December 09, 2009, 07:01 AM

I always wondered if it would be even possible to change those collisions and now I have seen this tutorial. Thanks a lot for that!

Somehow it seems not many people are interested in this yet (or they just havn't managed to really understand all this, like me

), but I suppose it will become invaluable once someone has achieved to modify a settlement.

Do you think you may do such a tutorial for modifying buildings and pathfinding (which is probably even more important than collision)?

**Yelü Dashi** · December 09, 2009, 01:04 PM

I also completely missed this. Bookmarking it for a rainy day when my brain is functioning properly. Thanks for posting this makanyane, you're a star. Feel sure it will be compulsory reading in the future.

**makanyane** · December 09, 2009, 01:32 PM

Originally Posted by King Kong

Do you think you may do such a tutorial for modifying buildings and pathfinding (which is probably even more important than collision)?

Re: modifying buildings I've been able to do some bits under existing tools see Example fort, but its not ideal at the moment without facility to add or subtract objects from existing structures, so I was holding off explaining too much on that in case we can get a bit further with tools shortly.

Pathfinding (on walls) will probably always end up being a manual addition as alterations require you to 'understand' in 3 dimensions links to the existing paths and routes, and I don't think anyone's likely to make modding program that can 'think' in that way, so that one I will try and write some more about. I did manage to add some extra routes in the fort example but its a bit time consuming and finicky...

**King Kong** · December 10, 2009, 01:59 PM

Nice, that's great news!

As long editing pathfinding doesn't end in real programming, I would certainly be willing to make this stuff manually, given that I will ever understand it.

Good luck for you and wilddog for whatever you do next.

**Devils_Advocate** · December 14, 2009, 04:04 AM

@Makayane
It looks a "bit" sofisticated.
I don´t even ask what you are doing, all I understood respectively saw is that you are able to remove buildings form castles/cities. So this means you are able to remove structers/complexes? Wouldn´t then this thread belong to the world modified thread?

I hardly look into the tutorial section but I am actually very interested in this.
I am pretty much a nob when it comes to bits and bytes.
Maybe you can say in a few (understandable) words what the benefit of this will/may be?

**makanyane** · December 14, 2009, 11:20 AM

@DA
this tutorial isn't really to do with adding or deleting visible structures from the .world file. Wilddog is still working on tool to try and do that, it looks feasible but is still a way off yet.....

This tutorial can help with what you are able to do at the moment. Existing WorldEditor by KE allows you to change shape of objects within a structure, or hide them by moving them underground (by changing milkshape models). But if you do that on its own you are left with the collision version of the object (the invisible bit that tells the game when something has been hit by artillery - and that gives an object the label 'building' when you hover mouse over it in game / says you can't attack it / stand cavalry on it etc...) still in the old shape / position.

If you're just trying to hide object you can get rid of the invisible collision part by changing the objects table three entry in the .worldcollision file. I've just added section here, which explains more explicitly how to do that.

If you've vastly changed shape or size of visible object then you either need to Change Existing Collision Entry (to get its invisible version to match up with new shape)

...or if it shared a collision entry with another object (that hasn't changed to same shape and size) then you need the bit about adding a new entry - so it can have its own unique shape for its invisible version.

Some of this might get automated later, but I wouldn't want to guarantee how much! A lot of the info here (apart from adding new collision entries), was actually in the World Modified thread, most things are in there somewhere..... but when thread got past 50 pages it got a bit impossible to find

**Devils_Advocate** · December 14, 2009, 04:48 PM

Ahhh, now I get it, why it is called 'World Collision'.

I understand now its purpose and what is meant.
Thanks for clarification!

@ KK so that´s what you did to TATW?

**johnwhile** · December 26, 2009, 04:22 PM

I create a excel file to undestand the RotationMatrix. Makanyane has tested my excel file with a lot of test and at the moment it work at 100%.
In this site i found the math information to build the matrix:
http://spanusoft.altervista.org/Pipe..._rotazione.htm
The matrix work with 90°, 180°, -90°, -180°, 270° and mirror operation but i don't test other angle.

Attention:
In milkshape: make the following order operations: mirror, rotation, move and utilize the "User point" and "Absolute" option to do a correct rotation and movement without altering the pivot of object. The sign of "X move" in the collision file must changed in -X !!!

In 3dstudio: mirror, rotation, move haven't a order, put "absolute" in move and rotation operation, the mirror utilize the traslated pivot, not like milkshape so it's very simple

**johnwhile** · December 28, 2009, 08:21 AM

A very simple script for 3dstudio max to view the row BoundingBox of table1 from file .world.
(A little correction here).
Copy the script and the file ascii.txt in the same folder, drag on the script into 3dstudio max interface.
I never utilize maxscript so i can't create a perfect tool, if someone know the maxscript can do it better

this is the resul for ne_curch.world, make attention to delete the two "0" in the first Line:

**makanyane** · December 28, 2009, 10:27 AM

Thanks for posting the excel file, I've been using it and it works well for everything I've tried so far.

(think you need to enter rotation as clockwise rotation not the value you put in milkshape 'rotate' menu which seems to turn anticlockwise - I'm still managing to confuse myself about differences between milkshape and game co-ordinates.... )

I'll try and re-write the relevant section of the tutorial now that you've shown how to find the matrix numbers for re-using a collision object in different locations / orientation. I hadn't thought that was going to be feasible to work out before...

I'd love to try the Bounding Box visualiser but don't have access to 3ds at the moment.
Can you name the boxes so you can refer back to which line of the table they came from? For .world file you're really stuck with adapting the box the complex is already in... but for collision file you can change which existing box your object uses (it's just figuring out which one is closest that is the problem!) if tool works for collision file table 1 that might be a solution.

As the Bounding Box thing relates to the .world file as well as collision it might be worth posting about that in World Modified thread too.

**Devils_Advocate** · December 28, 2009, 12:23 PM

Originally Posted by johnwhile

Do I understand things right, those boxes simulate the area, ingame invisible of course, where the collision with the church i.e. that area happens? The textured church model itself is so to speak 'just a visual placeholder'?

**johnwhile** · December 28, 2009, 02:04 PM

Ops, the X game correspond to -X in 3dstudio so now i correct the position of box but i don't undestand why the pivot has the x and not -x.... my knowledge of maxscript is very low

**johnwhile** · December 28, 2009, 02:10 PM

Originally Posted by Devils_Advocate

Do I understand things right, those boxes simulate the area, ingame invisible of course, where the collision with the church i.e. that area happens? The textured church model itself is so to speak 'just a visual placeholder'?

i make this tool only to help me to correct quickly the BoundingBox and to see quickly all BoundingBox, but i don't know now export the correct file, you can do it manually...
Why don't exist a WORLD to MAX coverter ??? i think it's simple to build and don't exist the vertices and triangles limit

**johnwhile** · December 28, 2009, 02:15 PM

Originally Posted by makanyane

.
Can you name the boxes so you can refer back to which line of the table they came from?

The name of box are Box01 Box02 ecc... and correspond with line1, line 2 ecc...
This is only a modest contribution, if you wnat a big tool you can ask to Knight Errant or Vicingetorix (i don't remenber

...)

**makanyane** · December 28, 2009, 02:16 PM

@ Devils_Advocate
Not quite, you've got the right idea that there is an invisible version of the church that says where collisions occur. But that should actually be exactly the same shape as the church, complete with pitched roof / crosses etc..

That invisible version is made up of lots of small models in a similar way to the visible textured one.

Those invisible small models all have to fit within the bounding box structure that johnwhile has illustrated, and also their own bounding spheres. If your invisible small model doesn't actually fit inside the bounding box that it's meant to be using then it won't work properly (either 'disappears' from some angles or doesn't work at all - you can tell if the bits of invisible collision model are working or not by hovering mouse pointer over building in battle - if it says 'building' etc, its working - if it doesn't say anything / you can move camera through it, then its not)

**wilddog** · December 29, 2009, 01:34 PM

OK, I finally caught up on some things and so intend to look at this over the next few days (whilst still on hols). Maks explained the basics and I want to try and re-enter the info associated with a Gate as a first step. Some bits look relatively straight forward but we'll see

@johnwhile - thanks for uploading the excel sheet with the rotation matrix info. I need to cross check it to make sure I understand it - but it should come in handy... and my maths is very rusty.

**xeryx** · December 29, 2009, 01:47 PM

KUDOS to you SIR!! As this is one of the top problems of this game that must be fixed, for seiges to work correctly!! +rep

If the portals and gates can be fixed those two are big problems. Then of course there are many buildings inside of the castles/cities that pose problems.However the most anoying are the roads in some of the settlements are just all hosed up. As I'm sure you well know.

This really is some AWESOME news!! I hope the community realizes how big this is.

Thread: World Collision Entry alterations

Thread Tools

Search Thread

Display

World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Re: World Collision Entry alterations

Posting Permissions