BRender Tutorial Guide:8 BRender Tools :Importing Models into BRender
Next|Prev|Up
Working with 8-bit Colour
Working with True Colour

Importing Models into BRender


When importing a model into BRender from a 3D modeller, there are three classes of entity which you may need to import - texture maps, materials and geometry. Each needs to be imported separately, then re-united inside BRender. If you are only interested in importing model geometry, you can use GEOCONV (or the 3DS2BR -mod option) to import and convert .asc files. If you want to import materials associated with a model, you will use 3DS2BR. TEXCONV is used to import texture maps. If you are working in true colour mode, importing models is an reasonably straightforward process. Indexed colour is altogether more complicated due to the complexities of palette management. Indexed colour is discussed first below. A shorter section towards the end of the chapter covers true colour. This section is largely a review of ground already covered.

Working with 8-bit Colour

When working in 8-bit colour you will need to formulate a strategy for palette management. How you set up and manage your palette will depend on personal preference and the requirements of your application. You may be happy to use the palette supplied with BRender (std.pal) which offers a reasonably wide selection of colours. If all your materials reference imported texture maps you may wish to construct a palette and a shade table using only the colours in your texture maps. If you are not using texture maps you may wish to construct a custom palette containing the colours of the materials in your scenes. Alternatively, your palette may be divided into two parts, one part containing strip colours for your non-textured materials, the other containing texture colours. Some possible palette management strategies are considered below.

Using the supplied palette (std.pal)
and shade table (shade.tab)

You may find that the palette and shade table supplied with BRender adequately represent your scenes. In this case you will need to ensure suitable index_base and index_range values are added to your material descriptions. You will also need to quantize your texture maps to std.pal using TEXCONV. When you quantize an imported texture map to a palette, TEXCONV takes each colour in the texture map in turn, and selects the colour from the palette that most closely approximates that colour. This new colour then replaces each instance of the original colour in the output pixelmap. Note that std.pal contains a range of colours sufficiently general to reproduce a reasonable representation of most scenes.

The material script file illustrated below will display a blue shaded material when rendering using std.pal. Note the index_base and index_range values. You will need to ensure that the index_base and index_range values for all your materials (whether saved as script files or in .mat format) reference the appropriate colour in your palette.

cube8.mat

# A plain blue material
material =	[
		identifier = "BLUE MATERIAL"; 
		ambient = 0.05;
		diffuse = 0.55;
		specular = 0.4;
		power = 10;
		flags = [light,smooth];
		index_base = 64;
		index_range = 31;
	];

3DS2BR doesn't know how your hardware palette is set up. Materials imported using the -mat command line option contain dummy index_base and index_range values. Your application should set these fields to point to the correct palette indices when the material is loaded. Material script files generated by 3DS2BR for non-textured materials contain true colour information. You can use this data to add appropriate index_base and index_range values to the script file for use in 8-bit mode. Some examples will help clarify these issues.

Non-textured Materials

In Chapter 7 we extracted information describing the geometry and appearance of a model from the 3D Studio file duck.3ds using the following command line:

	3DS2BR duck.3ds -nomatrix -mod duck.dat -scr duck.mat
For the purposes of this exercise, enter the following command line to extract material descriptions from duck.3ds and store them in duck.mat:

	3DS2BR duck.3ds -scr duck.mat
The script file generated by 3DS2BR is shown below:

duck.mat

# BRender Material Script 

material =	[
		identifier = "BLACK PLASTIC";
		flags = [light,smooth];
		colour = [0,0,0];
		ambient = 0.000000;
		diffuse = 0.000000;
		specular = 1.000000;
		power = 69.309998;
	];

material =	[
 		identifier = "YELLOW PLASTIC";
		flags = [light,smooth];
		colour = [202,179,52];
		ambient = 0.679216;
		diffuse = 0.679216;
		specular 0.741569;
		power = 23.770000;
	];

