opengl 3d second tryout

[zawran]

It turned out to be a combination of the upside down texture coords you mention and my mistake of reversing the UV, so that U were stored as V and vice versa.



This is how it looks so far: http://zac-interactive.dk/temp/oglloader2.zip

[hellfire]

Well done!
Now it's time to read the vertex-normals, too

[Pixel_Outlaw]

Looks like you are progressing quickly. Amazing what you have done in 2 days.

[zawran]

So far what I have done is recalculate the normals based on the orientation of the polys after loading the object. I have not been able to figure out, what chunk of the 3ds file is the normal values, if they are there at all. The following information is what I have been working with to decipher the format:

Code: [Select]

                              1. Introduction
                          ======================

   The 3ds file format is made up of chunks. They describe what information
   is to follow and what it is made up of, it's ID and the location of the
   next block. If you don't understand a chunk you can quite simply skip it.
   The next chunk pointer is relative to the start of the current chunk and
   in bytes. The binary information in the 3ds file is written in a special
   kind of way. Namely the lest significant byte comes first in an int.
   For example: 4A 5C  (2 bytes in hex) would be 5C high byte and 4A low
   byte. In a long it is: 4A 5C 3B 8F where 5C4A is the low word and 8F 3B
   is the high word. And now for the chunks. A chunk is defined as:

   start end size name
   0     1   2    Chunk ID
   2     5   4    Pointer to next chunk relative to the place where
                  Chunk ID is, in other words the length of the chunk

   Chunks have a hierarchy imposed on them that is identified byt it's ID.
   A 3ds file has the Primary chunk ID 4D4Dh. This is always the first
   chunk of the file. Within the primary chunk are the main chunks.

   to give you a preview and a reference to the hierarchy of chunks,
   below is a diagram to show the diffrent chunk ID's and their place
   in the file. The chunks are given a name because below the diagram is
   a list which defines the names to the actual chunk id's. This makes it
   easier to put it in some source code ( how convenient that some sample
   code is included )


                  MAIN3DS  (0x4D4D)
                  |
                  +--EDIT3DS  (0x3D3D)
                  |  |
                  |  +--EDIT_MATERIAL (0xAFFF)
                  |  |  |
                  |  |  +--MAT_NAME01 (0xA000) (See mli Doc)
                  |  |
                  |  +--EDIT_CONFIG1  (0x0100)
                  |  +--EDIT_CONFIG2  (0x3E3D)
                  |  +--EDIT_VIEW_P1  (0x7012)
                  |  |  |
                  |  |  +--TOP            (0x0001)
                  |  |  +--BOTTOM         (0x0002)
                  |  |  +--LEFT           (0x0003)
                  |  |  +--RIGHT          (0x0004)
                  |  |  +--FRONT          (0x0005)
                  |  |  +--BACK           (0x0006)
                  |  |  +--USER           (0x0007)
                  |  |  +--CAMERA         (0xFFFF)
                  |  |  +--LIGHT          (0x0009)
                  |  |  +--DISABLED       (0x0010) 
                  |  |  +--BOGUS          (0x0011)
                  |  |
                  |  +--EDIT_VIEW_P2  (0x7011)
                  |  |  |
                  |  |  +--TOP            (0x0001)
                  |  |  +--BOTTOM         (0x0002)
                  |  |  +--LEFT           (0x0003)
                  |  |  +--RIGHT          (0x0004)
                  |  |  +--FRONT          (0x0005)
                  |  |  +--BACK           (0x0006)
                  |  |  +--USER           (0x0007)
                  |  |  +--CAMERA         (0xFFFF)
                  |  |  +--LIGHT          (0x0009)
                  |  |  +--DISABLED       (0x0010) 
                  |  |  +--BOGUS          (0x0011)
                  |  |
                  |  +--EDIT_VIEW_P3  (0x7020)
                  |  +--EDIT_VIEW1    (0x7001)
                  |  +--EDIT_BACKGR   (0x1200)
                  |  +--EDIT_AMBIENT  (0x2100)
                  |  +--EDIT_OBJECT   (0x4000)
                  |  |  |
                  |  |  +--OBJ_TRIMESH   (0x4100)     
                  |  |  |  |
                  |  |  |  +--TRI_VERTEXL          (0x4110)
                  |  |  |  +--TRI_VERTEXOPTIONS    (0x4111)
                  |  |  |  +--TRI_MAPPINGCOORS     (0x4140)
                  |  |  |  +--TRI_MAPPINGSTANDARD  (0x4170)
                  |  |  |  +--TRI_FACEL1           (0x4120)
                  |  |  |  |  |
                  |  |  |  |  +--TRI_SMOOTH            (0x4150)   
                  |  |  |  |  +--TRI_MATERIAL          (0x4130)
                  |  |  |  |
                  |  |  |  +--TRI_LOCAL            (0x4160)
                  |  |  |  +--TRI_VISIBLE          (0x4165)
                  |  |  |
                  |  |  +--OBJ_LIGHT    (0x4600)
                  |  |  |  |
                  |  |  |  +--LIT_OFF              (0x4620)
                  |  |  |  +--LIT_SPOT             (0x4610)
                  |  |  |  +--LIT_UNKNWN01         (0x465A)
                  |  |  |
                  |  |  +--OBJ_CAMERA   (0x4700)
                  |  |  |  |
                  |  |  |  +--CAM_UNKNWN01         (0x4710)
                  |  |  |  +--CAM_UNKNWN02         (0x4720) 
                  |  |  |
                  |  |  +--OBJ_UNKNWN01 (0x4710)
                  |  |  +--OBJ_UNKNWN02 (0x4720)
                  |  |
                  |  +--EDIT_UNKNW01  (0x1100)
                  |  +--EDIT_UNKNW02  (0x1201)
                  |  +--EDIT_UNKNW03  (0x1300)
                  |  +--EDIT_UNKNW04  (0x1400)
                  |  +--EDIT_UNKNW05  (0x1420)
                  |  +--EDIT_UNKNW06  (0x1450)
                  |  +--EDIT_UNKNW07  (0x1500)
                  |  +--EDIT_UNKNW08  (0x2200)
                  |  +--EDIT_UNKNW09  (0x2201)
                  |  +--EDIT_UNKNW10  (0x2210)
                  |  +--EDIT_UNKNW11  (0x2300)
                  |  +--EDIT_UNKNW12  (0x2302)
                  |  +--EDIT_UNKNW13  (0x2000)
                  |  +--EDIT_UNKNW14  (0xAFFF)
                  |
                  +--KEYF3DS (0xB000)
                     |
                     +--KEYF_UNKNWN01 (0xB00A)
                     +--............. (0x7001) ( viewport, same as editor )
                     +--KEYF_FRAMES   (0xB008)
                     +--KEYF_UNKNWN02 (0xB009)
                     +--KEYF_OBJDES   (0xB002)
                        |
                        +--KEYF_OBJHIERARCH  (0xB010)
                        +--KEYF_OBJDUMMYNAME (0xB011)
                        +--KEYF_OBJUNKNWN01  (0xB013)
                        +--KEYF_OBJUNKNWN02  (0xB014)
                        +--KEYF_OBJUNKNWN03  (0xB015) 
                        +--KEYF_OBJPIVOT     (0xB020) 
                        +--KEYF_OBJUNKNWN04  (0xB021) 
                        +--KEYF_OBJUNKNWN05  (0xB022) 

 
 A chunk type which you can find all through the file are the color chunks
 which are called:

 COL_RGB
 COL_TRU
 COL_UNK



                             2. Chunks anyone ?
                         =========================

 Now for the actual numbers, as you will see I used the define, because I
 ripped that part right out of my code. Be carefull however because there
 are a lot of new chunk types which were not documented in the original
 paper by Jim Pitts.

 //------ Primary chunk

 #define MAIN3DS       0x4D4D

 //------ Main Chunks

 #define EDIT3DS       0x3D3D  // this is the start of the editor config
 #define KEYF3DS       0xB000  // this is the start of the keyframer config

 //------ sub defines of EDIT3DS

 #define EDIT_MATERIAL 0xAFFF
 #define EDIT_CONFIG1  0x0100
 #define EDIT_CONFIG2  0x3E3D
 #define EDIT_VIEW_P1  0x7012
 #define EDIT_VIEW_P2  0x7011
 #define EDIT_VIEW_P3  0x7020
 #define EDIT_VIEW1    0x7001
 #define EDIT_BACKGR   0x1200
 #define EDIT_AMBIENT  0x2100
 #define EDIT_OBJECT   0x4000

 #define EDIT_UNKNW01  0x1100
 #define EDIT_UNKNW02  0x1201
 #define EDIT_UNKNW03  0x1300
 #define EDIT_UNKNW04  0x1400
 #define EDIT_UNKNW05  0x1420
 #define EDIT_UNKNW06  0x1450
 #define EDIT_UNKNW07  0x1500
 #define EDIT_UNKNW08  0x2200
 #define EDIT_UNKNW09  0x2201
 #define EDIT_UNKNW10  0x2210
 #define EDIT_UNKNW11  0x2300
 #define EDIT_UNKNW12  0x2302
 #define EDIT_UNKNW13  0x3000
 #define EDIT_UNKNW14  0xAFFF

 //------ sub defines of EDIT_OBJECT
 #define OBJ_TRIMESH   0x4100
 #define OBJ_LIGHT     0x4600
 #define OBJ_CAMERA    0x4700

 #define OBJ_UNKNWN01  0x4010
 #define OBJ_UNKNWN02  0x4012 //---- Could be shadow

 //------ sub defines of OBJ_CAMERA
 #define CAM_UNKNWN01  0x4710
 #define CAM_UNKNWN02  0x4720

 //------ sub defines of OBJ_LIGHT
 #define LIT_OFF       0x4620
 #define LIT_SPOT      0x4610
 #define LIT_UNKNWN01  0x465A

 //------ sub defines of OBJ_TRIMESH
 #define TRI_VERTEXL   0x4110
 #define TRI_FACEL2    0x4111
 #define TRI_FACEL1    0x4120
 #define TRI_SMOOTH    0x4150
 #define TRI_LOCAL     0x4160
 #define TRI_VISIBLE   0x4165

 //------ sub defs of KEYF3DS

 #define KEYF_UNKNWN01 0xB009
 #define KEYF_UNKNWN02 0xB00A
 #define KEYF_FRAMES   0xB008
 #define KEYF_OBJDES   0xB002

 //------  these define the different color chunk types
 #define COL_RGB  0x0010
 #define COL_TRU  0x0011
 #define COL_UNK  0x0013

 //------ defines for viewport chunks

 #define TOP           0x0001
 #define BOTTOM        0x0002
 #define LEFT          0x0003
 #define RIGHT         0x0004
 #define FRONT         0x0005
 #define BACK          0x0006
 #define USER          0x0007
 #define CAMERA        0x0008 // 0xFFFF is the actual code read from file
 #define LIGHT         0x0009
 #define DISABLED      0x0010
 #define BOGUS         0x0011



 
                            3. 3D Editor Chunks
                       ===========================

 So far for the quick stuff now the more detailed info.

 * Main chunks

 The main chunk ( the primary chunk of 0x4D4D that is ) is actually the
 complete file. So the size of this chunk is the size of the file minus
 the main chunk header.

 There are two more main chunks, the 3d-editor chunk and the keyframer
 chunk:

   id

  3D3D Start of Editor data  ( this is also the place where the objects are )
  B000 Start of Keyframer data

  Directly after a Main chunk is another chunk. This could be any other type
  of chunk allowable within its main chunks scope. ( see diagram )

 * Subchunks of 3D3D
  id   Description
 0100  Part of configuration
 1100  unknown
 1200  Background Color
 1201  unknown
 1300  unknown
 1400  unknown
 1420  unknown
 1450  unknown
 1500  unknown
 2100  Ambient Color Block
 2200  fog ?
 2201  fog ?
 2210  fog ?
 2300  unknown
 3000  unknown
 3D3E  Editor configuration main block
 4000  Definition of an Object
 AFFF  Start of material list

 * Subchunks of AFFF - Start of material list
 * A000 - material name
 - This chunk contains the name of the material which is an ASCIIZ string

 (
   More material chunks are explained in the doc about 3d-studio .mli
   files. The chunk types mentioned in that doc are exactly the same
   as in the .3ds file
 )

 * Subchunks of 3D3E - Editor configuration

  id   Description
 7001  Start of viewport indicator
 7011  Viewport definition ( type 2 )
 7012  Viewport definition ( type 1 )
 7020  Viewport definition ( type 3 )

 The 3D3E chunk is a curious one because it contains a lot of redundant
 data. ( or so it seems ) The most important chunk is 7020. this chunk
 describes the 4 viewports wich are active in the editor. I assume that
 U are using the 4 normal viewport layout, because I have not tested it
 with other configurations. The editor confid will contain 5x chunk 7020
 and 5x chunk 7011. only the first 4 7020 chunks are important for how
 the viewports look like. I guess that the other chunks only give additional
 info, but I am not sure. The things you are looking for in these chunks is
 at byte: 6 & 7 ( as offset from the first 6 bytes chunk header and pointer )
 these bytes ( unsigned int ) contain the info at to what view is used, with
 the following id's:

  id    Description
 0001   Top
 0002   Bottom
 0003   Left
 0004   Right
 0005   Front
 0006   Back
 0007   User
 FFFF   Camera
 0009   Light
 0010   Disabled

 * Subchunks of 4000 - Object description Block

 - first item of Subchunk 4000 is an ASCIIZ string of the objects name.
   ASCIIZ means a string of charakters ended by a zero.

 Remember an Object can be a Camera a Light or a mesh
  id      Description
 4010     unknown
 4012     shadow ?
 4100     Triangular Polygon List ( Contains only subchunks )
 4600     Light
 4700     Camera

 ( Mapping:

   These chunks are optional. They stand just after the vertex list when
   the object is mapped. )
 
 * Subchunks of 4100 - Triangular Polygon List

  id      Description
 4110     Vertex List
 4111     Vertex Options
 4120     Face List
 4130     Face Material
 4140     Mapping Coordinates
 4150     Face smoothing group
 4160     Translation Matrix
 4165     Object visible/invisble
 4170     Standard Mapping

 * 4110 - Vertex List

   start end size type          name
   0     1    2   unsigned int  Total vertices in object
   2     5    4   float         X-value
   6     9    4   float         Y-value
  10    13    4   float         Z-value

 bytes 2..13 are repeated times the total amount of vertices in the object

 * 4111 - Vertex Options

 First 2 bytes: number of vertices.

 Then a short int for each vertex:

 bit 0-7    0
 bit 8-10   x
 bit 11-12  0
 bit 13   vertex selected in selection 3
 bit 14   vertex selected in selection 2
 bit 15   vertex selected in selection 1

 bit 8-10 are just like random. From a save to another of the same scene
 it may change.
 
 Other bits (0-7 and 11-12) have effects on visibility of vertex.

 The 4111 chunk can be deleted without much influence, 3ds will still load
 the file all right.


 * 4120 - Face list

 start end size type          name
 0     1    2   unsigned int  total polygons in object (numpoly)

 2     3    2   unsigned int  number of vertex A
 4     5    2   unsigned int  number of vertex B
 6     7    2   unsigned int  number of vertex C
 8     9    2   unsigned int  face info (*)

 repeats 'numpoly' times for each polygon.

 The first three ints are the three vertices of the face.
 0 stands for the first vertex defined in the vertex list.
 The order has a purpose: to give the direction for the normal
 of each face.
 If you turn a screw (standard screw) in the way the vertices
 indicate you will find the normal.
 If vertices given in order are A B C:

               C
               ^
               |
        A-----B

 This means unscrewing = the normal points out of the screen.

 (*) this number is is a binary number which expands to 3 values.
     for example 0x0006 would expand to 110 binary. The value should be
     read as 1 1 0 .This value can be found in 3d-studio ascii files as
     AB:1 BC:1 AC:0 .Which probably indicated the order of the vertices.
     For example AB:1 would be a normal line from A to B. But AB:0 would
     mean a line from B to A.

     bit 0       AC visibility
     bit 1       BC visibility
     bit 2       AB visibility
     bit 3       Mapping (if there is mapping for this face)
     bit 4-8   0 (not used ?)
     bit 9-10  x (chaotic ???)
     bit 11-12 0 (not used ?)
     bit 13      face selected in selection 3
     bit 14      face selected in selection 2
     bit 15      face selected in selection 1

 * 4130 - Face Material Chunk

   If the object is all default material there is no 4130 chunk.
   In fact, there is one 4130 chunk for each material present on the object.

   Each 4130 face material chunks begins with an asciiz of a material,
   then after the null character is a short int that gives the number
   of faces of the object concerned by this material, then there is the
   list itself of these faces. 0000 means the first face of the (4120)
   face list.

   ************ Read the Doc on MLI files for more info on **************
   ************ Mapping and Materials                      **************

 * 4140 Mapping coordinates.

   First 2 bytes: number of vertices.

   Then, for each vertex 2 floats that give the mapping coordinates.
   That is, if a point is at the center of the map it will have 0.5 0.5
   as mapping coordinates.

 * 4150 - Face Smoothing Group

   nfaces*4bytes

   If read as long int, the nth bit indicate if the face belongs or not
   to the nth smoothing group.

 * 4160 Local axis

   Local axis info.
   The three first blocks of three floats are the definition
   (in the absolute axis) of the local axis X Y Z of the object.
   And the last block of three floats is the local center of the object.
 
 
 * 4170 Standard mapping

   First 2 bytes: type of mapping
   0 = plannar or specific (in this case, like mapping from the lofter,
                            the information of this chunk is irrelevant)
   1 = cylindrical
   2 = spherical

   then come 21 floats that describe the mapping.

