Dissecting the Stunts files, trying to. Anyone know more?

[Duplode]

Can you recommend a good 3d shaping tool?

That was exactly the topic I'd post about... Blender is way more powerful a software than we need, and takes long to learn, so I looked for an alternative, and found a pretty good one: Anim8or. Once you reach the site, look for the latest preview version (0.97d), as it has some tools useful for Stunts editors which are absent from the latest stable version (0.95). Why Anim8or is so appropriate?

• Freeware
• Runs on Windows, and on Wine too
• Imports and exports .OBJ files neatly
• Quick to learn - just a few glances at the manual available on the site were needed to get me started
• Allows for easy edition of vertex coordinates, so we can input exact integer coordinates (which in turn can be gathered from those 2D models CTG provided on the other thread... details to follow later)
• No need to start from scratch, as morphing an existing car into a new model is rather simple once you get the hang of it
• Supports material file (.mtl) importing alongside with the .OBJ files one can make with Stressed. By importing the .mtl file Dstien provided us you'll at the very least have a pretty nice preview of the final render.
  

There are a few issues you'll have to prepare dealing with, but all of them are (relatively) minor:

• As of now, I haven't found out a way to preserve wheel shapes, as it seems the program can't parse >4-gons (so only the vertexes remain). The raw solution to that would be adding the wheels with Stressed or editing the .OBJ directly after the shape is ready.
• If you enter integer values, Anim8or will export them without adding decimal points, which in turn will make Stressed fail to import the resulting .OBJ (as it expects input with decimal points). The current workaround to that is to use a macro-capable text editor (like Vim) to put the decimal points back automatically.

Anyway, by using Anim8or I made very quick progress with the Skyline car1 shape, created taking the Corvette as basis. Attached you have screenshots of Anim8or in action and of my half-finished Skyline under Stressed (only y and z axis dimensions are correct, wheels are obviously not inserted, etc.). When the shape is closer to completion and I have the small issues fully solved I'll post the detailed procedure I'm using to achieve those results.

CAn we create custom paint jobs? I mean with drawings or names or anything like that?

In principle, we can - the only limits are number of vertexes and polygons and, depending on which tools we use, .OBJ import/export capabilities. Detailed writings or logos might be a bit hard, but if you can provide the workarounds, sky is the limit. 

PS1.: It seems there's another SVN update for Stressed, I'm going to catch it 
PS2.: Dstien/Zak, could you please make this topic a sticky?

[Mark L. Rivers]

@dstien

I saw with very pleasure the 2nd release of your wonderful tool on the closed topic, and I tried immediately to use it  , but... the tool return me the error you can see in the attached image... 
With 1st release I have not problem... Have you a workaround to suggest me?

[dstien]

Have you a workaround to suggest me?

Open the file in the previous build, in the field called "Depth" assure that the value never exceeds 3. If you didn't modify those values yourself you may have found some new flags...

If you enter integer values, Anim8or will export them without adding decimal points, which in turn will make Stressed fail to import the resulting .OBJ (as it expects input with decimal points).

This may have been fixed now. I'm not sure what I was thinking when I wrote the original OBJ vertex regex.

You're right about Blender, my biggest beef about it is its lack of native ngons support.

PS2.: Dstien/Zak, could you please make this topic a sticky?

Hm, I don't know. Shouldn't we try to branch out into new threads now that we've got a whole new forum? This humongous thread contains some speculation and misinformation on my behalf, nobody should rely on it as a source of information for other than archaeological purposes.

[CTG]

Two questions:

1, Can you give labels to polygons to help grouping in Stressed (or are you planning to give an option like that?)? That would be a very useful aid for car designers!

2, Is it possible to change the position of speedometer and RPM indicator sticks?

[CTG]

What an evolution since my last visit: new cars, pack of possibilities! I'm shocked in the positive meaning of the word. Dstien, Duplode and Mark: thank you for this incredible work! It's amazing to see your dashing innovations!