This script file can be used unaltered in true colour mode, as indeed it was in BRTUTOR7.C described in Chapter 7. In order to use the materials described in duck.mat in 8-bit mode, we need to add appropriate index_base and index_range values. It is likely that the exact colour will not be available in std.pal, due to the 256 colour limitation. It should be possible, however, to find a reasonable approximation.

duck8.mat

# BRender Material Script 

material =	[
		identifier = "BLACK PLASTIC";
		flags = [light,smooth];
		ambient = 0.000000;
		diffuse = 0.000000;
		specular = 1.000000;
		power = 69.309998;
		index_base = 0;
		index_range = 0;
	];

material =	[
		identifier = "YELLOW PLASTIC";
		flags = [light,smooth];
		ambient = 0.679216;
		diffuse = 0.679216;
		specular 0.741569;
		power = 23.770000;
		index_base = 224;
		index_range = 25;
	];

An index_base value of 224 points to the beginning of the yellow colour ramp. The colour range for this material is 224-248, essentially the yellow colour ramp. When rendering BRender will select a shade of yellow from within this range according to the current lighting level. Note that true colour information is redundant in 8-bit mode and has been removed. This modified material script is stored on your Tutorial Programs disk as duck8.mat. Compile and run BRTUTR7B.C to display a revolving yellow duck in 8-bit mode.

Textured Materials