* 4600 - Light

   start end size type   name
   0      3    4  float  Light pos X
   4      7    4  float  Light pos Y
   8     11    4  float  Light pos Z

   after this structure check for more chunks.

   id      Description ( full description later )
  0010     RGB color
  0011     24 bit color
  4610     Light is a Spot light
  4620     Light is off/on ( Boolean )

* 4610 - Spot Light

  start end size type   name
   0     3    4  float  Target pos X
   4     7    4  float  Target pos X
   8    11    4  float  Target pos X
  12    15    4  float  Hotspot
  16    19    4  float  Falloff

* 0010 - RGB Color

  start end size type   name
   0     3   4   float  Red
   4     7   4   float  Green
   8    11   4   float  Blue

* 0011 - RGB Color - 24 bit

  start end size type   name
   0    1    1   byte   Red
   1    1    1   byte   Green
   2    2    1   byte   Blue

* 4700 - Camera

 Describes the details of the camera in the scene

 start end size type   name
  0     3   4   float  Camera pos X
  4     7   4   float  Camera pos Y
  8    11   4   float  Camera pos Z
 12    15   4   float  Camera target X
 16    19   4   float  Camera target X
 20    23   4   float  Camera target X
 24    27   4   float  Camera bank ( rotation angle )
 28    31   4   float  Camera lens







                           4. Keyframer Chunks
                       ==========================



 * Keyframer chunk

  id         Description
 B00A        unknown
 7001        See first description of this chunk
 B008        Frames
 B009        unknown
 B002        Start object description

 * B008 - Frame information

 simple structure describing frame info

 start end size type            name
   0    3    4  unsigned long   start frame
   4    7    4  unsigned long   end frame

 *B002 - Start of Object info

 Subhunks

  id     Description
 B010    Name & Hierarchy
 B011*   Name Dummy Object
 B013    unknown
 B014*   unknown
 B015    unknown
 B020    Objects pivot point ?
 B021    unknown
 B022    unknown

 * B010 - Name & Hierarchy descriptor

 start end  size type          name
 0      ?    ?   ASCIIZ        Object name
 ?      ?    2   unsigned int  unknown
 ?      ?    2   unsigned int  unknown
 ?      ?    2   unsigned int  Hierarchy of Object

 The object hierarchy is a bit complex but works like this.
 Each Object in the scene is given a number to identify its
 order in the tree. Also each object is orddered in the 3ds
 file as it would appear in the tree.
 The root object is given the number -1 ( FFFF ).
 As the file is read a counter of the object number is kept.
 Is the counter increments the objects are children of the
 previous objects. But when the pattern is broken by a number
 what will be less than the current counter the hierarchy returns
 to that level.

 for example.

    object   hierarchy
    name

        A      -1
        B       0                 This example is taken
        C       1                 from 50pman.3ds
        D       2
        E       1                 I would really reccomend
        F       4                 having a look at one of the
        G       5                 examples with the hierarchy
        H       1                 numbers to help work it out.
        I       7
        J       8
        K       0
        L      10
        M      11
        N       0
        O      13
        P      14


                           A
         +-----------------+----------------+
         B                 K                N
    +----+----+            |                |
    C    E    H            L                O
    |    |    |            |                |
    D    F    I            M                P
         |    |
         G    J

 Still not done with this chunk yet !
 If the object name is $$$DUMMY then it is a dummy object
 and therefore you should expect a few extra chunks.

 * B011 - Dummy objects name.

    Names a dummy object. ASCIIZ string.

 * B020 - Pivot Point ?

 The Objects pivot point. Not quite sure what the first five floats do yet
 ( ideas ?).

 start end size type   name
   0    3    4  float  unknown
   4    7    4  float  unknown
   8   11    4  float  unknown
  12   16    4  float  unknown
  16   19    4  float  unknown
  20   23    4  float  unknown
  24   27    4  float  Pivot Y
  28   32    4  float  Pivot X



     
                                 5. CODE
                       =============================

 
 !!!!!!!!!!! The source code is not UP-TO-DATE it is written after rev 0.9
 of this Doc It will be updated when I can find the time ( or maybe YOU can)
 If the code looks like it has been written by a a twelve year old, then
 looks do decieve, I like very simple and easy to read source code. All that
 matters is that it does the trick.


