[ Midtown Madness 2 Central ] [ Midtown Madness 2 Central ]

Midtown Madness 2 Central > City Editing > [RTI] Pathsets: Basic file format
Goto page 1, 2, 3, 4, 5, 6  Next
View previous topic | View next topic
Author
Message Post new topicReply to topic
fre_ber
triangle fan
Moderator

Joined: 15 Jul 2002
Posts: 2399
Location: ZZ9 Plural Z Alpha

Status: Offline


Post subject: [RTI] Pathsets: Basic file format Reply with quote

There are already a few threads about pathsets, but since most images in those are lost and gone forever, I thought that I would start a new one.

Based on the pathset file format description made by someone named Wolf that was posted here by Yallis I made a few refinements that made it just a tad more complete. Still some things are mysterious, though.

Code:
struct Pathset
{
    char[4] id = "PTH1";
    ulong nPaths;    // Number of paths in this pathset
    ulong unknown0;
    struct Path paths[nPaths];
}

struct Path
{
    char[32] name;    // Name of object or texture, padded with 0x00
    ulong nPoints;    // Number of points in this path
    ulong unknown1;
    struct Point points[nPoints];
    ulong spacing; // Spacing of props placed between the points in units of 1/1024 metres (spacing = (ulong)(metres * 1024))
}

struct Point
{
    ulong unknown2;
    float x;
    float y;
    float z;
}


Props can be placed using three different methods, either by assigning explicit locations for each prop, by letting MM2 place the props uniformly along connected or separated line segments. At this time, I don't really know how these three methods are indicated within the pathset file.

Pathset files can also be used to place decals instead of props. A decal is a texture that isn't bound to a specific PSDL attribute. For example a crosswalk texture that is in the middle of a road strip - not near a road junction. At this time I don't know what differentiates a decal pathset from a prop pathset. All I know is that when placing decals, the name element is a texture name rather than a PKG name.
_________________

"He who re-invents the wheel, understands much better how a wheel works."

<[4D]JoeShmo> what we have here, is a failure.. to communicate


Last edited by fre_ber on 23 Apr 2006 02:40 pm; edited 4 times in total
Post 09 May 2004 05:17 pm
View user's profile Send private message Visit poster's website
abec
Bench Warmer

Joined: 20 Apr 2003
Posts: 30
Location: NE

Status: Offline


Post subject: Reply with quote

This is really great, using the information available so far I managed to make a test track (I call it a "skid pad" Smile, with a jungle of trees surrounding the road:



The coordinates described here work perfectly for me, what's most puzzling is the "unknown" bits of the structure. Problem I'm experiencing is, at one point on the track, lots of trees are visible but most of them will disappear as soon as I move just a little bit (1 or 2 meters away from the "last good" point. The trees are still visible from the mirror though, see picture below).

)

I guess the unknown bits in the structure most likely have to do with the visibility managed by the MM2 rendering engine. Would be real nice to have this stuff sorted out.

Cheers[/img]
Post 14 May 2004 03:16 pm
View user's profile Send private message
fre_ber
triangle fan
Moderator

Joined: 15 Jul 2002
Posts: 2399
Location: ZZ9 Plural Z Alpha

Status: Offline


Post subject: Reply with quote

Cool. Nice to see the info come to use. One thing I have been wondering about is the orientation and scale of the objects placed in the pathset. The scale might not be controllable, but the orientation should be. I'm thinking that unknown2 should, somehow, represent an orientation. Anyone up to test this theory? Wink
_________________

"He who re-invents the wheel, understands much better how a wheel works."

<[4D]JoeShmo> what we have here, is a failure.. to communicate
Post 14 May 2004 03:22 pm
View user's profile Send private message Visit poster's website
Misterlvlariusz
PSDL-ML

Joined: 08 Apr 2003
Posts: 337
Location: BE/PL

Status: Offline


Post subject: Reply with quote

