[Fixed] Problem with texturing and normal mapping ...

Hi All,

I've fixed the last problem concerning cameras and object positionning by learning with some tutorials and making several tests :p

Now I can play with camera and objects easily with the commands set I've created for :)

But I encounter 3 new issues.

1/ 1 triangle is not drawn ... It seem to be the last one or the first one .... I've defined 36 triangles with each all correct coordinates :

last arg simply change the UV textures to define the triangle.
Here is the triangle function :


Strange Issue .. I'm maybe wrong with something in the function that render the object ...

2/ Problem with normals.
I'm making now the object normals and object texturing but I encounter 2 problems.
My test concern a cube.
I've set normal to 1 axis to 1/-1 depending on the face:
Top : Y = 1.0
Bottom : Y = -1.0
Left : X=-1.0
Right : X= 1.0
Front : Z = -1.0
Rear : Z = 1.0
These values are the axis orientation of the face with object rotation set to 0.0, 0.0, 0.0
But lighting doesn't appear correctly.

3/ Problem with texturing.
Each face is 2 triangle. I've set textures coordinates to 0.0 or 1.0 depending on the position on the face
If I put the face on 2 axis:
top left : 0.0, 0.0
top right : 1.0, 0.0
bottom left : 0.0, 1.0
bottom right : 1.0, 1.0
All faces vertex follow this rule.

But I get this result :
http://files.odyssey-creators.com/MyCubev0_1.jpg

Here is the code I use to trace my 3D Object on screen :


I don't understand what can cause this issue.
I've rechecked the UV coordinates, the normals, the vertexes ...

If someone have an idea ... plz help :)
Thank you

Regards,
Freddix / AmiDARK

@freddix

I can see two issues

1. you have defined

ObjectMeshPTR, ObjectNormalPTR and ObjectUVPTR as pointer to int

but you are passing them to the functions with GL_FLOAT

so are they pointers ints or glFloats?

I suspect they are glFloat as you are using floats most other places.

So you are asumming that floats and ints have the same size. That's a bad thing to do, as it might not be true, and even if it is, they are still different things. An array in int has diiferent alignment restrictions to an array of float etc ete


2. your pointer arithmatic is bad


This Line:

ObjectNormalPTR = ObjectMeshPTR + 12 + ( 36 * 12 )

What are these numbers?

12 triangles? 36 bytes per triangle?

but your pointer is to an int so adding 1 to it advances it by 4 bytes.

You could do the arithmatic like that if your pointers were pointers to void

ie declared like so

void *ObjectMeshPTR, *ObjectNromalPTR, *ObjectUVPTR

But then it would be better to write something like

ObjectNormalPTR = ObjectMeshPTR + 12 * sizeof(whatever that 12 is) + ( (9 * sizeof(float)) * 12 )

Perhaps a better idea to consider might be to have seperate array for each item Mesh Normal and UV then you could better keep track of corresponding positions in the array.

Then you would just need three functions like
GetObjectMeshPTR( ObjectID )
GetObjectNormalPTR( ObjectID )
GetObjectUVPTR( ObjectID )

much easier to keep track of, no messy pointer arithmatic.


Hope all that makes sense

@broadblues

Exactly right.

Please guys, no "magic numbers" in your code.

I deal with older code where this was common (argh!) practice and it is a royal PITA to upgrade. It is very fragile and causes no end of grief.

@broadblues

Pointer arithmetic on void pointers isn't allowed. If you try to do this the compiler will generate an error. Use a pointer to char instead.

i.e.

APTR ptr1, ptr2;
int byte_offset;

ptr1 = (char *)ptr2 + byte_offset;

@freddix
Hello.

Ok
I was thinking that adding 12 was shifting a pointer to 12 bytes and not 12 * sizeof( pointer type ) ...
It's mentionned nowhere in the manual I use to lear C ...
Thank you for these informations.

For sure it should fix my issues.

Regards,
Fred.

@salass00

Quote:

That was at the back of mind when writing the explanation above, so I wrote the following test code which compiled without error on gcc

#include <stdio.h>