-----------------------------88-------------------------------


/*----------------------------------------------------------------------------*\
     This is a lib which reads 3d-studio binary files from version 3.0
     and higher
     (v1.05)
     author: Martin van Velsen
             ( and some great help by Gert van der Spoel )
     email:  vvelsen@ronix.ptf.hro.nl

     If you happen to come across some variables with strange names, then
     that will possible be Dutch names, sorry for that :)
\*----------------------------------------------------------------------------*/
#ifndef __3DSBIN_H__
#define __3DSBIN_H__

#include <stdio.h
#include <string.h
#include <stdlib.h
#include <conio.h   // IF you are on a dos system
#include <dos.h     // IF you are on a dos system

//------ tools

#define __DEBUG__          0

#define TRUE               0
#define FALSE              1

//------ Id Chunk

#define MAIN3DS       0x4D4D

//------ Main Chunks

#define EDIT3DS       0x3D3D  // this is the start of the editor config
#define KEYF3DS       0xB000  // this is the start of the keyframer config

//------ sub defines of EDIT3DS

#define EDIT_MATERIAL 0xAFFF
#define EDIT_CONFIG1  0x0100
#define EDIT_CONFIG2  0x3E3D
#define EDIT_VIEW_P1  0x7012
#define EDIT_VIEW_P2  0x7011
#define EDIT_VIEW_P3  0x7020
#define EDIT_VIEW1    0x7001
#define EDIT_BACKGR   0x1200
#define EDIT_AMBIENT  0x2100
#define EDIT_OBJECT   0x4000

