Hi Guys.
Col, Paradox7, Andy...
Paradox: of course I am very gratefull to you, for pointing me the path of the swapped signs :^).
I am not sure if you really don´t know anything about 3d. If you really don´t, maybe this can help you understand how you helped us: there are two standards employed when writting 3d code: the right-hand rule and the left-hand rule.
Well, I was creating vertices using one standard, and was doing the normals math using the other one.
Vertex math really is not *that* succeptible to that kind of mistake, for wire-frame, or flat-shaded polygons, because we are using a sphere here.
So, what we were looking at, prior to the changes, was the inside of the sphere, not its outside, actualy.
But, as it is a sphere, we were not able to tell the difference.
But with normals, it makes a lot of difference.
Normals are VERY sensitive to signals.
Why is that?
Take a look at how normals are calculated.
You are going to find a sqr() inside of its code.
Well, sqr() for positive numbers have TWO possible answers.
One is positive, and the other one is negative.
But the compiler always returns the positive root.
So, you have to pick the correct signs or, otherwise, you are going to end up pointing your normal to the opposite direction.
Normals should always point outwards, but they were doing the other way around.
Actualy, at some point in time, some of the normal components were correct, whist others were wrong. That may be the reason why I was getting that 12.5 degrees offset, remember?
Now, everything is working fine.
Thanks to you guys.
Well, things are looking good in voxel realm :^).
Let me just finish adding real-time lights to the voxel engine and I will release the source-code.
Initialy, I will release the gcc source-code.
Then, I plan on porting it to BlitzPlus.
I am not promissing that the B+ version will be lightning fast.
It´s not that B+ os not fast enough.
It´s just that the engine was written with C in mind.
I took advantage of many special constructs of the C language.
For one thing, pointers are used all over the place.
I believe that using memory blocks will allow for a speed that will be very close to what I get with C pointers, but am not sure about how they are implemented.
I am sure they are slower, but they may be much faster than my best estimates (but will never be as fast as a plain C pointer).
As it is heavily based on the use of pointers, performance will depend almost exclusively on how fast peekint and pokeint perform their tasks.
Well, I have to go to sleep now...
I will keep you guys updated.
Just keep one thing in mind: the voxel engine is targetted at the PS2, which has a very powerfull floating point unit (actualy, a couple of them) and a processor which allows for 128 bit instructions.
So, I don´t think a P IV will have a chance against it.
Also, voxel engines don´t rely on hardware acceleration, so no matter what kind of video-card you have, it is not going to change the performance of the engine at all.
Fast RAM is desirable, thou...
Talk to you guys tomorrow,
Rui Barbosa Jr.
P.S.: I live in Brazil. It´s 01:21AM.
It would be good if you guys could tell me where you live, so I can have an approximate idea of time-zone differences among us.
P.P.S.: To know my local time, check Rio de Janeiro time or Brasilia time (they are both on the same time zone as mine, in Brazil). I live in Rio de Janeiro. I have to go.. take a warm shower and go to sleep... See you...
Col, Paradox7, Andy...
Paradox: of course I am very gratefull to you, for pointing me the path of the swapped signs :^).
I am not sure if you really don´t know anything about 3d. If you really don´t, maybe this can help you understand how you helped us: there are two standards employed when writting 3d code: the right-hand rule and the left-hand rule.
Well, I was creating vertices using one standard, and was doing the normals math using the other one.
Vertex math really is not *that* succeptible to that kind of mistake, for wire-frame, or flat-shaded polygons, because we are using a sphere here.
So, what we were looking at, prior to the changes, was the inside of the sphere, not its outside, actualy.
But, as it is a sphere, we were not able to tell the difference.
But with normals, it makes a lot of difference.
Normals are VERY sensitive to signals.
Why is that?
Take a look at how normals are calculated.
You are going to find a sqr() inside of its code.
Well, sqr() for positive numbers have TWO possible answers.
One is positive, and the other one is negative.
But the compiler always returns the positive root.
So, you have to pick the correct signs or, otherwise, you are going to end up pointing your normal to the opposite direction.
Normals should always point outwards, but they were doing the other way around.
Actualy, at some point in time, some of the normal components were correct, whist others were wrong. That may be the reason why I was getting that 12.5 degrees offset, remember?
Now, everything is working fine.
Thanks to you guys.
Well, things are looking good in voxel realm :^).
Let me just finish adding real-time lights to the voxel engine and I will release the source-code.
Initialy, I will release the gcc source-code.
Then, I plan on porting it to BlitzPlus.
I am not promissing that the B+ version will be lightning fast.
It´s not that B+ os not fast enough.
It´s just that the engine was written with C in mind.
I took advantage of many special constructs of the C language.
For one thing, pointers are used all over the place.
I believe that using memory blocks will allow for a speed that will be very close to what I get with C pointers, but am not sure about how they are implemented.
I am sure they are slower, but they may be much faster than my best estimates (but will never be as fast as a plain C pointer).
As it is heavily based on the use of pointers, performance will depend almost exclusively on how fast peekint and pokeint perform their tasks.
Well, I have to go to sleep now...
I will keep you guys updated.
Just keep one thing in mind: the voxel engine is targetted at the PS2, which has a very powerfull floating point unit (actualy, a couple of them) and a processor which allows for 128 bit instructions.
So, I don´t think a P IV will have a chance against it.
Also, voxel engines don´t rely on hardware acceleration, so no matter what kind of video-card you have, it is not going to change the performance of the engine at all.
Fast RAM is desirable, thou...
Talk to you guys tomorrow,
Rui Barbosa Jr.
P.S.: I live in Brazil. It´s 01:21AM.
It would be good if you guys could tell me where you live, so I can have an approximate idea of time-zone differences among us.
P.P.S.: To know my local time, check Rio de Janeiro time or Brasilia time (they are both on the same time zone as mine, in Brazil). I live in Rio de Janeiro. I have to go.. take a warm shower and go to sleep... See you...