When 3DS2BR converts a textured material for use in BRender programs, the resultant material file (binary or script) will contain a dummy texture map and a dummy shade table. For instance, suppose the 3D Studio model being imported contains a material named 'FACE OF THE MOON', which references a colour (or texture) map called moonshot.gif. 3DS2BR will save a material file containing a BRender material called `FACE OF THE MOON'. This material will reference a dummy BRender pixelmap called 'moonshot' (note the .gif file extension has been stripped away) and a dummy shade table named 'shade'.

You could convert moonshot.gif to a BRender .pix file using TEXCONV. Your application would then need to load a file containing a pixelmap called 'moonshot' (it doesn't matter what the file is called) before loading and registering the file containing the material 'FACE OF THE MOON'. If you don't wish to use the texture map in moonshot.gif, simply replace 'moonshot' with the identifier of any previously loaded and registered texture map. If you are using shade.tab, the shade table supplied with BRender, you will need to change 'shade' to 'shade_table' in the colour_map field. This is necessary because shade.tab uses the string 'shade_table' as an identifier (an alternative would be to change the identifier in shade.tab to 'shade' using TEXCONV -n). A further example should help illuminate the above discussion.

The following command line imports a model of a fork and its associated material from the standard 3D Studio model description file fork.3ds:

	3DS2BR fork.3ds -mod fork.dat -scr fork.mat
Both fork.3ds and the file containing its associated texture map, refmap.gif, can be found on your Tutorial Programs disk. You will need to enter the command lines in this example in order to display the imported fork model. Mesh data describing the geometry of the converted model is stored in fork.dat. Enter the command line:

	geoconv fork.dat -l
to display the following information on this newly created file:

GEOCONV 1.24 Copyright (C) 1994-1995 by Argonaut Technologies Limited
Models: 1
        Verts   Faces  Edges  Fgrps  Vgrps  Sort  DOTQ   Radius
 fork   858     812    1648    1      1     858  ----   3.05932
Materials: 1
 CHROME GIFMAP
	
Scale the model (set radius to 1) and translate it to the origin (in its parent's coordinate space) as follows:

	geoconv fork.dat -c -n -o fork.dat

BRTUTR7B.C


/* Copyright (c) 1996 Argonaut Technologies Limited. All rights reserved.
 * Program to Display a Revolving Yellow Duck (8-bit).
 */

#include <stddef.h>
#include <stdio.h>
#include "brender.h"
#include "dosio.h"

int main(int argc, char **argv)
{
	br_pixelmap *screen_buffer, *back_buffer, *depth_buffer, *palette;
	br_actor *world, *observer, *duck;
	int i;
	br_material *mats[10]; /*for storing pointers to material descriptions*/

/******** Initialise BRender and Graphics Hardware **************/

	BrBegin();

	/*
	 * Initialise screen buffer and set up CLUT (ignored in true colour) 
	 */
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
	BrZbBegin(screen_buffer->type, BR_PMT_DEPTH_16);
	
	back_buffer = BrPixelmapMatch(screen_buffer,BR_PMMATCH_OFFSCREEN);
	depth_buffer = BrPixelmapMatch(screen_buffer,BR_PMMATCH_DEPTH_16);

/*************** Build the World Database **********************/

	world = BrActorAllocate(BR_ACTOR_NONE,NULL);	
	BrLightEnable(BrActorAdd(world,BrActorAllocate(BR_ACTOR_LIGHT,NULL)));
	
	/*
	 * Load and Position Camera
	 */
	observer = BrActorAdd(world,BrActorAllocate(BR_ACTOR_CAMERA,NULL));
	observer->t.type = BR_TRANSFORM_MATRIX34; 
	BrMatrix34Translate(&observer->t.t.mat,BR_SCALAR(0.0),BR_SCALAR(0.0),
	                                                      BR_SCALAR(5.0));
	
	/*
	 * Load and Apply Duck Materials
	 */
	i = BrFmtScriptMaterialLoadMany("duck8.mat",mats,BR_ASIZE(mats));
	BrMaterialAddMany(mats,i);

	/*
	 * Load and Position Duck Model
	 */
	duck = BrActorAdd(world,BrActorAllocate(BR_ACTOR_MODEL,NULL));
	duck->model = BrModelLoad("duck.dat");
	BrModelAdd(duck->model);
	duck->t.type = BR_TRANSFORM_MATRIX34;
	BrMatrix34RotateX(&duck->t.t.mat,BR_ANGLE_DEG(30)); 

/********************** Animation Loop ***********************/

	for(i=0; i < 200; i++)
		BrPixelmapFill(back_buffer,0);
		BrPixelmapFill(depth_buffer,0xFFFFFFFF);
		BrZbSceneRender(world,observer,back_buffer,depth_buffer);
		BrPixelmapDoubleBuffer(screen_buffer,back_buffer);
		BrMatrix34PostRotateX(&duck->t.t.mat,BR_ANGLE_DEG(2.0));
	}

	/*
	 * Close down 
	 */
	BrPixelmapFree(depth_buffer);
	BrPixelmapFree(back_buffer);
	BrZbEnd();
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
	BrEnd();
	return 0;
}
BRTutr7b.c

The model described in fork.dat can now be used in any BRender program. The material file, fork.mat, generated by 3DS2BR is given below:

fork.mat

# BRender Material Script 
#

material =	[
		identifier = "CHROME GIFMAP";
		flags = [light,smooth,environment];
		ambient = 0.000000;
		diffuse = 0.000000;
		specular =0.992941;
		power = 69.340004;
		index_base = 64;
		index_range = 31;
		colour_map = "REFMAP";
		index_shade = "shade";
	];

Note that the identifier used for BRender's standard shade table is `shade_table', and not `shade'. The script file, fork.mat, will need to be edited accordingly.

With texture mapped materials, index_base is used as a row offset into a shade table. index_range determines the number of shades (or lighting levels) available, starting at index_base. The standard shade table has 64 rows (this is also the default number of rows generated by MKSHADES, the utility used to create shade tables discussed later in this chapter). Not surprisingly, then, the default index_base is 0 and the default index_range is 63.

Unless you are using a shade table with non standard dimensions (or you want to restrict the range of shades available), you can omit the index_base and index_range fields completely. Alternatively, specify the default values, 0 and 63.

The revised script file is given below:

fork.mat

# BRender Material Script 