Wait wait.. so props are completely independant from PSDL? I mean, there's not even a need to specify on which blocks the decal/prop has to be placed? And are there any other files linked with props? (maybe files that contain prop visibility info(like distance).. stuff like that)
_________________

www.3dtcf.info
Post 14 May 2004 03:44 pm
View user's profile Send private message Visit poster's website MSN Messenger
fre_ber
triangle fan
Moderator

Joined: 15 Jul 2002
Posts: 2399
Location: ZZ9 Plural Z Alpha

Status: Offline


Post subject: Reply with quote

I think that they are completely inpependent. But those visibility issues abec is talking about might indicate something else...

I am also thinking that the block structure of the PSDL will improve performance when using many props. Jason's experiments indicate that, when he used many breakable props in his one-block-map he experienced lagging. My theory is that each block internally has a list of all the props currently in that block. This way MM2 doesn't always have to render or check for collisions with every prop in the entire city.
_________________

"He who re-invents the wheel, understands much better how a wheel works."

<[4D]JoeShmo> what we have here, is a failure.. to communicate
Post 14 May 2004 03:56 pm
View user's profile Send private message Visit poster's website
Yallis
Professional Sucker
Moderator

Joined: 20 Jul 2002
Posts: 693
Location: city.psdl

Status: Offline


Post subject: Reply with quote

abec - Neat! Props sure add life to a track.

Yep, both Dacris' City Editor and Wolf's SF Editor support rotation. Wolf's editor also shows the unknown flags. Dacris says this in the readme about flags (or are they really flags?):
Quote:
Flags do not have any significant impact on the objects. Therefore, all flags support has been removed. We have yet to figure out what the flags mean. As long as you do not mix different types of pathsets (such as mixing sf_bridge with props), you should be fine. The editor just maintains the flags of the pre-existing objects in that pathset.


...it goes on about rotation and visibilty:
Quote:
An object is a set of points. Each object is of a certain type. An object can have more than one set of two points. The sets of points are called "instances" of the object. The object ID is a unique number identifying each object. The object ID in the screenshot on the left is the first number of the set of two comma-separated numbers appearing before the object type. The second number is the point number (which point in the object). It grows by 2, since all instances of the object have two points. If an object has the more than one instance (i.e., there are two or more objects with the same object ID), all instances of the object will be affected when you apply such functions as changing the object type.

There is a certain linear length between the two points of an object instance. This length should be left at 10. If you want to make your object instance more visible amongst the other instances, you can increase this value to make a greater distance between the two points of the object. However, in-game, this value doesn't matter.

Rotation on all axis are provided by using two coordinates. We're re-inventing the wheel. Wink

Another intersting thing he mention is that one pixel on the hudmap equals ~2.85 MM2 units.
_________________
Post 14 May 2004 07:35 pm
View user's profile Send private message Visit poster's website
fre_ber
triangle fan
Moderator

Joined: 15 Jul 2002
Posts: 2399
Location: ZZ9 Plural Z Alpha

Status: Offline


Post subject: Reply with quote

Well, I'm thinking that both Dacris and Wolf are slightly off. There isn't a "set of two points" defining each object. There can be an odd number of points as well. I still think that, when there are just two points, the path defines a line segment. Along that line segment an instance of the object is placed at an interval defined by the spacing parameter. So in order to place a row of trees, all you need to do is define the start and end points of the row and the trees will be placed automatically using the given spacing.

I made a little program that reads the pathset files and prints them out in the pseudo C format I usually post my findings in. If you do see the connections - please post. Wink

Dumps
_________________

"He who re-invents the wheel, understands much better how a wheel works."

<[4D]JoeShmo> what we have here, is a failure.. to communicate
Post 14 May 2004 11:05 pm
View user's profile Send private message Visit poster's website
Stereo
Senior Dismember
Moderator

Joined: 22 Jul 2002
Posts: 4023
Location: London, Ontario

Status: Offline


Post subject: Reply with quote

Breakable objects disappear as soon as you go onto a different block, I'm not sure if it has to be not a neighbour with the block the breakable is on or not.