#define EDIT_UNKNW01  0x1100
#define EDIT_UNKNW02  0x1201
#define EDIT_UNKNW03  0x1300
#define EDIT_UNKNW04  0x1400
#define EDIT_UNKNW05  0x1420
#define EDIT_UNKNW06  0x1450
#define EDIT_UNKNW07  0x1500
#define EDIT_UNKNW08  0x2200
#define EDIT_UNKNW09  0x2201
#define EDIT_UNKNW10  0x2210
#define EDIT_UNKNW11  0x2300
#define EDIT_UNKNW12  0x2302 // new chunk type
#define EDIT_UNKNW13  0x3000
#define EDIT_UNKNW14  0xAFFF

//------ sub defines of EDIT_MATERIAL
#define MAT_NAME01    0xA000  // includes name (see mli doc for materials)

//------ sub defines of EDIT_OBJECT

#define OBJ_TRIMESH   0x4100
#define OBJ_LIGHT     0x4600
#define OBJ_CAMERA    0x4700

#define OBJ_UNKNWN01  0x4010
#define OBJ_UNKNWN02  0x4012 //---- Could be shadow

//------ sub defines of OBJ_CAMERA
#define CAM_UNKNWN01  0x4710 // new chunk type
#define CAM_UNKNWN02  0x4720 // new chunk type