material =	[
		identifier = "CHROME GIFMAP";
		flags = [light,smooth,environment];
		ambient = 0.000000;
		diffuse = 0.000000;
		specular =0.992941;
		power = 69.340004;
		colour_map = "REFMAP";
		index_shade = "shade_table";
	];

This material references a dummy texture map called `REFMAP'. In order to replicate the image created in 3D Studio, the original .gif file needs to be converted to BRender .pix format:

TEXCONV refmap.gif -n REFMAP -c BR_PMT_INDEX_8 -Q std.pal -o refmap.pix
The following is displayed:

TEXCONV 1.6 Copyright (C) 1994 by Argonaut Technologies Limited
Loaded `refmap.gif' as BR_PMT_INDEX_8(320,200)
Palette `refmap.gif' BR_PMT_RGBX_888(256)
`refmap.gif' assigned new identifier `REFMAP'
Converted `REFMAP' BR_PMT_INDEX_8 (8 bit) to BR_PMT_INDEX_8 (8 bit)
Quantizing `REFMAP' to palette `Palette' using 256 colours from the range 0-255
Output pixelmap `refmap.pix'
The -n option ensures that the identifier, `REFMAP', is the same as that used in the material script file (alternatively, we could have changed the line in the script file specifying the texture map to colour_map = refmap.gif)

The -c option converts the input file to the required BRender pixelmap type (where necessary).

The -Q option quantizes the colours in the texture map to the specified palette.

The -o option generates an output file in accordance with the specified command line options.

Compile and run BRTUTOR9.C to display a chrome-textured fork. Please note that this program will not work unless the command lines specified above have been entered. Only fork.3ds and refmap.gif are included on the Tutorial Programs disk. You will need to run 3DS2BR to generate fork.dat and fork.mat, GEOCONV to convert fork.dat, and TEXCONV to convert and quantize refmap.gif. You will also need to edit fork.mat as indicated.

BRTUTOR9.C is almost identical to BRTUTR8B.C, encountered in Chapter 7. A fork model is loaded instead of the duck model of BRTUTR8B.C, and the 'gold' textured material is replaced with a material that references the chrome texture in refmap.pix.

To recap:

To import 3D Studio models and associated materials:

Creating a Texture Palette

If all your materials reference texture maps, you may wish to construct a palette and a shade table using only the colours in these texture maps. TEXCONV can be used to generate an optimal palette for a number of texture maps. This palette could then be defined as the texture palette, to be used for all textures.

Begin by assembling your textures and listing them in a text file (to keep command line length within manageable proportions). Suppose your project uses the following textures, listed in a text file textures:

--------------------------- textures
gold.gif
refmap.gif
buttons.gif
canada.gif
cloud.gif
cruiser.gif
dash.gif
graymarb.gif
Note that all the above textures are standard 3D Studio .gif files. You may want to copy these files (or your own textures) to your current directory before proceeding, so you can work through this example.

It is worth noting that colour 0 is always transparent for textures in 8-bit colour mode. For this reason it is advisable to quantize and remap between colours 1 and 255.

The following command line loads the specified pixelmaps, converts them to BRender 8-bit format, quantizes and remaps to 255 colours in the range
1-255 (this avoids reassigning colour 0, which would be treated as transparent by the renderer), and creates an output palette, texture.pal, containing these colours.

	texconv @textures -c BR_PMT_INDEX_8 -R 1,255 -O palette -o texture.pal
In short, TEXCONV examines the specified textures maps and comes up with what, in its estimation, is the best combination of 255 colours that could be used to reproduce these textures. Note that you will still need to run TEXCONV to generate a BRender .pix file for each or your textures.

Enter the following command line to display the palette:

	viewpal texture.pal
VIEWPAL displays all 256 colours in a palette, along with their respective palette indices (0-255). The next step is to create a shade table based on this palette.

Figure 41 A palette displayed using VIEWPAL

BRTUTOR9.C


/* Copyright (c) 1996 Argonaut Technologies Limited. All rights reserved.
 * Program to Display a Chrome-Textured Fork (8-bit)
 */