As for the hudmap - thats completely dependent on the pkg that defines it, and I think some tuning files. The 2.85 units is for the editor's map view.
_________________
Hi!
I can bend minds with my spoon.

A member of Team Graduation 2004/05!
Post 15 May 2004 01:01 am
View user's profile Send private message Visit poster's website AIM Address MSN Messenger
Yallis
Professional Sucker
Moderator

Joined: 20 Jul 2002
Posts: 693
Location: city.psdl

Status: Offline


Post subject: Reply with quote

fre_ber - I agree. That explains the huge spacing for single objects. Btw, Midnight Club 2 use these flags for props: FixedObject, Obstacle, GfxOnly, Drivable and Far.

Edit:
Stereo - Hehe, thank you for exposing my stupidity even further.
_________________
Post 15 May 2004 06:26 pm
View user's profile Send private message Visit poster's website
fre_ber
triangle fan
Moderator

Joined: 15 Jul 2002
Posts: 2399
Location: ZZ9 Plural Z Alpha

Status: Offline


Post subject: Reply with quote

Yallis: It seems as if both Dacris/Wolf and I are correct... It appears as if MM2 does indeed use two vertices to define the orientation of the props. But at least in case of the line strip method of placing props it is not two vertices per line segment.
Code:
0-------1
        |
        |
        |
        2

Here, I assume that it would use vertices 0 and 1 to define the orientation of all props along the first segment and vertices 1 and 2 for the next segment. I haven't tested this in reality though. Just thinking.
_________________

"He who re-invents the wheel, understands much better how a wheel works."

<[4D]JoeShmo> what we have here, is a failure.. to communicate
Post 19 May 2004 09:04 am
View user's profile Send private message Visit poster's website
abec
Bench Warmer

Joined: 20 Apr 2003
Posts: 30
Location: NE

Status: Offline


Post subject: Reply with quote

fre_ber - I think in your Path struct, "spacing" seems to be controlling a few other things as well. As far as I'm convinced, at least the lowest byte of this 4 byte ulong has a limited range of value 0, 1 and 2. (BTW if you would change your dump program to write hex. instead of dec. values for the "spacing" defined in any pathset file, you might see this pattern).

So for an example, in your sf_props_pathset_dump file, Path #0-#2 have the same "spacing" (5120 = 0x1400), Path #3-#5: spacing = 5121 (0x1401), #48.spacing = 51202 (0xc802) and #49.sp = 61442 (0xF002).

My tests showed (first byte of ulong "spacing"):

