I've done it.
I've implemented the Frustum class as I described, and I've tested it with the CubeManager to render cullable and selectable 3D textured Cubes.
I modified the CubeManager_RenderAllSelectable method to have one extra param, a pointer to the Camera you wish to "render through".
Now you can throw your geometry at the current Camera quite easily :)
The Camera class now supports three cull-related methods which you can use to test render objects at the last moment during rendering loops :)
They are called Camera_CullPoint, Camera_CullSphere and Camera_CullCube. They return TRUE if the entity is offscreen and should be culled, they return FALSE if the entity is (partially?) onscreen and should be rendered.
Who's a Happy Homer ?
Have a nice day :)
I've implemented the Frustum class as I described, and I've tested it with the CubeManager to render cullable and selectable 3D textured Cubes.
I modified the CubeManager_RenderAllSelectable method to have one extra param, a pointer to the Camera you wish to "render through".
Now you can throw your geometry at the current Camera quite easily :)
The Camera class now supports three cull-related methods which you can use to test render objects at the last moment during rendering loops :)
They are called Camera_CullPoint, Camera_CullSphere and Camera_CullCube. They return TRUE if the entity is offscreen and should be culled, they return FALSE if the entity is (partially?) onscreen and should be rendered.
Who's a Happy Homer ?
Have a nice day :)
I took a break after that little effort (phew!) I felt that I should quit while I was way ahead :)
Next things to be added: the existing but currently not implemented Sphere class, a yet-to-be-written SphereManager class, and then modify both the Cube and Sphere classes to use per-instance textures (at which point I will probably want to implement some kind of texture management too).
After that I am ready to add some support for "complex objects" in the form of Loaders for some common model file formats (OBJ, 3DS etc)
Then I must add code to find tight-fitting hulls for those complex objects (in the form of non-rendered cubes and spheres?)
Having done all of that, it will probably be time to write up some documentation and post the first official public beta of the engine :)
Next things to be added: the existing but currently not implemented Sphere class, a yet-to-be-written SphereManager class, and then modify both the Cube and Sphere classes to use per-instance textures (at which point I will probably want to implement some kind of texture management too).
After that I am ready to add some support for "complex objects" in the form of Loaders for some common model file formats (OBJ, 3DS etc)
Then I must add code to find tight-fitting hulls for those complex objects (in the form of non-rendered cubes and spheres?)
Having done all of that, it will probably be time to write up some documentation and post the first official public beta of the engine :)
It has been brought to my attention that a problem exists in the Camera code. It would be great if I could get some feedback on this.
If you visit my page http://homer.ultrano.com and scroll to the bottom theres a list of files. The latest upload of this project is called "dllStuff5.rar" - you will need one of the very early ones for the bmp files.
A quick description of the problem:
I have a scene containing two 3D cubes positioned at +/-,0,0 ie one on either side of the Origin, separated on the X axis. My camera is a few units back in Z so we can see them immediately.
If we move towards 0,0,0 ie the space between the cubes, the Camera will veer off to the left or right (whichever Cube is closer) as if the Cubes themselves are somehow attracting the Camera. The Direction X value is moving more than it should be.
HOWEVER, if I "sidestep" around these cubes and approach the origin from the far side, the problem disappears - and if I now return to the original location and again approach the origin, its working correctly !!
Does this sound weird or what?
If you visit my page http://homer.ultrano.com and scroll to the bottom theres a list of files. The latest upload of this project is called "dllStuff5.rar" - you will need one of the very early ones for the bmp files.
A quick description of the problem:
I have a scene containing two 3D cubes positioned at +/-,0,0 ie one on either side of the Origin, separated on the X axis. My camera is a few units back in Z so we can see them immediately.
If we move towards 0,0,0 ie the space between the cubes, the Camera will veer off to the left or right (whichever Cube is closer) as if the Cubes themselves are somehow attracting the Camera. The Direction X value is moving more than it should be.
HOWEVER, if I "sidestep" around these cubes and approach the origin from the far side, the problem disappears - and if I now return to the original location and again approach the origin, its working correctly !!
Does this sound weird or what?
The problem was resolved by setting the initial lookat point further away.
Something smells funny, and I'm not smiling.
But it's working and correctly.
Something smells funny, and I'm not smiling.
But it's working and correctly.
Oh joy, Oh joy, Oh joyojoyojoy !!!
Implemented Sphere class (textured 3D sphere instances)
Implemented SphereManager class (an arraymanager for the above)
Implemented Selectable, CULLABLE spheres :)
Just like the Cube and CubeManager, Sphere and SphereManager handle all the rending and culling for effectively an infinite number of 3D spheres.
Just like the Cubez code, culling is performed by the frustum of the active camera.
Just like the Cubez code, Selectable objects return their pointer on request.
Do you feel lucky, punk?
Implemented Sphere class (textured 3D sphere instances)
Implemented SphereManager class (an arraymanager for the above)
Implemented Selectable, CULLABLE spheres :)
Just like the Cube and CubeManager, Sphere and SphereManager handle all the rending and culling for effectively an infinite number of 3D spheres.
Just like the Cubez code, culling is performed by the frustum of the active camera.
Just like the Cubez code, Selectable objects return their pointer on request.
Do you feel lucky, punk?
I've added complete code for importing (loading), animating and rending of player models from MD3 (Quake3) files. It's compiling ok but its untested and I have to assume there's a lot of bugs to be fixed.
The code compiled to 3kb, not bad huh
The entire DLL is still a puny 29kb, and could definitely be screwed down even tighter than that.
I'll try to get all that code working asap, followed by the addition of collision detection of the player model with the world, using an imaginary sphere about the player model.
After that, code to export (save) the player models to a CUSTOM FILE FORMAT so that IDG don't get antsy and sue me
Finally, code to import (load) the now native custom format.
At that point, I can only be accused of writing a file format converter, and not of openly ripping off the MD3 file format. As long as I don't imply that MD3 is the native format of the Engine, I should be safe, yes?" />
The code compiled to 3kb, not bad huh
The entire DLL is still a puny 29kb, and could definitely be screwed down even tighter than that.
I'll try to get all that code working asap, followed by the addition of collision detection of the player model with the world, using an imaginary sphere about the player model.
After that, code to export (save) the player models to a CUSTOM FILE FORMAT so that IDG don't get antsy and sue me
Finally, code to import (load) the now native custom format.
At that point, I can only be accused of writing a file format converter, and not of openly ripping off the MD3 file format. As long as I don't imply that MD3 is the native format of the Engine, I should be safe, yes?" />
Bah - considering throwing away all the work I did on MD3 support.
I've decided I want to separate the skeleton, its animations, and mesh into separate data files. I'm using Maya for modelling, and I'm satisfied that I can do something useful with the data exported by Maya's animExport plugin, but there's no neat solution to exporting skeletons by themselves. The best solution I found was to export the skeleton to DirectX X-File format (ASCII) and then pilfer the minimal required data by hand (for the moment)..
Since there was no one super-sexy file format for Skeleton data, I have begun implementing my own file format..
I've already written a Loader for it, which is working nicely.
Here's the example file which I'm loading at the moment..
(note the matrix values are dummy values only)
I've decided I want to separate the skeleton, its animations, and mesh into separate data files. I'm using Maya for modelling, and I'm satisfied that I can do something useful with the data exported by Maya's animExport plugin, but there's no neat solution to exporting skeletons by themselves. The best solution I found was to export the skeleton to DirectX X-File format (ASCII) and then pilfer the minimal required data by hand (for the moment)..
Since there was no one super-sexy file format for Skeleton data, I have begun implementing my own file format..
I've already written a Loader for it, which is working nicely.
Here's the example file which I'm loading at the moment..
(note the matrix values are dummy values only)
Skeleton Biped
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0 ;Matrix to position and orient the Skeleton Origin
Joint Pelvis
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0 ;Matrix to position and orient the Pelvis relative to (Origin)
Joint LeftHip
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0 ;Matrix to position and orient the LeftHip relative to Pelvis
Joint LeftKnee
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
Joint LeftAnkle
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
EndJoint
EndJoint
EndJoint
Joint RightHip
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0 ;Matrix to position and orient the RightHip relative to Pelvis
Joint RightKnee
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
Joint RightAnkle
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
EndJoint
EndJoint
EndJoint
Joint LowerSpine
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0 <> ;Matrix to position and orient the LowerSpine relative to Pelvis
Joint UpperSpine
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
Joint Clavicle
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
Joint LeftShoulder
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
Joint LeftElbow
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
Joint LeftWrist
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
EndJoint
EndJoint
EndJoint
Joint RightShoulder
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
Joint RightElbow
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
Joint RightWrist
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
EndJoint
EndJoint
EndJoint
Joint Neck
Mat4 1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0
EndJoint
EndJoint
EndJoint
EndJoint
EndJoint
EndSkeleton
Basically it's a simply script language for describing a hierarchy of named joints, along with a 4x4 matrix for each joint which is used to position and orient each joint...
This should be enough information for me to render the skeleton in its "bind pose" by using some primitives to show the joints and bones...
This should be enough information for me to render the skeleton in its "bind pose" by using some primitives to show the joints and bones...
OK think of it this way : if the above script (describing a joint hierarchy) is enough to display the skeleton in its "bind pose", then we should realize that Joints are what needs to be animated..
Animation keyframes will consist of matrices to be applied to joints, and therefore the matrices in the Joint Hierarchy will be replaced at runtime with matrices interpolated from the current and next keyframes.
Clear as mud, eh?
Animation keyframes will consist of matrices to be applied to joints, and therefore the matrices in the Joint Hierarchy will be replaced at runtime with matrices interpolated from the current and next keyframes.
Clear as mud, eh?