#include <stddef.h>
#include <stdio.h>
#include "brender.h"
#include "dosio.h"

int main(int argc, char **argv)
{
	br_pixelmap *screen_buffer, *back_buffer, *depth_buffer, *palette, *shade;
	br_actor *world, *observer, *fork;
	br_pixelmap *chrome_pm;
	int i;

/****** Initialise Renderer and Set Screen Resolution ********/

	BrBegin();	

	/*
	 * Initialise screen buffer and set up CLUT (ignored in true colour) 
	 */
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
	BrZbBegin(screen_buffer->type, BR_PMT_DEPTH_16);
	
	back_buffer = BrPixelmapMatch(screen_buffer,BR_PMMATCH_OFFSCREEN);
	depth_buffer = BrPixelmapMatch(screen_buffer,BR_PMMATCH_DEPTH_16);

	/* 
	 * Load Shade Table
	 */
	shade = BrPixelmapLoad("shade.tab");
	if (shade==NULL)
			BR_ERROR0("Couldn't load shade.tab");
	BrTableAdd(shade);

/*************** Build the World Database **********************/

	world = BrActorAllocate(BR_ACTOR_NONE,NULL)	
	BrLightEnable(BrActorAdd(world,BrActorAllocate( BR_ACTOR_LIGHT,NULL)));

	/* 
	 * Load and Position Camera
	 */
	observer = BrActorAdd(world,BrActorAllocate(BR_ACTOR_CAMERA,NULL));
	observer->t.type = BR_TRANSFORM_MATRIX34; 
	BrMatrix34Translate(&observer->t.t.mat,BR_SCALAR(0.0),BR_SCALAR(0.0),
	                                                      BR_SCALAR(5.0));

	/* 
	 * Load and Register chrome Texture
	 */
	chrome_pm = BrPixelmapLoad("refmap.pix");
	if (chrome_pm==NULL)
		BR_ERROR0("Couldn't load refmap.pix");
	BrMapAdd(chrome_pm);
	/* 
	 * Load and Apply fork Material
	 */
	BrMaterialAdd(BrFmtScriptMaterialLoad("fork.mat"));
	
	/* 
	 * Load and Position fork Actor
	 */
	fork = BrActorAdd(world,BrActorAllocate(BR_ACTOR_MODEL,NULL));
	fork->model = BrModelLoad("fork.dat");
	BrModelAdd(fork->model);
	BrModelApplyMap(fork->model,BR_APPLYMAP_PLANE,NULL);
	fork->t.type = BR_TRANSFORM_MATRIX34;
	BrMatrix34RotateX(&fork->t.t.mat,BR_ANGLE_DEG(30)); 
	fork->material = BrMaterialFind("CHROME GIFMAP"); 

/********************** Animation Loop ***********************/
	
	for(i=0; i < 200; i++) {
					BrPixelmapFill(back_buffer,0);
					BrPixelmapFill(depth_buffer,0xFFFFFFFF);
					BrZbSceneRender(world,observer,back_buffer,depth_buffer);
					BrPixelmapDoubleBuffer(screen_buffer,back_buffer);
					BrMatrix34PostRotateX(&fork->t.t.mat,BR_ANGLE_DEG(2.0));
	}

	/*
	 * Close down 
	 */
	BrPixelmapFree(depth_buffer);
	BrPixelmapFree(back_buffer);
	BrZbEnd();
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
	BrEnd();
	return 0;
}

BRTUTOR9.C

Figure 42

The following command line generates a shade table, newshade.tab from the source palette texture.pal:

	mkshades texture.pal -r 1,255 -o newshade.tab
Enter the following command line to display the shade table:

	texconv -I pix newshade.tab -P texture.pal -c BR_PMT_INDEX_8 -v
newshade.tab is an array of 255 columns by 64 rows. Each column indexes a colour in texture.pal. Each row contains indices to shades of its associated colour representing 64 lighting levels.