//------ sub defines of OBJ_LIGHT
#define LIT_OFF       0x4620
#define LIT_SPOT      0x4610
#define LIT_UNKNWN01  0x465A

//------ sub defines of OBJ_TRIMESH
#define TRI_VERTEXL   0x4110
#define TRI_FACEL2    0x4111 // unknown yet
#define TRI_FACEL1    0x4120
#define TRI_SMOOTH    0x4150
#define TRI_LOCAL     0x4160
#define TRI_VISIBLE   0x4165

//------ sub defs of KEYF3DS

#define KEYF_UNKNWN01 0xB009
#define KEYF_UNKNWN02 0xB00A
#define KEYF_FRAMES   0xB008
#define KEYF_OBJDES   0xB002

#define KEYF_OBJHIERARCH  0xB010
#define KEYF_OBJDUMMYNAME 0xB011
#define KEYF_OBJUNKNWN01  0xB013
#define KEYF_OBJUNKNWN02  0xB014
#define KEYF_OBJUNKNWN03  0xB015 
#define KEYF_OBJPIVOT     0xB020 
#define KEYF_OBJUNKNWN04  0xB021 
#define KEYF_OBJUNKNWN05  0xB022 

//------  these define the different color chunk types
#define COL_RGB  0x0010
#define COL_TRU  0x0011
#define COL_UNK  0x0013 // unknown