I also have some questions: Do you know how to convert any downloaded pictures into Stunts compatible indexed 8-bit PNG to change the horizont or any other .pvs files? Have you thought on a user friendly CarBlaster with easier and more didactical handling? Is there any site for uploading and downloading new cars? What about the sound/music decoding? (sorry for asking too much but this topic is more than interesting! )

[dstien]

1, Can you give labels to polygons to help grouping in Stressed (or are you planning to give an option like that?)? That would be a very useful aid for car designers!

We could make our own resource types for storing meta data, but I don't think it's worth the effort. Again, I'd like to stress that stressed is not supposed to become a high-level modelling tool. I'm too lazy to do that.

2, Is it possible to change the position of speedometer and RPM indicator sticks?

According to Duplode CarBlaster allow you to change these variables. Said pipsqueak have documented the car parameters very well, so implementing it in stressed should be straight forward.

I also have some questions: Do you know how to convert any downloaded pictures into Stunts compatible indexed 8-bit PNG to change the horizont or any other .pvs files? Have you thought on a user friendly CarBlaster with easier and more didactical handling? Is there any site for uploading and downloading new cars? What about the sound/music decoding? (sorry for asking too much but this topic is more than interesting! )

Thanks for the kind words. Stressed can import and export PNGs. As long as the original image dimensions and unknown values are maintained existing bitmap resources can be replaced. There aren't any addon repositories yet, but I'm sure the marked will respond when there's demand. I don't see much value in sound addons, but reversing the formats sure is an interesting challenge.

[Duplode]

Is there any site for uploading and downloading new cars?

As Dstien said, the demand will eventually call for it - for instance, the recent improvements in Stressed coupled with Zak's new car contest means we'll probably have at least four new or vastly overhauled cars by November 30th 

(sorry for asking too much but this topic is more than interesting!  )

Yeah, it is well on the way to #5 spot on number of posts... 

Now Dstien, I have a quick feature request for Stressed: could you change the 3D shape exporting function so wheels are exported as hexagons and spheres as lines? That way the information about which vertexes were connected to form the special shapes wouldn't be lost while working with the .OBJ on an external editor, and when we would import the shape back we would just need to change back the primitive types to wheel or sphere.

[Duplode]

Dstien updated the Wiki solving the riddle of how the angular culling bytes (Unknown1 and Unknown2) work - a very cool find, I'd never have the insight of looking for bit-level data structures!

Additionally, after struggling quite a bit I found a way around my issues with rear lights and other details placement. Z-bias was not working correctly for me because I had not realized it is sensitive to polygon order. If you need to overlay details over a body panel with Z-bias and it's not working, ensure that the relevant body panel is placed ahead of the details in the polygon list. Another weird problem I had was with rear wheels - their orientation didn't follow the rest of the car when the camera was rotated. That problem had to do with which coordinate values you use define the different radii of the wheel. Quoting Dstien's (attached) scheme for the wheels, we have:



Points 3 and 6 define the inner radius of the wheel (or the radius of the wheel proper) on its internal and external faces, respectively. They are the points which are off-center in the z-axis with respect to the rest of the wheel. In order to have the wheels rendered properly, the z coordinates of points 3 and 6 must be set according to the table below. "+" indicates the z coordinate must be larger than the rest of the wheel (that is, it must be ahead of), and vice-versa for "-":

Wheel	Point 3	Point 6
Front/Left	+	+
Front/Right	-	+
Back/Right	-	+
Back/Left	+	+

Hopefully that can help CTG with the "minor display errors" and "wheel disorders" he was having on his Lada Laika... 

[dstien]

could you change the 3D shape exporting function so wheels are exported as hexagons and spheres as lines?

Does it work as intended if you comment out line 484 of src/shape/shaperesource.cpp?