Figure 43 A shade table displayed using TEXCONV

Note that the identifier shade_table has been assigned to newshade.tab. This could be changed using the -n option:

	texconv -I pix newshade.tab -n newname -O pix -o newshade.tab
To recap:

To create a custom texture palette and shade table:

Creating a Custom Palette With Strip Colours

If you are not using texture maps, you may wish to build a custom palette containing the colours of the materials in your scenes using MKRANGES. MKRANGES is a utility for building ramped, or strip, palettes from information contained in a text file.

For imported materials, material colours are specified in the text files generated using the 3DS2BR -mod and -scr options. If you are intending to construct a palette based on the colours of your materials, compile a list of colours from your material script files or log files (or your material data structure if not using material script files). Then use this information to create a text file for MKRANGES. Remember to ensure appropriate index_base and index_range values have been specified for all your materials.

Supposing you have compiled the following list of colours from your material script files or log files:

You could then prepare a text file for MKRANGES as follows:

Then run MKRANGES to create your custom palette:

	mkranges strippal.txt strip.pal 
The text file `strippal.txt' can be found on your Tutorial Programs disk. Having created a new palette, you can view it by entering:

	texconv -I pix strip.pal -c BR_PMT_INDEX_8 -v
or:

	viewpal strip.pal
You could experiment by loading strip.pal in BRTUTR7B.C above, instead of std.pal, and varying the index_base and index_range values to select the newly generated colours.

Creating a Custom Palette With Strip Colours and Texture Colours

If you are using both textured and non-textured materials, your palette may be divided into two parts, one part containing strip colours for your nontextured materials, the other containing texture colours. To achieve this you will need to create separate strip colour and texture palettes using the utilities provided and subsequently combine them using PALJOIN.

Suppose your project uses the textures in textures above, and the colours specified in strippal.txt. Let's assume that you have decided to divide your palette equally between strip colours and textures.

Project Palette
-----------------------------------
| strip colours | texture colours |
-----------------------------------
|<----0-127---->|<----128-255---->|
1. You could begin by generating a texture palette and shade table:

Run TEXCONV to generate a texture palette:

	texconv @textures -c BR_PMT_INDEX_8 -R 128,128 -O palette 
   o texture.pal
For each of the texture maps in textures, quantize and remap to the specified range:
e.g. texconv gold.gif -c BR_PMT_INDEX_8 -Q texture.pal -R 128,128
O pixelmap -o gold.pix

Run MKSHADES to create a shade table from the texture palette:

	mkshades texture.pal -r 128,128 -o newshade.tab
2. Generate a strip palette using only the first 128 colours:

Edit strippal.txt as follows:

Run MKRANGES to generate a strip palette:

	MKRANGES strippal.txt strip.pal
The strip colours are located in the first 128 locations in strip.pal. The remaining locations are `empty'. Texture colours occupy the second half of texture.pal. This can be visually verified by running VIEWPAL to view the palettes on the screen. Enter:

	viewpal strip.pal
to display the strip palette. Enter:

	viewpal texture.pal
to display the texture palette.

3. Combine your texture and strip palettes into a single palette.

Generate the following text file to combine in a single palette the first 128 colours in the strip palette and the last 128 colours in the texture palette.



Then run the following command line to generate the output palette, new.pal, containing all the required colours:

	paljoin newpal.txt new.pal
Enter:

	viewpal new.pal
to view new.pal.

The newly generated palette will need to be assigned an identifier:

	texconv -I pix new.pal -n palette -O pix -o new.pal
The best way to handle indexed colour is to pre-define a set of colours for a given project, use MKANGES to generate a strip palette using these colours, then define a range of palette-indexed materials based on these colours. Similarly with texture maps - prepare your textures, then run TEXCONV to generate an optimal texture palette and MKSHADES to generate a shade table based on the optimised palette. Thereafter, use only the pre-defined materials and textures. This involves much less work than starting with your artwork and trying to hand-convert and optimise the entire project's artwork once it is completed.