00: default orientation (no rotation), all instances (points) are individually visible
01: only the first point of each 2 point-set is visible, with orientation determined by the angle between P0 and P1 (or P2-P3 and so on).
02: creates an array of the current pathset object, stretching from p0 to P1 (or P2-P3 etc.). Number of array elements proportional to the distance between P0 and P1 (don't know what defines the element spacing though).

0, 1 and 2 seem to be the only valid values. I tried setting this to 3-5, MM2 didn't crash but no props would show up at all.
Post 19 May 2004 01:45 pm
View user's profile Send private message
fre_ber
triangle fan
Moderator

Joined: 15 Jul 2002
Posts: 2399
Location: ZZ9 Plural Z Alpha

Status: Offline


Post subject: Reply with quote

Hmm... Interesting, but when I use the spacing as I defined I get the correct number of trees between the points... Maybe I have only looked at the places where it works... Neutral

Edit: Would it make sense to break that parameter up into two 16 bit parameters instead? One being spacing and the other being pathType? That would be the missing link... Smile

EDIT 2: Hmm, the values are too close to eachother, bitwise... MM2 rarely use parameter sizes smaller than 16 bits...
_________________

"He who re-invents the wheel, understands much better how a wheel works."

<[4D]JoeShmo> what we have here, is a failure.. to communicate
Post 19 May 2004 02:09 pm
View user's profile Send private message Visit poster's website
fre_ber
triangle fan
Moderator

Joined: 15 Jul 2002
Posts: 2399
Location: ZZ9 Plural Z Alpha

Status: Offline


Post subject: Re: Pathsets: Basic file format Reply with quote

Further investigation shows that you are correct, Abec. Here follows an update of the format:

Code:
struct Pathset
{
    char[4] id = "PTH1";
    ulong nPaths;    // Number of paths in this pathset
    ulong unknown0;
    struct Path paths[nPaths];
}

struct Path
{
    char[32] name;    // Name of object or texture, padded with 0x00
    ulong nPoints;    // Number of points in this path
    ulong unknown1;
    struct Point points[nPoints];
    uchar type;       // See definition below
    uchar spacing;    // Spacing of props placed between the points in
                      // units of 1/4 metres (spacing = (ulong)(metres * 4))
    ushort unknown3;
}

struct Point
{
    ulong unknown2;
    float x;
    float y;
    float z;
}


Props can be placed using three different methods, either by assigning explicit locations for each prop, by letting MM2 place the props uniformly along connected or separated line segments. The type of path is defined by the type parameter. Values are as follows:
  • 0 - Points
  • 1 - Lines
  • 2 - Line strip

For the Points path type the point list is a sequence of point pairs. The first point is the position of the prop and the second defines the direction of one of the local coordinate axis. In the Lines path type there is also a sequence of point pairs. Here the two points define a line segment and props are placed along the entire line using spacing as the distance between each prop. The next two vertices in the sequence define a completely new line segment. For the Line strip path type, the sequence is no longer a list of pairs. Instead the points 0 and 1 defines the first line segment, just as in the previous type, but the next line segment is defined by point 1 and 2, the next by point 2 and 3 and so on. Each line segment is filled with props, spaced by the spacing parameter.

Props seem to be oriented according to the vertices in the PathPoints, apparently props can only be rotated around the Y-axis and the angle is determined by the vector between two points. This means that the minimum number of points in a path is two.

Pathset files can also be used to place decals instead of props. A decal is a texture that isn't bound to a specific PSDL attribute. For example a crosswalk texture that is in the middle of a road strip - not near a road junction. At this time I don't know what differentiates a decal pathset from a prop pathset. All I know is that when placing decals, the name element is a texture name rather than a PKG name.
_________________

"He who re-invents the wheel, understands much better how a wheel works."

<[4D]JoeShmo> what we have here, is a failure.. to communicate
Post 19 May 2004 03:19 pm
View user's profile Send private message Visit poster's website
Yallis
Professional Sucker
Moderator

Joined: 20 Jul 2002
Posts: 693
Location: city.psdl

Status: Offline


Post subject: Reply with quote

Decals are path type 2, strips with 2 vertices per section. The maximum number of sections are unknown. Decal pathsets are recognized by it's file name, city\cityname\decals.pathset. The nice texture you choosed as path name will fill the polygon.
Code:
Vert 2        Vert 1
      x------x
       \
         \
           \
      x------x
Vert 4        Vert 3

_________________
Post 19 May 2004 06:10 pm
View user's profile Send private message Visit poster's website
fre_ber
triangle fan
Moderator

Joined: 15 Jul 2002
Posts: 2399
Location: ZZ9 Plural Z Alpha

Status: Offline


Post subject: Reply with quote

Very nice, are you sure that there is nothing within the file identifying wether it is a prop or a decal? I don't like the idea of checking the file name... I mean, apparently you can have many different pathset files...
_________________

"He who re-invents the wheel, understands much better how a wheel works."

<[4D]JoeShmo> what we have here, is a failure.. to communicate
Post 19 May 2004 06:15 pm
View user's profile Send private message Visit poster's website
Display posts from previous: Post new topicReply to topic

Page 1 of 6 All times are GMT
Goto page 1, 2, 3, 4, 5, 6  Next


Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Home - MM2C.com - Contact - Staff & Seniors - FAQ - Community Rules - Syndication


Powered by phpBB © 2001, 2005 phpBB Group