CMP to SUR Conversion Tests

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.

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=surexportersrc

And here is the importer source if it is useful:
http://eoa.seriouszone.com/download.php?file=surfileprograms

There are some other archives at the EOA that may be useful:
http://eoa.seriouszone.com/colinsanby.php

And 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??!!

That is amazing, LS. Well friggin’ done!

You’d have to be a modder to really appreciate this… to me it is more magnificent than the works of Michaelanglo (spelling?) I can’t wait to get out of the SUR making business.

Drools with anticipation…

As to Michaelangelo, you missed an e

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!

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.

Lancer, you say vertex = x,y,z … sounds similar to .obj format, do you mean it will be possible to use .obj meshes to generate a sur file?

If so that could be a good thing too, as .obj is a simple text format, it would then be possible to generate from 3ds Max and other modellers too, only needing to export the .cmp from Milkshape?