Working with True Colour

If you are working in true colour mode, you won't need to use MKSHADES or MKRANGES, since there are no palettes or shade tables to worry about. 3DS2BR can be used to import model geometry and materials. TEXCONV is used to import textures. If you are only interested in a model's geometry, GEOCONV can be used to import .asc files etc. Much of what you need to know to import model geometry, materials and textures has already been covered, either above or in Chapters 6 and 7. What follows, therefore, is a brief review.

Importing Model Geometry

Enter the following command line to import the 3D Studio .asc file fork.asc (fork.asc can be found on your Tutorial Programs disk),

	geoconv fork.asc -c -n -o fork.dat

Importing Geometry and Materials

1. Use 3DS2BR to convert 3D Studio .3DS files to BRender format. The following command line extracts data describing model geometry from the 3D Studio file duck.3ds and stores it in duck.dat, and creates a material script file describing the converted materials:

	3DS2BR duck.3ds -nomatrix -mod duck.dat -scr duck.scr
2. Use GEOCONV to convert model geometry to a format suitable for BRender. The following command line collapses data into a single model, centres the model at the origin and normalises it to fit a sphere of radius 1:

	geoconv duck.dat -m -c -n -o duck.dat

Importing Texture Maps

Use TEXCONV to convert a pixelmap to BRender pixelmap format. The following command line generates a 15-bit BRender pixelmap from a .gif file:

	texconv gold.gif -c BR_PMT_RGB_555 -o gold15.pix

A Worked Example

Let's work through an example.

Suppose you want to import a model whose geometry is described in the file fork.asc. Suppose further that the material you want to assign to this model is called GRIDMAP, and is defined in the 3D Studio file light.3ds. GRIDMAP is a textured material that references a texture map called TILE0011 in the file tile0011.tga. Note that fork.asc, light.3ds and tile0011.tga are all on your Tutorial Programs disk.

Start by importing the model geometry:

	geoconv fork.asc -c -n -o fork.dat
Then import the material and store it in a material script file:

	3DS2BR light.3ds -scr fork.mat
Finally, import the texture map:

	texconv tile0011.tga -n TILE0011 -c BR_PMT_RGB_555 -o tile.pix
The -n option sets the identifier to TILE0011 to be consistent with that contained in the colour_map field in the recently generated script file fork.mat. The -c and -o options generate a .pix file in BRender 15-bit format.

The material script file generated by 3DS2BR is shown below:

fork.mat

# BRender Material Script
# 

material = [
		identifier = "WHITE PLASTIC";
		flags = [light,smooth];
		colour = [206,206,206];
		ambient = 0.807843;
		diffuse = 0.807843;
		specular = 1.000000;
		power = 52.480000;
	];
material = [
		identifier = "GRIDMAP";
		flags = [light,smooth];
		colour = [0,0,0];
		ambient = 0.000000;
		diffuse = 0.000000;
		power = 1.000000;
		index_base = 64;
		index_range = 31;
		colour_map = "TILE0011";
		index_shade = "shade";
	];



BRTUTR10.C


/* 
 * Copyright (c) 1996 Argonaut Technologies Limited. All rights reserved.
126
126
#include <stddef.h>
#include <stdio.h>
#include "brender.h"
#include "dosio.h"

int main(int argc, char **argv)
{
	br_pixelmap *screen_buffer, *back_buffer, *depth_buffer, *palette;
	br_pixelmap *tile_pm;
	br_actor *world, *observer, *fork;
	int i;
	br_material *mats[10];

/******** Initialise Renderer and Set Screen Resolution *********/

	BrBegin();	
	
	/*
	 * Initialise screen buffer and set up CLUT (ignored in true colour) 
	 */
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
	BrZbBegin(screen_buffer->type, BR_PMT_DEPTH_16);
	
	back_buffer = BrPixelmapMatch(screen_buffer,BR_PMMATCH_OFFSCREEN);
	depth_buffer = BrPixelmapMatch(screen_buffer,BR_PMMATCH_DEPTH_16);

