Re: NEED INFO: TEXTUREASSIGN PROGRAMMATION

Replies | Reply | Tomb Raider Level Editor & Utility Discussion Forum

Posted by E.Popov on May 04, 2000 at 10:13:47:

In reply to: NEED INFO: TEXTUREASSIGN PROGRAMMATION posted by BitShifter on May 02, 2000 at 20:31:57:

I think having all the data for one object in the same place would be good (as suggested by TPascal for an object library): so it means we should have all the texture data embodied with the object. Then, when we import this object into a level, we add these textures to the texture list. There are two possibilities here:

- we build an object from scratch. In this case, we can simplify the texture management saying that all texture data for this object are contained in a rectangular map, and it's up to the object maker to put what he wants in this rectangle.

- we reuse objects from TR1/2/3/4: it's the hard part because texture fragments for an object are spanned all over the texture tiles. So we have to collect them all (not difficult) and then rebuild a rectangular map to put them in: can be very difficult if we try to minimize the area covered by these fragments (in fact, the problem is: I have a given number of triangles / quadrilaterals of any shape (not necessarily axis aligned / square angle - these are tr2_object_texture elements), and I want to reorganize them to cover the minimal rectangular area. Another constraint is that the width of the resulting rectangle must be 256... Sounds not easy). Another possibility is to collect the fragments, put them in a 256xY texture map in the order we encounter them, then let the object maker optimize this map. That should be easy to code, but put the burden on the object maker... I think that's the way I'm going to take to start with to implement in TRViewer the drag & drop of meshes / moveables between levels.

Thinking about the "minimizing area coverage"...It should be a lot easier if we could assume that quadrilaterals / triangles are in fact rectangles / square triangles with their sides horizontal or vertical... Maybe it's the case in the TR levels (though the tr2_object_texture_vert doest not enforce this) ? When we browse the texture tiles, we clearly notice that fragments are square or rectangular, but nothing prevents a designer to put the coordinates he wants in tr2_object_texture_vert structures. Maybe I will make a little tool to check that.

E.Popov

Replies:

Shape of texture fragments E.Popov 16:53:08 5/04/00 (6)
- Re: Shape of texture fragments BitShifter 06:56:53 5/05/00 (5)
  - RE: Shape of texture fragments E.Popov 11:32:29 5/05/00 (4)
    - Re: RE: Shape of texture fragments BitShifter 11:49:32 5/05/00 (3)
      - RE: texture rotated E.Popov 16:49:09 5/05/00 (0)
      - texture rotated Turbo Pascal 15:32:15 5/05/00 (1)
        
        Re: texture rotated BitShifter 20:46:13 5/06/00 (0)

Name:

Email:

Subject:

Message:
: I think having all the data for one object in the same place would be good (as suggested by TPascal for an object library): so it means we should have all the texture data embodied with the object. Then, when we import this object into a level, we add these textures to the texture list. There are two possibilities here: : - we build an object from scratch. In this case, we can simplify the texture management saying that all texture data for this object are contained in a rectangular map, and it's up to the object maker to put what he wants in this rectangle. : - we reuse objects from TR1/2/3/4: it's the hard part because texture fragments for an object are spanned all over the texture tiles. So we have to collect them all (not difficult) and then rebuild a rectangular map to put them in: can be very difficult if we try to minimize the area covered by these fragments (in fact, the problem is: I have a given number of triangles / quadrilaterals of any shape (not necessarily axis aligned / square angle - these are tr2_object_texture elements), and I want to reorganize them to cover the minimal rectangular area. Another constraint is that the width of the resulting rectangle must be 256... Sounds not easy). Another possibility is to collect the fragments, put them in a 256xY texture map in the order we encounter them, then let the object maker optimize this map. That should be easy to code, but put the burden on the object maker... I think that's the way I'm going to take to start with to implement in TRViewer the drag & drop of meshes / moveables between levels. : Thinking about the "minimizing area coverage"...It should be a lot easier if we could assume that quadrilaterals / triangles are in fact rectangles / square triangles with their sides horizontal or vertical... Maybe it's the case in the TR levels (though the tr2_object_texture_vert doest not enforce this) ? When we browse the texture tiles, we clearly notice that fragments are square or rectangular, but nothing prevents a designer to put the coordinates he wants in tr2_object_texture_vert structures. Maybe I will make a little tool to check that. : E.Popov

Optional
Link URL:

Link Title:

Image URL:

Replies | Reply | Tomb Raider Level Editor & Utility Discussion Forum