Dstien updated the Wiki solving the riddle of how the angular culling bytes (Unknown1 and Unknown2) work - a very cool find, I'd never have the insight of looking for bit-level data structures!

Finding the 18 seconds penalty shortcut in Z88 mentioned by CTG seems a lot tougher...

I've tried to come up with a way to visualize the culling data using four discs. The two outer ones in green (first facing up, next facing down) are part of what I've called "horizontal cull data". The two inner ones in yellow are "vertical cull data". This screenshot probably illustrates this better than my incoherent English:

Set bits are marked with red/magenta. The patterns are clearly matching the model's vertical or horizontal polygons. I'm not quite sure how it works for inclined surfaces, so I haven't attempted to implement an algorithm for generating this data yet. Maybe you can help me making some sense of it with your academic background?

[Duplode]

Does it work as intended if you comment out line 484 of src/shape/shaperesource.cpp?

Yes, it did the trick 

I've tried to come up with a way to visualize the culling data using four discs. The two outer ones in green (first facing up, next facing down) are part of what I've called "horizontal cull data". The two inner ones in yellow are "vertical cull data". This screenshot probably illustrates this better than my incoherent English:

Set bits are marked with red/magenta. The patterns are clearly matching the model's vertical or horizontal polygons. I'm not quite sure how it works for inclined surfaces, so I haven't attempted to implement an algorithm for generating this data yet. Maybe you can help me making some sense of it with your academic background?

Very ingenious scheme... After looking with a puzzled expression at all the colorful tiles for a while, I got to understand it properly... except it is still not clear to me what is the purprose of the negative direction half (mask 0x0001FFFC / the underside of the disks) of the culling data, as I (maybe for not looking that hard into it) could not find any example of in-game shape where one might identify which viewing directions are covered by it. Once I understand that, I can try to help 

And finally, a rather wild suggestion on how to make the displaying/editing of culling data more transparent (if a bit more complicated): Perhaps the program might read the unknown flags, display them as checkboxes and then display the remaining 30 culling bits as a pair of 5-digit octals. That way, each octal digit would amount to exactly three circle sectors, and thus one would be able to read/write patterns more easily.

(Edit: the original post mentioned dividing the 32-bit set by 4, rounding down, to drop the final bits, which is obviously pointless if you can just pick the 30 initial bits and do whatever you need with them...)

[dstien]

Points 3 and 6 define the inner radius of the wheel (or the radius of the wheel proper) on its internal and external faces, respectively.

This turned out to be complete baloney. It looks like all the points outside the center of the wheel marks the radius. As discussed recently in the Lada thread, the height:length ratio is not 1:1, so the wheels are actually elliptical. The tyre width is decided by the game.

Very ingenious scheme... After looking with a puzzled expression at all the colorful tiles for a while, I got to understand it properly... except it is still not clear to me what is the purprose of the negative direction half (mask 0x0001FFFC / the underside of the disks) of the culling data, as I (maybe for not looking that hard into it) could not find any example of in-game shape where one might identify which viewing directions are covered by it.

Look at polygons facing down, such as the bottom of a car body.

And finally, a rather wild suggestion on how to make the displaying/editing of culling data more transparent (if a bit more complicated): Perhaps the program might read the unknown flags, display them as checkboxes and then display the remaining 30 culling bits as a pair of 5-digit octals. That way, each octal digit would amount to exactly three circle sectors, and thus one would be able to read/write patterns more easily.

I was hoping we wouldn't need to edit this data manually, but I'll put it on my list.

(Edit: the original post mentioned dividing the 32-bit set by 4, rounding down, to drop the final bits, which is obviously pointless if you can just pick the 30 initial bits and do whatever you need with them...)

The usual way to this is to read the interesting bits through a mask and then do a shift operation.

[Duplode]

Look at polygons facing down, such as the bottom of a car body.

Indeed - there is a very good illustration of that: the floor of the cargo section of LM002's car1. It has 0xFFFE0002 for Cull H and thus is only visible from above.

