CMP to SUR Conversion Tests
-
**I did a raw string dump of all of the exes,dlls,cmps,mats,txms,3dbs & utfs in FL, converted them to CRC values. No luck. It is the same routine I used to find those missing sound hashes used in FLEC. IMO its a sur that didn’t get remade when they made a change to the Border World models. A binary search only turned up a relevant CRC in those specific sur files. It could also be dummy nodes like those used for the sur splicer, as far I can tell, they don’t exist anywhere else…
Thanks Adoxa, BTW, like the format on the output files the SurDump makes, nice and clean. Nice touch on the Offset in the face list ;)**
-
**OK, one value left to figure out, the colors in the bits section…
The type 5 face list acts like a sort of shrink wrap on the mesh. It doesn’t take hits but it links all of a specific parts of the sur together (as in the Root sur part) by having faces that attach to each mesh. Look at the Liberty battleship for example. In that it looks like the ship is inside of a plastic bag but when you shoot it u don’t hit the bag.
I now have an opposite face calculation routine completed. It was listed in the face list as ‘Index’ a few pages back. How this works is that I create a normalized normal vector for each face then do a non-squared dot product of the normal vector between faces. The one with the largest negative dot product (that means it facing away from that face by more than 90 degrees) is selected to be the opposite face (excluding the same face). Hehe, I’m sure this sounds like Greek to most of ya so don’t worry about it, I have the math part covered.
So at this point there is only 1 part left to crack, once thats done then I will post a fully updated sur format file…**
-
LS, you may want to read one of adoxa’s reply a little up… He says they’re not color bits
-
True, they aren’t colors, just simply referring to them as I listed them a few pages back. Too bad it isn’t that simple
-
Sorry if I’m throwing in a wobbly…
They do look like ‘RedGreenBlueAlpha’ don’t they.
But - are these numbers anything to do with checking normals?
Some time ago I remember a post about normals being important in collision meshes (or absence of them maybe)?
-
well would be logical? but normals just define which way the face is… well er… facing… lol i think? XD
-
Normals are vectors which are perfectly perpendicular to any 2D plane. By using normals, you can determine the orientation of the plane and calculate things such as lighting. Normals oriented in the wrong direction cause “flipped” polygons.
However, I don’t see why a normal would have four values. Three should be plenty?
Also, something I noted on most if not all custom SURs: stars shine through them. If you look at a full custom SUR which works for collisions, you can often see a part of the star’s texture through it, as if the model wasn’t there. I do not know if it is a SUR or a CMP problem, but it’s rather odd.
-
**Looking at the code that Adoxa pointed out, only the RGB part is used. Each one is a byte in size. So far the only thing that really seems to have any relation to it that I can see is the radius value listed right above it. if the radius is the same between 2 bits section and the centers are different, the color value is exactly the same.
As far as it being a normal, don’t know at this point. In the code each color is converted to a unsigned float before it is used. The radius value is multiplied by 0.004 then multiplied by each of the color values.
BTW, does anyone have a copy of the source for the MS sur exporter 1.1?**
-
I don’t have 1.1 source - Louva Deus may well have it.
But to save you time, here is the link for 1.2b3 if you don’t already have it, or for anyone else that needs it:
http://eoa.seriouszone.com/download.php?file=surexportersrcAnd here is the importer source if it is useful:
http://eoa.seriouszone.com/download.php?file=surfileprogramsThere are some other archives at the EOA that may be useful:
http://eoa.seriouszone.com/colinsanby.phpAnd also check the side panel on that page for more.
-
Here is my decompilation of the function that makes use of the “RGB” values. I’ve used my names, this time.
// It's not actually this, but some sort of dynamic array. std::vector <theader*>THeaderVec; // Common.0634a9b0 (v1.1) // ecx points to six floats, looks to be the bounding box. Not used, though. void Extents::FindTriangleGroup( Bit* bit, // esi const Vector& centre, // ebp float radius, THeaderVec& face_list ) // ebx { for (;;) { float dx = bit->centre.x - centre.x; float dy = bit->centre.y - centre.y; float dz = bit->centre.z - centre.z; if ((radius + bit->radius) * (radius + bit->radius) < dx*dx + dy*dy + dz*dz) return; float scale_radius = bit->radius / 250; if (scale_radius * bit->scale.x + radius <= fabsf( dx )) return; if (scale_radius * bit->scale.y + radius <= fabsf( dy )) return; if (scale_radius * bit->scale.z + radius <= fabsf( dz )) return; THeader* group; if (bit->tri) { group = (THeader*)((char*)bit + bit->tri); // edi if (group) // ? this will always be true break; } if (bit->sibling) { FindTriangleGroup( bit + 1, centre, radius, face_list ); bit = (Bit*)((char*)bit + bit->sibling)); } else { group = (THeader*)((char*)bit + bit->tri); // edi if (group->triangles == 2) { // triangle_list is simply the triangles after the header. if (radius * radius < unknown( group, group->triangle_list, centre ) return; } break; } } face_list.push_back( group ); }</theader*> ```There, that's one function down…
-
Keep it up adoxa, many thanks for your excellent help to Lancer, between you two we hope for a new evolution to model making!
I feel so… where’s my toy digger again??!!
-
**Ok, just had to learn a whole new branch of mathematics. I have had to learn how to create convex hulls based on an arbitrary mesh. This will be implemented into the sur conversion routine soon to do the sur linkage mesh. Here is an example of the Nomad Lair hull being built and animated.
[wmp=640,480]http://digitalbrilliance.org/Files/ConvexHull.wmv[/wmp]**
-
That is amazing, LS. Well friggin’ done!
-
FWIW, I’ve put up one more final revision of my Sur Dumper. Fixes a bug where ScaleZ was output using ScaleY’s value; displays the scale values as decimal fractions; and adds an option to prefix relevant lines with the file offset.
-
Thank you again Adoxa.
By the way, all I see in the video is the sur being drawn in about 1.5 secs, there is no lair shape - is that correct or is there more I can’t see?
Waiting with 'bated breath for the sur generator, Lancer!
-
**You should see it being built then then the background turns blue and the model rotates.
The model is nomad_lair.cmp in solar/dockable**
-
How are you getting along with it, LS?
We could really use the SUR LODs, having highly complex surs when near, but having more simple surs when far away.
Seeing that you have a good understanding of the file structure, could you build some sort of sur-builder where you simply pass in geometry to be used for the different sur-lods and other parts of the sur file format?
That would be really great.
While a simple cmp to sur converter is cool, I think in most cases it would have the problem of producing too complex surs.
-
Odd, it builds and stops and returns to zero without turning blue or rotating. I see only the sur wireframe being built. I’m using firefox.