I need some help on a problem with my 3DS Loader. I had the GLUT 3DS Loader working on my Intel workstation, and I just ported it to my PowerBook. I just had to wrote a little endian to big endian conversion function. I can now render a 3DS model on my PowerBook, but I have a little bug. Depending on the orientation of the model, I can see some black triangle on the border of the mesh, but I can’t figure out the reason of it.
I also noticed some performance difference between my PowerBook and my Intel P4 1.3 GHz. I fixed the frame rate of the application to 20 fps, but I press a button to rotate the model, it is smoother on my P4 with a GeForce 2 than on my PowerBook with GeForce FX. So I find that a bit suspicious. Maybe a didn’t activate full support of the GPU on my PowerBook. I’m new to Mac OS X, so I use standard Unix tools to compile.
So if someone had an idea what the problem is, please tell me, because I’m a bit disappointed of my PowerBook now 
Did you tried with http://lib3ds.sourceforge.net/ ?
For me it sounds like the way you are drawing object is not the most optimal way for the architecture.
Are you using display list ? converts your model in triangles strip ? etc … ?
At the moment I draw the model using simple triangles, so I use glBegin( GL_TRIANGLES ) and loop over the faces. I’m looking to use triangle strips but befor I had to figure out if there is a way to store the vertices in triangles strips in 3DS or if I have to compute them by myself.
But thanks for the reply, I will try to use display list, maybe it will fix the problem.
What’s a GLUT 3DS Loader? Where can I download it?
Thank’s
Immediate mode is slow on OS X compared to Windows. Displays lists are much faster.
I have done some tests with my 3DS Loader. I have drawn the model normally (just with glBegin(GL_TRIANGLES) ), triangle strips and display lists. But I always had the same bug, that on the border of the model we can see some black triangles. I could fix the problem by using glEnable(GL_CULL_FACE). Now I wanted to know why I have to use face culling, because I don’t have to use it my Intel PC. There are some parts of the model who will be better drawn with face culling disabled. I could just change a bit my model, but I wondered why face culling seems to be a problem on Mac.
It’s not; you’re doing something else wrong. How big a depth buffer have you asked for? Have you got depth testing enabled? Where are your near and far planes?
Thanks for the remark about the clip plane. It seems that the problem had come from there. I had fixed the near clip plane to 1.0 and the far clip plane to 1000.0. So I changed the near clip plane to 5.0. Now the model is drawn whithout graphic bug.
I made some tests on my 3DS Loader. On my PowerBook when I set the near clip plane near to 0.0, I can see some black area on the model. But on my Intel PC, I can set the near clip plane near to 0.0 whithout having this black area. Any idea why ?
Does your PowerBook have a Rage 128? That card seems only to support 16-bit depth buffers, which might explain things… Otherwise, try using CGLDescribePixelFormat to tell you precisely how many depth bits you have, and whatever the equivalent is on Linux/Windows for comparison.
The precision available to the depth buffer is related to the ratio of far/near; so pushing the near plane out or pulling the far plane in will give you more precision. Pushing the near plane out is generally the better option, since smaller changes give more precision back (moving the near plane from 1.0 to 2.0 gives you as much extra precision as moving the far plane from 1000.0 to 500.0).
Err? Asking the Rage128 about its supported depth modes via CGLDescribeRenderer(…, kCGLRPDepthModes, …) returns exactly the same results as all other ATI renderers:
7169 (0x00001c01)
meaning depth modes of 0, 16, 24, and 32 bpp are supported.
Have you found differently, in practice? (obviously, available framebuffers are subject to VRAM constraints…)
I have a GeForceFX 5200 on my PowerBook G4 1,33 GHz. I don’t think that the GPU have problem with the depth buffer, for me it seems that it is the way the Apple OpenGL driver is implemented. What disturbs me most, is that my apps seems to run better on my Intel P4 1,3 GHz with a GeForce 2 GTS. By the way, I use GLUT for my apps, so I can compare the apps whithout changing a line of code. So I would like to understand this difference of performance between my PowerBook and my PC, also if the PowerBook have a better GPU.
The usual cause of performance discrepancies between Windows and Mac OS X is immediate mode (glBegin). Immediate mode is around 3 to 5x slower on Mac OS X than on Windows.
Use Shark and the OpenGL profiler to find where your time is going. Those are tools you won’t find equalled on Windows 
It seems very unlikely to me that the hardware would use the depth buffer differently on the different platforms. Failure to get 24-bit Z seems much more likely.
Are you calculating the normal vectors correctly?
If the points in the traingle are counter clockwise it should show by default. But if its clockwise then it might get culled or not shaded properly.
Maybe it has something to do with the order you are putting in your verticies? Remember the right hand rule? The thumb is the normal.
Never ever use immidiate mode!!!
I say it once again!
Never ever use immidiate mode!!!
why? Because its slow!
You can easily do this 20->40 times faster!
Actually its a petty immidiate mode is not deprecated!
DrawElements is the way to go!
glVertexArray (…) // and etc.
Use GL_APPLE_vertex_array_range on os x.
I strongly suggest that you check this out!
Good luck!
Originally posted by <normals>:
[b]Are you calculating the normal vectors correctly?
If the points in the traingle are counter clockwise it should show by default. But if its clockwise then it might get culled or not shaded properly.
Maybe it has something to do with the order you are putting in your verticies? Remember the right hand rule? The thumb is the normal.[/b]
This might actually be the reason!
3DS files are stored in a lefthand oriented coordinate system.
( so is directx
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.