After looking a bit more at the culling data displays, I realized I understood them less than I thought, so I decided to finally build a debug shape (a cute pair of multicolored giant dices) and watch the bits in action systematically. Some of the observations actually enhanced my confusion, but others were quite definite. While you may well have realized quite a few of those already, I'll summarize them:

• Consider the position of visualization as being defined in a polar coordinate system centered at the polygon, with angular coordinates theta and phi. Theta is the horizontal plane angle (the one that acts as variable for Cull H), and phi is the vertical angle, defined so that phi=0 stands for a vertical POV and phi=90deg stands for an horizontal POV. The first remarkable fact is Cull H only acts for POVs with relatively large phi angles. That is, there is no horizontal culling for high camera positions. If you start with the F3 camera directly above a polygon, horizontal culling will only be seen after lowering the camera by 7 button presses.
• Additionally, Cull H only acts for relatively large distances from the polygon. On a flat surface, the threshold is about 17 button presses starting from maximum zoom.
• The way the negative direction half of Cull H operates on vertical polygons is still beyond my comprehension (well, that's not really a conclusion...)
• Perhaps the most clear-cut find of this list is the fact that the first flag of Cull H triggers polygon display for low values of phi and beyond a threshold radius. That is, if you zoom out enough and raise the camera with the flag turned off the polygon won't be displayed, period.
• And now for something (at least for me) perplexing: There is no such a thing as vertical culling. When you analyze simple debug shapes, the whole of Cull V (and, for that matter, the second Cull H flag) appear to be utterly purposeless. The very function of the first Cull H flag, as well as the patterns shown by the disks visualization, seem to indicate Cull V has no relation to vertical culling. On the other hand, the way those bits are set is too neat to be random... the only guess I can make about their function (based most on intuition, and very slightly on some stuff I've seen while toying with actual car models) is they are involved in some sort of occlusion-by-polygons mechanism, but it's just a weak conjecture at the moment. 

Overall, I find the facts above somewhat bewildering... but if they are correct, it might be feasible to work with less variables while implementing the rest of the culling stuff. At least for a while, maybe...

[dstien]

And finally, a rather wild suggestion on how to make the displaying/editing of culling data more transparent (if a bit more complicated): Perhaps the program might read the unknown flags, display them as checkboxes and then display the remaining 30 culling bits as a pair of 5-digit octals. That way, each octal digit would amount to exactly three circle sectors, and thus one would be able to read/write patterns more easily.

Done.

As for the vertex list remarks, there is another relevant characteristic of Stressed 3D editor associated to that issue: when you pick a polygon and edit one of its vertex coordinates, what Stressed actually does is to create a new vertex and replace the original one in the chosen polygon, instead of updating the old vertex position. Not only that makes it necessary to adjust all adjacent polygons to displace a vertex, it also means large-scale edition of complex 3D shapes with ~200 vertexes (some of the more detailed car0 shapes, like Corvette and Audi, have about that number IIRC) is probably impossible under Stressed.

I've implemented a compromise, check the "weld coexisting" box below the vertex list to update all vertices with the same position simultaneously. Stressed doesn't save any duplicated vertices, so scaling existing models is not a problem.

After looking a bit more at the culling data displays, I realized I understood them less than I thought, so I decided to finally build a debug shape (a cute pair of multicolored giant dices) and watch the bits in action systematically. Some of the observations actually enhanced my confusion, but others were quite definite.

Thanks for the details. Some of the culling data makes perfect sense, and some do not. Maybe some of it was edited manually by the game designers?

[CTG]

Only an idea for Stressed innovation: to make the car edition faster, it would be cool to have a special duplicating option which converts the new polygon to inverse X coordinates.

[Duplode]

Only an idea for Stressed innovation: to make the car edition faster, it would be cool to have a special duplicating option which converts the new polygon to inverse X coordinates.

On that same line, one addition I'd propose would be vertex reordering in polygons, so it would be easier to flip their faces. Anyway, both major recent changes - culling data displays and weld coexisting vertexes - were really useful and help a long way in making Stressed a capable 3D editor for Stunts shapes, in particular for testing and experimentation. Just one small thing, Dstien: it seems you inserted back that 49x line on shaperesource.cpp which (tries to) export wheels as lines. Could you please revert it to r35 behaviour? Thanks in advance 

Now, on to further experimentation: after a lot of head-scratching, I have a reasonable, semi-functional, theory on how the four culling bit sets work. Explaining it tersely:

• As you're probably aware, polygons have definite front and back sides. Which is which can be identified by applying a "left-hand grip rule" (analogous to this, only done with the left hand instead of the right one - the four fingers are supposed to be parallel to the polygon plane and then be rotated in the sense vertexes are ordered on Stressed. The thumb will then be pointing outwards.). Accordingly to the front/back distinction, the polygon plane divides the viewing space in two halves: one with POVs (viewpoints/points-of-view) facing the front of the polygon and the other with backside-facing POVs. The function of the 2-sided flag is to make the engine take both faces, and POVs, as frontal.
• The four sets of culling data and associated flags are active only for specific regions of the space (or POV sets, if you prefer):
  
  
  
  • CH+: Front-facing POVs from above
  • CH- : Front-facing POVs from below
  • CV+ : Back-facing POVs from above
  • CV- : Back-facing POVs from below
  Definitions of "above" and "below" aren't completely clear, but they seem to refer to above and below the median horizontal plane of the polygon. I assume that's what Dstien meant with positive and negative viewing directions as well.
• There is a culling cutoff radius, which is approximately equal to 17 zoom steps when looking the polygon from above. The culling data sets only are effective outside of this radius. Within the cutoff, visibility is exclusively determined by sidedness (front-facing = visible; back-facing = not visible), and both the 15-bit data sets and the associated flags are disregarded.
• There is a vertical angle cutoff, about 7 camera steps away down from a fully vertical angle. Due to limitations of F3 camera angles, this was only checked for from-above POVs. It is reasonable to assume a similar cutoff should exist for the opposite direction though. For vertical viewing angles high enough to be beyond the cutoff, the 15-bit data sets gets disregarded, and visibility is exclusively determined by the flags associated to CH/V data appropriate for the current POV. If the flag is on, the polygon will be always visible beyond the cutoff (within the high vertical angle cone), otherwise it won't be visible.
• The 15-bit culling data sets only are effective outside of the cutoff radius and below the high vertical angle cutoff. As identified by Dstien and displayed by the disk representations in Stressed, they define visibility ranges for horizontal angles within the region where the current POV is located (frontside/backside and above/below).

The scheme presented above seems to work well in most usual cases, in particular for vertical or near-vertical polygons. Sometimes it's hard to assess whether the expected results are being attained or not due to limitations on the viewing angles available from F3 camera (that is specially annoying when trying to identify culling at POVs from below). Horizontal polygons sometimes cause trouble too: the theory partly breaks apart when trying to make downwards-facing polygons visible from above, for instance - it seems that CH+ and CV+ both need to be set in such case (a good, and annoying, demonstration exercise is attempting to, without using two-sidedness, make the floor of a car visible from above (after making the roof/hood invisible), or tunnel roofs for that matter...). Nevertheless, a number of common culling data patterns seem to make sense now: for instance, the fact that front-facing from-above POVs are the ones which are the primary concern most of the time when modeling a car explains why I previously though only CH+ was relevant. On the other hand, when looking at a car floor it becomes apparent it's CH- which dictates its visibility. Some of the trends when comparing CH+ to CH-, CV+, etc. for horizontal, vertical and oblique polygons also begin to make sense from that perspective (and thus a method for generating them might be viable), although it seems the values were indeed hand-edited to some extent...