/*************** Build the World Database **********************/
	
	world = BrActorAllocate(BR_ACTOR_NONE,NULL)
	BrLightEnable(BrActorAdd(world,BrActorAllocate(BR_ACTOR_LIGHT,NULL)));
	
	/*
	 * Load and Position Camera
	 */
	observer = BrActorAdd(world,BrActorAllocate(BR_ACTOR_CAMERA,NULL));
	observer->t.type = BR_TRANSFORM_MATRIX34; 
	BrMatrix34Translate(&observer->t.t.mat,BR_SCALAR(0.0),BR_SCALAR(0.0),
	                                                      BR_SCALAR(5.0));
	
	/*
	 * Load and Register TILE0011 Texture
	 */
	tile_pm = BrPixelmapLoad("tile.pix"); 
	if (tile_pm==NULL) 
			BR_ERROR0("Couldn't load tile.pix"); 
	BrMapAdd(tile_pm); 
	
	/*
	 * Load and Apply fork Material
	 */
	i = BrFmtScriptMaterialLoadMany("fork.mat",mats,BR_ASIZE(mats));
	BrMaterialAddMany(mats,i);

	/*
	 * Load and Position fork Actor
	 */
	fork = BrActorAdd(world,BrActorAllocate(BR_ACTOR_MODEL,NULL));
	fork->model = BrModelLoad("fork.dat")
	BrModelAdd(fork->model);
	BrModelApplyMap(fork->model,BR_APPLYMAP_PLANE,NULL); 
	fork->t.type = BR_TRANSFORM_MATRIX34;

	/*
	 * Assign fork Material
	 */
	fork->material = BrMaterialFind("GRIDMAP"); 

/********************** Animation Loop ***********************/

	for(i=0; i < 200; i++)  {
				BrPixelmapFill(back_buffer,0);
				BrPixelmapFill(depth_buffer,0xFFFFFFFF);
				
				BrZbSceneRender(world,observer,back_buffer,depth_buffer);
				BrPixelmapDoubleBuffer(screen_buffer,back_buffer);
				BrMatrix34PostRotateX(&fork->t.t.mat,BR_ANGLE_DEG(2.0));
	}

	/*
	 * Close down 
	 */
	BrPixelmapFree(depth_buffer);
	BrPixelmapFree(back_buffer);
	BrZbEnd();
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
.      .      .
	BrEnd();
	return 0;
}

BRTUTR10.C


The material WHITE PLASTIC, imported from light.3ds along with GRIDMAP, could be deleted. The index_base, index_range and index_shade fields could also be deleted, since we are working in non-indexed mode. The colour field is also irrelevant for a textured material. If your version of BRender does not support lit textures, the ambient, diffuse and power fields could also be eliminated (refer to your installation guide for details). Finally, your version of BRender might not support smooth shading, in which case this flag should be reset. If you were running BRender x86, Version 1.2, for example, which doesn't support light or smooth shaded textures in true colour mode, the following minimalist script would suffice:

fork.mat

# BRender Material Script
# 
material =	[
		identifier = "GRIDMAP";
		flags = [];
		colour_map = "TILE0011";
	];

We now have:

Note that the model described in fork.asc was saved without texture coordinates. It was therefore necessary to call BrModelApplyMap to generate texture co-ordinates for the model's vertices:

	BrModelApplyMap(fork->model,BR_APPLYMAP_PLANE,NULL);
Compile and run BRTUTR10.C to display a texture mapped fork. Note that only the source files fork.asc, light.3ds and tile0011.tga are included on your Tutorial Programs disk. You will need to run the command lines described above to generate fork.dat, fork.mat and tile.pix, before attempting to compile BRTUTR10.C.


Generated with
CERN WebMaker