//------ defines for viewport chunks

#define TOP           0x0001
#define BOTTOM        0x0002
#define LEFT          0x0003
#define RIGHT         0x0004
#define FRONT         0x0005
#define BACK          0x0006
#define USER          0x0007
#define CAMERA        0x0008 // 0xFFFF is the code read from file
#define LIGHT         0x0009
#define DISABLED      0x0010
#define BOGUS         0x0011


Looks like you are progressing quickly. Amazing what you have done in 2 days.

Thanks, although I must confess that I did try and get something working a couple of years ago, although most of what I figured out back then seems to have been lost somewhere in the back of my mind as I am finding it difficult to remember it again. This is probably the most progress I have had ever on raw opengl and 3d stuff, so I am quite happy with the progress myself

[hellfire]

To get the normal of a face's vertex you average the normals of all faces that share this vertex and have the same smoothing-group-id assigned.

[Hotshot]

Very good zawran

[zawran]

I figured out how to read the <4150 - Face Smoothing Group> chunk, and for the knot its 8640 (number of faces) times the same number 65536, so that doesn't seem to be of any use.

I have taken a look at the source code for the irrlicht graphics engine, and they also seem to be loading the smoothing group data, but I cannot see if they are using it for anything.

In any event, in order for me to do vertex normals, it looks like I will have to it manually. And I have found this explaination from the old flipcode site, which I will attempt first:

Code: [Select]

// Calculating vertex normals using a vertex list and polygon faces (vertex indices);

 loop through your vertex list {
       clear this_vertex_normal;    // initialized to [0,0,0]
       loop through your face lists {
                 for each face vertex, check if its
                 the same as the vertex as in our
                 current outer vertex loop.
                 If it is, { 
                          this_vertex_normal += this_face.normal;
                 }
       }
       this_vertex_normal.Normalize();
 }

They only had this psudo code together with an explaination, but I think its enough to get me started. But one thing I am wondering is, I only have to do this once for the model right? Not each update?

[Jim]

The simplest algorithm for vertex normals is to add together all the normals of the polygons that share the vertex and then renormalise.
That's what the pseudo code you posted is doing.

It's not a bad approximation.  See if you can think of scenarios where it doesn't work, and how the algorithm could be made better.

Jim

[zawran]

I tried another approach, which seems to almost work:



Here is what I am doing:

Code: [Select]

for each vertex
   set vertex normal to (0,0,0)
for each face
   add face normal to vertex normal of all vertices in face
for each vertex
   normalize vertex normal

It seems like this doesn't quite work where the seams are in the object.

[hellfire]

I figured out how to read the <4150 - Face Smoothing Group> chunk, and for the knot its 8640 (number of faces) times the same number 65536, so that doesn't seem to be of any use.

The knot is completely smooth shaded, so each vertex-normal is the average of all surrounding triangles and there's only one smoothing-group (which includes the whole mesh).
At a "hard" edge the polygons on the one side use one smoothing-group id and the polygons on the other side use another id.
Have a look at the attached cylinder for example.

There's one special case you have to care for.
.3ds can only assign uv-coordinates per vertex. When two texture-boundaries meet at a vertex, the only solution to assign proper uvs is to duplicate that vertex.
But two adjacent faces that were sharing this vertex now use different vertices.
So you'll need to find duplicate vertex-positions to compensate the problem.

[zawran]

I got hold of a cube 3ds file, and it has 26 vertices and 26 texture uv coords. So not only does it have 2x the vertices needed to form a cube, it has 2 extra on top of that. And looking at the face data and vertex coords, it looks rather difficult finding out which are extra.

Code: [Select]

Vertices:
0: -10.0000000,-10.0000000,-10.0000000
1: -10.0000000,-10.0000000,10.0000000
2: -10.0000000,10.0000000,-10.0000000
3: -10.0000000,10.0000000,10.0000000
4: 10.0000000,-10.0000000,-10.0000000
5: 10.0000000,-10.0000000,10.0000000
6: 10.0000000,10.0000000,-10.0000000
7: 10.0000000,10.0000000,10.0000000
8: -10.0000000,-10.0000000,-10.0000000
9: -10.0000000,-10.0000000,10.0000000
10: 10.0000000,-10.0000000,10.0000000
11: 10.0000000,-10.0000000,10.0000000
12: 10.0000000,-10.0000000,-10.0000000
13: -10.0000000,-10.0000000,-10.0000000
14: -10.0000000,10.0000000,10.0000000
15: 10.0000000,-10.0000000,10.0000000
16: -10.0000000,10.0000000,10.0000000
17: -10.0000000,10.0000000,-10.0000000
18: 10.0000000,10.0000000,-10.0000000
19: 10.0000000,10.0000000,-10.0000000
20: 10.0000000,10.0000000,10.0000000
21: -10.0000000,10.0000000,10.0000000
22: -10.0000000,10.0000000,-10.0000000
23: 10.0000000,-10.0000000,-10.0000000
24: 10.0000000,-10.0000000,-10.0000000
25: -10.0000000,10.0000000,-10.0000000

Faces:
0: 3,2,0
1: 0,1,3
2: 7,5,4
3: 4,6,7
4: 10,9,8
5: 13,12,11
6: 7,14,1
7: 1,15,7
8: 18,17,16
9: 21,20,19
10: 23,0,22
11: 25,6,24

