Dark Bit Factory & Gravity
GENERAL => Projects => Topic started by: zawran on February 15, 2009
-
Yesterday I started working on opengl 3d again. Its been a long while since I messed around with raw opengl, so not everything is fresh in my mind. But I got off to a decent start I think.
(http://zac-interactive.dk/temp/ogl_screenshot.jpg)
Download from here: http://zac-interactive.dk/temp/ogl.zip (http://zac-interactive.dk/temp/ogl.zip)
It isn't much, but its a start. It shows 9 cubes with texture and a lightsource. There is a readme.txt file which explains the keyboard controls.
I would like to add some shadows, some of those selfshadowing ones would be cool, but I am not sure how those are done yet, so for now I will work on adding more dynamic object creation options than just the cube, while I look around for a solution for shadows.
-
You could use the stencil buffer to make shadows in this case Zawran :)
Works well here on old hardware. It would be great to see a demo from you again after all this time.
-
stencil buffer
And I am off to google it right away :)
Yeah it would be cool, if I got back into it and made some kind of demo, even a small intro would be nice. We'll see how things goes. At least I have the coming week off work and nothing better to do. :updance:
-
Nice one dude, its a start at least. And I second that about a new demo eventually :)
I'd recommend you look at some of the NeHe examples that were converted to BlitzMax. Im not sure if its been done yet, but there is a Nehe article / source on Cartoon Shading.
-
good work dude
runs smooth even on my sad excuse of a pc :D
-
Looks great!
Just remember that Blitz only uses OpenGL 1.1. Why they haven't updated, I have no clue. :boxer:
Also shaders seem to have hit and miss support with many computers.
-
Also shaders seem to have hit and miss support with many computers.
Shaders, yikes I have just jumped back in, I don't think I will be messing with shaders yet. First I am going to try and get the basics going before I try and step into the big league :)
But from what I have found searching the BlitzResearch forums is that using glew, you can get access to extensions and GLSL shaders in GL2.0, but I have not even begun to look into how it might work yet.
-
Not a huge update, but I have added the option of turning things foggy :)
(http://zac-interactive.dk/temp/foggy.jpg)
I am still working on adding more mesh building code to enable me to build more complex entities. At some point I will take a look at loading a model from a 3d package. I seem to remember that I have some code somewhere that I might be able to convert to bmax.
-
I started a topic about loading .3ds models in OpenGL with Blitzmax but I don't think the code was every fully written. It didn't help that it was in French.
Funny thing is I was going to suggest you try some fog and you beat me to it. You might try some black fog too.
Some time ago I wrote a small primative routine library. It was intended for gl lists and the models only had per face lighting calculations but I can provide it if you see any value in it.
-
First version runs smooth here. Nice start!
-
Well I got 3ds model loading working, at least for models without texture and color definition, but its a start :)
(http://zac-interactive.dk/temp/teapot.jpg)
Download test here: http://zac-interactive.dk/temp/oglloader.zip (http://zac-interactive.dk/temp/oglloader.zip)
I also changed my mesh setup, and re-coded the dynamic primitives code so that it works the same. Now I have to find a simple 3ds model with texture so that I can work on the code to read the texture data. After that I will start working on adding options for either displaylists or vbo depending on which I can get my head around an which works best. A long time ago I did dabble with displaylists and I seem to remember it being straight forward, but we'll see once I get started on it.
[edit] It seems rather difficult to locate a free simple 3ds model with texture, something like a crate or barrel will do. If one of you guys have one or a link to one you are willing to share I appreciate it highly.
-
a free simple 3ds model with texture
Here's some simple knot.
I can put some more stuff somewhere later...
-
[edit] It seems rather difficult to locate a free simple 3ds model with texture, something like a crate or barrel will do. If one of you guys have one or a link to one you are willing to share I appreciate it highly.
It seems that the .3ds format required a path to the texture rather than including the texture in the .3ds file. I may be mistaken however.
Hellfire's knot looks untextured in AutoCAD (which supports textured .3ds file import)
-
Yes the texture is not included in the 3ds files, but has to be loaded seperately, but the texture UV coords are there, and I need a model with its texture image to test that I am reading the texture UVs correctly. :)
The knot Hellfire provided, although doesn't make use of texture, does look great.
-
Ah right, I applied a procedural material, so 3dsmax didn't export a texture-filename.
-
I'll whip something up sir
Why thank you my good man :)
For starters it would probably be best with just a cube/box with each face UV mapped to a different part of a texture. That is perhaps the most simple model to test with and it should be very easy to see if the outcome is correct. Unfortunately I do not have any 3d software available at the moment. (the knot looked really cool though :clap: )
-
just a cube/box with each face UV mapped to a different part of a texture
Try this.
I intentionally rotated and scaled the texture-coordinates of each face differently so that wrong uvs are obvious.
-
Ah sorry I went a bit overboard and made a castle lol.
Perhaps the cube is best for now. I do know that Anim8or will export .3ds however it doesn't supply texture information.
-
(http://zac-interactive.dk/temp/ups.jpg)
Well it looks like I still have work to do with reading the texture UV coors, or it could be something wrong in the code that picks the UV coords during the render. Anyway my work is not quite done it seems. Well onwards and upwards as they say :)
-
in opengl texture-coordinates are bootom-up.
simply try v=1-v.
(the knot should have proper uvs included, too, by the way)
-
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.
(http://zac-interactive.dk/temp/knot.jpg)
This is how it looks so far: http://zac-interactive.dk/temp/oglloader2.zip (http://zac-interactive.dk/temp/oglloader2.zip)
-
Well done!
Now it's time to read the vertex-normals, too :)
-
Looks like you are progressing quickly. Amazing what you have done in 2 days.
-
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:
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 :)
-
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.
-
Very good 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:
// 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?
-
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
-
I tried another approach, which seems to almost work:
(http://zac-interactive.dk/temp/error.jpg)
Here is what I am doing:
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.
-
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.
-
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.
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.
-
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.
-
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?
-
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.
-
.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 (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 :D
-
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 :updance:
-
I am thinking about dropping the 3ds stuff though as its been nothing but a pain
Maybe obj (http://www.royriggs.com/obj.html) is an option to load a model.
-
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.
-
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. :)
-
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.
(http://zac-interactive.dk/temp/sphere.jpg)
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.
-
It either looks like it's lit from near the back, or some of your normals are coming out 0 in length.
Jim
-
While taking a break for the model loading stuff, I figured out how to do render to texture using the glCopyTexSubImage2D command. I had used it before but with some 2d stuff. Its not the fastest way of doing it, but I think that using extensions might have to wait a bit :)
(http://zac-interactive.dk/temp/r2t.jpg)
You can preview my very basic and simple test here: http://zac-interactive.dk/temp/r2t.zip (http://zac-interactive.dk/temp/r2t.zip)
-
If you really want Render To Texture, you need to look at pbuffers (old, compatible, sometimes incredibly slow, sometimes fast), and the framebuffer extensions - new, fast, not in every driver.
Jim
-
I am fairly certain that my .obj model loader is working as expected, so I thought that I would post it in case someone else would be able to get something out of it.
Function loadOBJmodel:TMesh(loadfile:String)
Local tmp:TMesh = TMesh.init()
Local sline:String, ck:String
Local v1:String, v2:String, v3:String
Local f1:String, f2:String, f3:String
Local vertices:Int, texUV:Int, vNormals:Int, faces:Int
Local filein:TStream = ReadFile(loadfile)
' locate vertex data
Repeat
sline = ReadLine(filein)
ck = Left( sline,2 )
Select ck
Case "v " ' vertex
v1 = NthField( sline," ",2 )
v2 = NthField( sline," ",3 )
v3 = NthField( sline," ",4 )
tmp.addVertex(Float(v1),Float(v2),Float(v3))
vertices:+ 1
Case "vt" ' vertex texture
v1 = NthField( sline," ",2 )
v2 = NthField( sline," ",3 )
tmp.addTexUV(Float(v1),Float(v2))
Print v1+","+v2
texUV :+ 1
Case "vn" ' vertex normal
v1 = NthField( sline," ",2 )
v2 = NthField( sline," ",3 )
v3 = NthField( sline," ",4 )
tmp.addVertexNormal(Float(v1),Float(v2),Float(v3))
vNormals :+ 1
Case "f " ' face
sline = Right(sline,Len(sline)-2) ' trim start of string
sline = Replace(sline," ","/") ' replace spaces
' vertex pointers
f1 = NthField( sline,"/",1 )
f2 = NthField( sline,"/",4 )
f3 = NthField( sline,"/",7 )
tmp.addFVpointer(Int(f1)-1,Int(f2)-1,Int(f3)-1)
' texture pointers
f1 = NthField( sline,"/",2 )
f2 = NthField( sline,"/",5 )
f3 = NthField( sline,"/",8 )
tmp.addFVTexUV(Int(f1)-1,Int(f2)-1,Int(f3)-1)
' normal pointers
f1 = NthField( sline,"/",3 )
f2 = NthField( sline,"/",6 )
f3 = NthField( sline,"/",9 )
tmp.addFVnormal(Int(f1)-1,Int(f2)-1,Int(f3)-1)
faces :+ 1
End Select
Until Eof(filein)
Return tmp
End Function
' Given a String, a delimiter, And a n -- returns the nth Field
Function NthField:String(s:String, delim:String, n:Int)
Local o:Int = 1
For Local i:Int = 1 To n - 1
o = Instr(s, delim, o)
If o = 0 Then
Return ""
End If
o = o + 1
Next
Local p:Int = Instr(s, delim, o)
If p = 0 Then
Return Mid(s, o)
Else
Return Mid(s, o, p - o)
End If
End Function
Its written in BlitzMax since that the language I use, but I am certain that it wouldn't be much trouble to translate it into other languages as well.
-
Looks cool but I think people would need to also see the "NthField" function which I assume is some string delimiter extracting function like we used in the old .asc to ttd lib format ? I should still have the blitzcode for those converters around somewhere, think one of them did truespace .asc models hich might be handy since I believe truespave is now free :)
-
Yes I forgot that function, I will add it when I get home. Its basically just a function which finds the Nth word/number in a string, so its not overly complicated :) But for completeness sake it should have been there.
[edit] I have added the string search function that was missing.
-
The example reminds me of the cube in Enigma by Phenomena :)
-
Cool; The Tin Dragons making tracks! :)
I recon it would be also cool to put those converters up.
-
I am not sure the converter's would be much use to anyone outside me and zawran, while they just create a text file full of data statements there presented in the order needed by the ttdvectorlib, infact I am not even sure they export in the correct format for the last few versions of that to be honest. They were kinda hacked together by me to help us get more than cubes into the lib's demos and dont give anything more than vertex and face data but they mix triangle and quad face data in one file type due to how we coded our old lib. It would probably be more useful in the long run to either right proper object loaders like zawran is now, or write a converter to match your own codes vertex and face storing methods.
I will however have a look and see if I can find the truespace .asc version I think that just did triangle faces and if Istill have the code it might be useful to someone to learn from :)
[EDIT] Found the truespace .asc code whacked it up here http://www.dbfinteractive.com/forum/index.php/topic,3988.0.html (http://www.dbfinteractive.com/forum/index.php/topic,3988.0.html) for those interested.
-
I have also made an .ASE model loader, which I will clean up and post tonight, provided I remember to do so. It is not a great file format in that it does not save a lot of information, but its easy to parse since its ascii format. But in case someone want to have a look, I will post it later on.
-
Nice one guys, they will definately be useful.
I waseven thinking of writing a very similar utility myself for simple stuff, this would save me a job.
-
I have posted all 3 of my current model loaders in the Bmax section. .3ds, .obj, .ase is covered. They should be fairly easy to translate into other languages being that Bmax is an easy to understand language, at least I think so :)
-
I was going through my mesh type and decided to add a planequad, which is basically a quad used as a plane where texture repeat is set when created. Nothing fancy or anything, but its something that could easily be used as floors/wall and other, like in a wolfenstein like maze.
(http://zac-interactive.dk/blogimages/planequad.jpg)
-
Looking good, is the plane made of multiple parts or one big quad as it looks like your texture is tiled across it rather than stretch like mine is. If its just one quad tiled then how do you do that in opengl?
-
If its just one quad tiled then how do you do that in opengl?
It is one quad with a tiled texture on it.
Usually for a quad with a texture you would have something like this as the texture UV coords:
0.0,0.0
1.0,0.0
1.0,1.0
0.0,1.0
If you want the texture tiled, then you simply adjust the 1.0 numbers to something else. Lets say you want the texture twice on the width, then your numbers would look like this:
0.0,0.0
2.0,0.0
2.0,1.0
0.0,1.0
So in my method which creates the quad, it takes a float for the width tiling, and a float for the height tiling, and then use these numbers instead of the 1.0 numbers.
-
OMG that is so simple, I thought there would be some strange command involved to set tiling and scale or something. Awesome thanks Zawran.
-
hehe, yeah its that simple :D
-
I just finished my first version of a Heightmap from Image method. It will load an image, then create a mesh and set the height according to one of the color channels on the image. Calculating normals for the heightmap mesh takes a long time if the image is large, so I should soon write custom load/save methods for my meshes, as this would allow me to convert the meshes outside the engine, and loading the resulting binary file would be really quick.
I did not have any colormaps lying around, so the following picture is rendered using the heightmap as texture.
(http://zac-interactive.dk/blogimages/heightmap.jpg)
-
Your making some very nice progress. Much faster than me at the moment, but I have been redoing my entity system to reference to a seperate mesh type after are chat about my original method making it likely to have lots of mesh overhead creating multiple entites of the same type, such as the cubes I had in my test. I have to say that from the shots and info your engine is inspiring me to work on mine.
:bully:
cheers
Jon
-
I am having more fun this time around with opengl than last time I tried, and that has been a motivational factor for me. Last time I didn't really get it, but for some reason it seems more logical now. So there is a good chance that I will keep at it, which is nice, and its rewarding to see something actually work.
-
You might be able to colorize the vertex points by height for a cool graphic effect. Or better yet you might provide a function to colorize them by height. In this way you could get procedural land with mountains and oceans. ;). In my old random terrain generator I just used a bitmap that measured 1x255 pixels. The height of the vertex set the color based on the bands or colors in the image.
-
After I made the method that created the terrain from the heightmap, I did actually think about making one of those "fly over never ending land" effects :) Where it randomly creates new heights as the terrain is moved. But I was too tired, so it will be something I might look at later on. Today I will be trying out how VBO works because I am thinking that it might be better if I get that added to it before I settle on my load/save object format. I will need to find out how data for VBO is formated, so that I store it most effeciently in my mesh type. As it looks right now, at least half my day looks to be free of other things, so I might have even more progress today. :)
-
I decided to take a stab at coloring the terrain using a heightmap color gradient. And I think it worked out great. I also made load/save methods for my mesh type, so now instead of taking 1500 millisecs to calculate the terrain from the heightmap, it takes 23 millisecs to load and prepare it from a binary file :)
(http://zac-interactive.dk/blogimages/heightmapcolored.jpg)
[edit] I just did a small test using my old heightmap tool I made back when using blitzplus. You can download it from here:
http://zac-interactive.dk/temp/zhmap.zip (http://zac-interactive.dk/temp/zhmap.zip)
-
The test runs fine, looks good.
I am having a rethink of my approach at the moment as it stands my engine can only deal with fixed meshs, due to it only using displaylists, there fast but once made there pretty much set it stone so to speak. I think your approach from what I have seen is much better and much easier to adapt and add to. My other concern atm is why my code is failing on someones system, I am really at a lost on that one :S
-
I have just figured out how multi texturing works, so will be working that into my engine as soon as I have grabbed something to eat. This will allow me to use a detail texture on the terrain, and I am sure there are other uses as well.
I have displaylists running, but as you mention, they have to be completely remade, if you want to change something, so for dynamic objects, like transforming/morphing primitives, tunnels, changeable terrain etc its not a good solution. If kept at a lower amount of vertices, you can get away with building the objects each frame, but for more complex stuff, I think it will have to be a combination between displaylists for static non-changing objects, for which they are great as they are fast, or VBO for dynamic objects. VBO can be used for static objects as well, but from what I have read so far, they are a bit slower than display lists, but since I haven't made any VBO objects yet, I cannot confirm this.
[edit] I re-uploaded the terrain test with one using the multi texture feature to add the detail map.
-
I ran into a problem which I haven't figured out yet.
If Self.multitexture = 0 Then
glBindTexture(GL_TEXTURE_2D,Self.texture[0].resource)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR)
glEnable(GL_TEXTURE_2D)
glBegin(GL_TRIANGLES)
Self.mesh.drawTextured()
glEnd()
Else
glActiveTextureARB(GL_TEXTURE0_ARB)
glBindTexture(GL_TEXTURE_2D, Self.texture[0].resource)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR)
glEnable(GL_TEXTURE_2D)
glActiveTextureARB(GL_TEXTURE1_ARB)
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_ARB) ' combine textures
glTexEnvi(GL_TEXTURE_ENV, GL_RGB_SCALE_ARB, Self.multitexturescale) ' set RGB scaling
glBindTexture(GL_TEXTURE_2D, Self.texture[1].resource)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR)
glEnable(GL_TEXTURE_2D)
glBegin(GL_TRIANGLES)
Self.mesh.drawMultiTextured()
glEnd()
End If
The code above shows how I setup the multi texture, but if I add a texture to one entity, then all entities becomes multi textured. I am thinking its because I need to somehow turn it off when doing the entities with only one texture on. But I have been searching around on the net and not finding anything yet that can enlighten me. So I am hoping one of you guys might have ideas worth trying out.
-
http://www.berkelium.com/OpenGL/examples/multitex.c
Take a look at this example, it might help you.
-
Yes that actually did help, I added the following after its done with multi texturing and now it works:
glActiveTextureARB(GL_TEXTURE1_ARB)
glDisable(GL_TEXTURE_2D)
glActiveTextureARB(GL_TEXTURE0_ARB)
glDisable(GL_TEXTURE_2D)
And the order does matter. If I disabled TEXTURE0 first, then no textures were being draw on the objects without multi texture, but disabling TEXTURE1 first, then it works. Thanks for the link, now I can move on. :)
I have uploaded a small example showing some cubes with 2 textures blended.
(http://zac-interactive.dk/blogimages/multitex.jpg)
It can be downloaded from here: http://zac-interactive.dk/temp/multitex.zip (http://zac-interactive.dk/temp/multitex.zip)
-
Very nice, your certainly getting the hang of opengl, I would say from that demo you could likely create some demos and intros that surpassed anything we did in the old ttdvectorlib ;D
Now I really have to suss out lights and textures into my engine proper rather than from outside it in the other code :D
-
you could likely create some demos
I might just do that some day :) But for the moment I am using my momentum to get this engine of mine to a stage where I am happy with the features and usability that it will enable me to put something together without too much fuzz. Exactly when that is, I am not sure yet. But I am starting to think about what kind of features I need for a version 1.0 and then focusing on only getting to that goal. Then when that goal has been reached, I would probably use it to make some kind of intro/demo thing, and after that make a list of additional features I can work on.
-
Looking good Zawran :)
Works here (ATI), no problems at all. I upgraded the forum to allow you to add files up to 1mb to your posts if it makes it easier for you to add the files.
-
I am having more fun this time around with opengl than last time I tried, and that has been a motivational factor for me.
You doing very well and my motivational isnt good.
Your Demo run fine on my system.
-
Very very nice progress.
-
I got the .obj loader working to my satisfaction, and I have successfully loaded a handful of .obj files found on the net. But it resulted in some changes in my mesh type, which then broke some of the procedual mesh creation methods, so during the coming weekend I will have to recode those parts of my engine. But its not all bad, because it might just end up with it being more effecient and model loading is a fairly important part of it, so its essential that it works, I can always adjust the procedual stuff. So if all goes well, then sometime during the weekend I will post another small test to show whatever progress I manage.
-
Well I managed to get VBO working, so now I have the choice between intermediate, display lists and vbo. I still have to rewrite my procedual primitive creation methods, but thats ok, I doubt those are going to be too much trouble. I also need to rewrite my terrain method, which might be a bit more difficult. Once those things are taken care of, I am not totally sure what I will try next, but I will put on the thinking cap for the rest of the weekend to figure that out.
For now I am just happy that I managed to get the vbo working. :)
-
Good to hear you got VBO's in, I havent looked into them yet but will be something to consider I am sure. Look forward to seeing your next engine demo ;)
-
I decided to look at how shaders are loaded and used, and I used the shader files from Jon's example. I haven't looked at how to include them into the exe yet though, which I will once I clean up the code and make it more in line with the rest of the engine.
(http://zac-interactive.dk/temp/shaderball.jpg)
http://zac-interactive.dk/temp/shaderball.zip (http://zac-interactive.dk/temp/shaderball.zip)
At the same time I found out how to use gluQuadric's. I still have no plans for actually using shaders for anything, but I figured that I might as well give it a try since I was home sick and really, really bored.
-
Works fine for me, great progress, and keep it up
-
great progress, and keep it up
Thanks, I am hoping to get some coding done on it this weekend. Its been really fun making it so far thats for sure.
-
I have been cleaning up my mesh type and re-written a bunch of mesh methods after changing the way meshes are stored. To get a break from code clean-up every now and then, I started working on a native gui for the engine. I first thought about using the windows gui, but since I have made a lot of gui's before and I don't really feel like messing around with the window api, I decided to go for a custom gui. I have windows drawing and some gadget drawing done. Next I will be working on the mouse control for it so that it can get a little interactive.
(http://zac-interactive.dk/blogimages/openglgui.jpg)
The gui is fully skinable and I added a font type to deal with text writing which I probably will expand on later on so I can use it for other things besides just the gui.
-
This looks really neat!
Are the GUI windows bound to the area inside the native window? It might be cool to have them have a very faint gradient and transparency but as you said skinnable so that is a moot point.
-
It's looking cool :)
zawran and I chatted about gui's for the engines as I thought it would be cool for making tools for use with them. I havent started on my actual gui code yet but I have got my own bitmap font code going with some reference to an example zawran made. I am hoping to use it for my gui system but I am probably going to make the gui seperate to my engine so that I can use it in other things as well and I can then ensure its not tied to heavy into the 3d side.
I think zawran can skin the windows for buttons, close icon etc. but i am not sure if the actual window pane is skinable or just colorable, but I suspect it could be changed to do gradients. Making them transparent could be done just by setting blend before drawing since there opengl :)
-
Yes the windows are bound to the native window and can only be used on opengl contexts, so they can not be used as loose windows outside the main application window. They are fully skinable, that is you can change all the graphics, including the titlebar and window background. So I could make a gradient if thats what I wanted. For now I really like this simple look, so that is what I will continue with, but I might make other versions later on. Transparency could be done since opengl supports this.
The windows are 2D quads which is drawn after the 3D is rendered to keep them ontop and they are using standard 2D coordinates.
-
I just wanted to let everyone know that I have not abandoned this 3d engine of mine. I am still working on it, but various things have ment that I have had less time to code lately. I am slowly progressing though, and I am currently working on a game idea where I will be using the 3d engine, so while I am working out the details of the game setup, I am only making whatever changes is needed for the game to work, such as making the engine render to a canvas and adding methods to the mesh type that can create the types of objects that I need.
Unfortunately this also means that I really don't have much to show at the moment, but as soon as I do, I will post here ofcause. Hopefully it won't be too long.
-
The main thing is to keep dipping your toes in the water so to speak.
As long as you keep yourself familiar with the code then you shouldn't have any problems getting back into it later on.
The screenshot a few posts up looks really lovely, it will be great to see the GUI used for a completed tool in the future.