Hi Col.
I have checked the rotating cube.
And it works perfectly.
Now, don´t worry about having it centered at the world coordinates.
The voxel engine works just the same.
When I rotate a voxel object around its picot, I just have to do this:
x# = x# - pivotX#
y# = y# - pivotY#
z# = z# - pivotZ#
;
;Rotate the voxel object here
;
x# = x# + pivtoX#
y# = y# + pivotY#
z# = z# + pivotY#
And tht is all it takes in order to take the pivot coordinates out of the way.
I would like to try your method with the voxel engine.
But, first, I would like to experiment with a sphere, instead of a cube.
If it works properly, no doubt I will use it.
An I thank you you for the great help.
I will have to get rid of floating point variables, and find a more compact way for representing the normals thou.
The spiderman head, for instance, employes 9800 voxels, and is equivalent to a 2000 polygons head model, in terms of graphics quality.
So, you see, storing 9800 normals is very memory consumming, specialy when you need photo-realistic models on the screen.
Spiderman, alone, uses 45 objects.
Some are small, like the fingers, but some are pretty big - his chest.
The average size is the shoulder.
BTW: If you want to have a better idea of how I cut spiderman in order to model it, take a look at Marvel´s fully poseable action figures. I actually have bought two spidermans.
One of them is right in front of me, and I use it to check the screen output against the real toy.
The other one... went through a surgic procedure hehe... got all of its parts, disassembled, in order to make it easier for me to model them.
Hierarchy is fine, too.
But here´s another thing... the final version of the engine will have to deal with normal indices, instead of the normals itself.
Because each time I draw the model, I have to recalculate the lighting for EACH voxel, which is very ime consumming.
I have already implemmented the normal indices, that does make it practical, because instead of computing the rotated normals for all 9800 voxels of spideys head, for instance, I only have to rotate 144 normals, no matter how far or how big it is.
This is even more critical when you add hierarchy to it.
Take spideys butt, for instance (sorry for the name, bu that was the word that came to my mind when I wrote the hierarchy part of the code).
Every time a change the butt´s rotation, I have to recalculate ALL normal tables for each and every piece of the model.
That is a total of 345 normal tables, each consisting of 144 normals = almost 50.000 normals!
Now, add to that, the fact that no 3d engine would be usable if you can have only one character at the screen, at any given time.
Double it, if you want to write a fighting game, and you end-up with almost 100.000 normals to rotate.
That´s why I have to use normal tables.
Handling individual voxel normals would make it absolutely impossible to achieve.
After implementing the lighting, no matter how slow it will run, I will have o find a way to use normal indices, no matter what... or else, I will have to forget about real-time lighting.
I have put all this info here, because I would like you to have a very clear understanding of why the backface-culling and normal rotation is so critical to the voxel engine.
The previous version of backface culling works fine, believe me... the number of drawn voxels dropped from 9800 5300 - the perfect solution would give us a count of 4900 voxels actualy drawn, but that is close enough - the engine is spending only 9.2% more time than it should.
I am prepared to accept that performance loss, for now.
But I truly agree with you that, if it can be done right from the start, then it is better to spend more time on that now than trying to find errors later.
I am glad you are helping me.
Thank you so much.
Rui Barbosa Jr.
I have checked the rotating cube.
And it works perfectly.
Now, don´t worry about having it centered at the world coordinates.
The voxel engine works just the same.
When I rotate a voxel object around its picot, I just have to do this:
x# = x# - pivotX#
y# = y# - pivotY#
z# = z# - pivotZ#
;
;Rotate the voxel object here
;
x# = x# + pivtoX#
y# = y# + pivotY#
z# = z# + pivotY#
And tht is all it takes in order to take the pivot coordinates out of the way.
I would like to try your method with the voxel engine.
But, first, I would like to experiment with a sphere, instead of a cube.
If it works properly, no doubt I will use it.
An I thank you you for the great help.
I will have to get rid of floating point variables, and find a more compact way for representing the normals thou.
The spiderman head, for instance, employes 9800 voxels, and is equivalent to a 2000 polygons head model, in terms of graphics quality.
So, you see, storing 9800 normals is very memory consumming, specialy when you need photo-realistic models on the screen.
Spiderman, alone, uses 45 objects.
Some are small, like the fingers, but some are pretty big - his chest.
The average size is the shoulder.
BTW: If you want to have a better idea of how I cut spiderman in order to model it, take a look at Marvel´s fully poseable action figures. I actually have bought two spidermans.
One of them is right in front of me, and I use it to check the screen output against the real toy.
The other one... went through a surgic procedure hehe... got all of its parts, disassembled, in order to make it easier for me to model them.
Hierarchy is fine, too.
But here´s another thing... the final version of the engine will have to deal with normal indices, instead of the normals itself.
Because each time I draw the model, I have to recalculate the lighting for EACH voxel, which is very ime consumming.
I have already implemmented the normal indices, that does make it practical, because instead of computing the rotated normals for all 9800 voxels of spideys head, for instance, I only have to rotate 144 normals, no matter how far or how big it is.
This is even more critical when you add hierarchy to it.
Take spideys butt, for instance (sorry for the name, bu that was the word that came to my mind when I wrote the hierarchy part of the code).
Every time a change the butt´s rotation, I have to recalculate ALL normal tables for each and every piece of the model.
That is a total of 345 normal tables, each consisting of 144 normals = almost 50.000 normals!
Now, add to that, the fact that no 3d engine would be usable if you can have only one character at the screen, at any given time.
Double it, if you want to write a fighting game, and you end-up with almost 100.000 normals to rotate.
That´s why I have to use normal tables.
Handling individual voxel normals would make it absolutely impossible to achieve.
After implementing the lighting, no matter how slow it will run, I will have o find a way to use normal indices, no matter what... or else, I will have to forget about real-time lighting.
I have put all this info here, because I would like you to have a very clear understanding of why the backface-culling and normal rotation is so critical to the voxel engine.
The previous version of backface culling works fine, believe me... the number of drawn voxels dropped from 9800 5300 - the perfect solution would give us a count of 4900 voxels actualy drawn, but that is close enough - the engine is spending only 9.2% more time than it should.
I am prepared to accept that performance loss, for now.
But I truly agree with you that, if it can be done right from the start, then it is better to spend more time on that now than trying to find errors later.
I am glad you are helping me.
Thank you so much.
Rui Barbosa Jr.