Texture UVs:
0: 1.00000000,1.00000000
1: 0.000000000,1.00000000
2: 1.00000000,0.000000000
3: 0.000000000,0.000000000
4: 0.000000000,1.00000000
5: 1.00000000,1.00000000
6: 0.000000000,0.000000000
7: 1.00000000,0.000000000
8: 0.000000000,1.00000000
9: 1.00000000,1.00000000
10: 1.00000000,0.000000000
11: 1.00000000,0.000000000
12: 0.000000000,0.000000000
13: 0.000000000,1.00000000
14: 1.00000000,1.00000000
15: 0.000000000,0.000000000
16: 0.000000000,1.00000000
17: 1.00000000,1.00000000
18: 1.00000000,0.000000000
19: 1.00000000,0.000000000
20: 0.000000000,0.000000000
21: 0.000000000,1.00000000
22: 0.000000000,1.00000000
23: 1.00000000,0.000000000
24: 1.00000000,0.000000000
25: 0.000000000,1.00000000

So far I have not found much mention of this problem in the pages I have read so far while looking for examples of loading 3ds files, so either people are not aware of this, or they are forgetting to mention it. But I do see that this poses another problem in the quest to get loading of 3ds files completely working.

[hellfire]

As pointed out earlier, it's necessary to create duplicate vertices at uv-discontinuities.
This results in 6 independant quads (makes 24 vertices).
Why there are 2 additional vertices is out of my understanding but it probably happened due to a completely braindead exporting function.

[zawran]

It seems to me like there are very little information out there about how people are getting this to work, could it be that the majority are using another 3d model file format than 3ds?

[hellfire]

There are certainly some drawbacks in the .3ds-format.
The normals/multivertex-weirdness ist solvable, though:
Create a list of unique vertex-position and assign a "unique id" to every vertex-index (so it's easy to test if two triangles share a vertex-position).
Batch triangles with the same smoothing-group id (sort faces by id) and calculate averaged vertex-normals for each face-set (so triangles from a different smoothing-group won't affect normals of the current face-set).

However, when you're going for more complex materials and require multiple sets of uv-coordinates, you're pretty much fu**ed with 3ds.
That's one of the main reasons why I coded my own exporter.

[TinDragon]

.3ds is a horrible format, its why alot of games companies develop there own export filters and why formats like mdl2 were made in the early 3d games era (of which there is a bmax code to load, can send it to you if you want). Even the nehe opengl tutorials dont have a 3ds loader, it seems to be a format most avoid 

One thing that i seem to recall is model loaders for the minib3d include which might cover 3ds, since that uses opengl maybe they have code in that you can look at to see how there doing it?

[edit]
Also there is a 3ds exporter someone wrote for blitz 3d http://www.blitzbasic.com/codearcs/codearcs.php?code=1815
maybe you can gleam some info from that or reverse the code to load, dont know if it actually covers the smoothing groups tho.

And Hi to everyone here, been awhile since i posted

[zawran]

Hi Jon, great to hear from you. I am sorry to say that I did not get any further with the game    It seems like coding is a seasonal thing for me, and right now its in season again   But as you can see, I am now messing around with 3D using opengl. I had totally forgotten about minib3d, but I have just downloaded it and will look through it later today. Perhaps there is a thing or two to learn from it. I am thinking about dropping the 3ds stuff though as its been nothing but a pain, and for perhaps doing a demo or two I probably wouldn't even need it really. Most stuff can be made in code anyways.

Anyhow, great to see that you are still around. Perhaps you might feel inspired to do a little something for the time challenge. Its what prompted me to get started again, but if I make something in time, only time will tell 

[hellfire]

I am thinking about dropping the 3ds stuff though as its been nothing but a pain

Maybe obj is an option to load a model.

[zawran]

Yes the .obj format seems like a good candidate. I have just redone some code I had to convert .ase which is 3dsmax ascii format, but it does not include texture uv coords, but it was really easy to get to work. Since .obj is ascii as well, it should be fairly straight forward. So I will give that a go and see if it works out better.

[Pixel_Outlaw]

I remember writing a half assed vertex loader for .obj.

I remember it being a very slow load in Bmax with parsing. I'll be interested to see how you do it.

[zawran]

I remember it being a very slow load in Bmax with parsing.

I am not that worried about the parsing time. Once I have the loader working 100%, it will be seperated from the render engine and changed to write a binary file with the information stored in the order I prefer. Then I will code another loader for the render engine. And reading a binary file is rather fast.

I have gotten as far as it is loading .obj files, parsing all the data available, only the lighting seems to be wrong, but I am too tired to work anymore on it tonight.



I have tried to reverse the vertex normals, but that did not change it for the better. If anyone has seen this problem before, then suggestions are welcome.