void *vPtr = 1000;
int *intPtr = 1000;

int main()
{
printf("%08lx %08lx\n",intPtr,intPtr+1);
printf("%08lx %08lx\n",vPtr,vPtr+1);
}

if that should fail then gcc has bug

@broadblues

From exec/types.h:


Output when compiling your code with vbcc:
Quote:

@salass00
in fact, the principle is a bit more complex for my needs.

What I'll do will simplify.
I will make my memoryblock become an array of structure ... I will then access data using the array.

@salass00

Gcc gives this:

gcc -o test test.c
test.c:3: warning: initialization makes pointer from integer without a cast
test.c:4: warning: initialization makes pointer from integer without a cast

and compies and works

resulting output being

000003e8 000003ec
000003e8 000003e9

Compiling with -Wall grumbles a bit more but still no error.

gcc -o test -Wall test.c
test.c:3: warning: initialization makes pointer from integer without a cast
test.c:4: warning: initialization makes pointer from integer without a cast
test.c: In function 'main':
test.c:8: warning: format '%08lx' expects type 'long unsigned int', but argument 2 has type 'int *'
test.c:8: warning: format '%08lx' expects type 'long unsigned int', but argument 3 has type 'int *'
test.c:9: warning: format '%08lx' expects type 'long unsigned int', but argument 2 has type 'void *'
test.c:9: warning: format '%08lx' expects type 'long unsigned int', but argument 3 has type 'void *'
test.c:10: warning: control reaches end of non-void function


So a definate difference of opinion between the two compilers there.

[edit]
A quick bit of googling reveals this to be gcc extension which can be remobed with the -pedantic oir -pedantic-errors switch

5.RAM Disk:> gcc -o test -pedantic test.c
test.c:3: warning: initialization makes pointer from integer without a cast
test.c:4: warning: initialization makes pointer from integer without a cast
test.c: In function 'main':
test.c:9: warning: pointer of type 'void *' used in arithmetic
5.RAM Disk:> gcc -o test -pedantic-errors test.c
test.c:3: error: initialization makes pointer from integer without a cast
test.c:4: error: initialization makes pointer from integer without a cast
test.c: In function 'main':
test.c:9: error: pointer of type 'void *' used in arithmetic
5.RAM Disk:>
[/edit]

@broadblues
Theorically, when you add +1 to a pointer, it should shift it with the size of its structure but under GCC ... it's wrong ... it simply add 1 to the pointer adress ... whenever the pointer is a pointer to a float, byte, int, char or a structure ...

I had to do :
MyPointer = MyPointer + sizeof( MyPointerStruct );
to avoid DSI error crash.

@freddix

Quote:

Pointer arithmatic does work under gcc so you mut be doing something wrong.

Make sure your pointer really does have the right type.

Be aware of alignment

take this test example

#include <stdio.h>

struct my_struct
{
int a;
int b;
char c;
};

struct my_struct array[2];
struct my_struct *array_ptr;

int
main()
{
printf("sizeof struct my_struct %d\n",sizeof(struct my_struct));
array_ptr = &array[0];

printf("array %08lx\n",(int)array_ptr);

array_ptr +=1;

printf("array + 1 %08lx\n",(int)array_ptr);

}

Output is:

8.RAM Disk:> gcc -o test test.c
8.RAM Disk:> test
sizeof struct my_struct 12
array 52553c7c
array + 1 52553c88
8.RAM Disk:>

Which is correct. It's 12 bytes because the next structure must align properly.


Check how you pointer is declared. Enable -Wall on your command line or even -Werror to make sure all is dewclared properly.

@broadblues
I've checked with printf output :p
It helped fix the pointer issue ...
Now all is ok...

Here is a shot of the 3D cube with correct normals, texture and lighting :p

All is now ok.
I can continue now devel on 3D objects...

Limbs will soonly appear on 3D objects :)

Here is the shot :



it's a 100% custom object creation system. I do not use gl cube object ;) It was needed to be sure the raw creation system work :)

@freddix

Nice cube

@broadblues
I can technically integrate more complex objects... Will make some tests and maybe poste a shot later.