I am newbie in this stuff since you have been in this field for a long time i thought you could guide me.
My project is finding wear of an object using its x-ray.I have cad model of the object and i have the x-ray which is obtained clinically.I have to find the exact pose of the cad model which matches with the x-ray and find the difference between the x-ray i obtain using the cad model and clinical model.
I need a x-ray simulator for my research which i was planning to do using an opengl program with cad model in form of .obj format and ray trace it and project the result in form of x-ray.But inorder to match with the clinical x-ray I need to rotate and translate the object i have but as you might be knowing .obj wont allow me to have any animation.
so next step was chosing a file format suitable for my work and i have come across .3ds format i thought this would be appropriate for me.So all i need to do is introduce a .3ds file loader and continue the raytracing as i have planned to do with the .obj file.
Since i am new to this i dont know if my thinking is right.Could you please tell me if i am right in my thinking if i am not right could you tell me what approach would be better for me?
if rotation and translation is all you need then .obj is just fine, while it does not contain any animation data translation and rotation of the entire object is done in your program and thus does not need any animation data.
Avoid the .3ds format. It does not retain texture coordinates and vertex normal data properly.
I would also suggest OBJ format, it is much easier to parse and debug.
If you need keyframed animation, roll your own. It is as simple as storing transforms as an array or positions and rotations (quaternion or matrices), and ‘lerp’/‘slerp’ between them.
would advise against *.3ds AND *.obj. Direct3D X file format is plain text like *.obj but supports more things and is somewhat easier to read and parse (imho). supported like 3ds and obj by almost any modelling tool.
In my experience, I have found that a good way to do things is to keep a polygon list (.obj format) plus an additional (internal, not necessarily saved to a file, but used internally and computed on load from disk) data structure that contains information on what vertices are part of what polygon. This gives rise to an efficient algorithm for sending data to your graphics card using triangle strips.
Algorithm goes:
Pick a triangle using the polygon list, issue glBegin()
Easily find connected triangles using point list.
Pick that triangle next, go to step 2
If you’ve hit a dead end, issue glEnd()
If there are still undrawn triangles, go to step 1.
You could do this without a point list, but a pre-computed point list is what makes this efficient.
Sending data to your card using triangle strips can greatly improve the performance of your code (up to x3) or could not affect the performance of your code at all, depending on exactly what you do in your code and your exact system configuration.
