KGLX - Rendering Issues

[TapamN]

Oh. Ok, this runs at 60 FPS just fine. Looks like you disabled near clipping.

[PH3NOM]

Oh. Ok, this runs at 60 FPS just fine. Looks like you disabled near clipping.

Yeah, good eye but it is not a final solution. It is re-enabled in this build.

I am trying to get a feel for what the DC can handle, now easily pushing over 100,000 polys/sec

[TapamN]

Newest version is a constant 60 FPS.

[Neoblast]

Hum so the max at 60 fps is 100,000 polys?

[PH3NOM]

Hum so the max at 60 fps is 100,000 polys?

Well, somewhere between 110k->140k polys at 60fps seems to be the max using GlDrawArrays().

Has anyone achieved better using KGLXs?

[PH3NOM]

Hum so the max at 60 fps is 100,000 polys?

I just looked and KOS has an example to mark the performance of KGL.

My engine seems to achieve the same numbers as the trimark example in kos

[Bouz]

Just curiosity... Do you use any clipping algorithm to reduce the amount of polygons to submit?
Second question: have you tried compiling KOS without the DEBUG flag?

[Bouz]

And third question / remark: you could probably get more polygons by submitting strips instead of single triangles.

[PH3NOM]

Just curiosity... Do you use any clipping algorithm to reduce the amount of polygons to submit?
Second question: have you tried compiling KOS without the DEBUG flag?
And third question / remark: you could probably get more polygons by submitting strips instead of single triangles.

1 - No, it has not been necessary until recently. However, since I have reached the upper limits of polygon rendering with KGLX, I will soon need to implement frustum culling
http://en.wikipedia.org/wiki/Viewing_frustum. If you have any thoughts on the process send me a PM.
But, I am curious how the PVR's deferred rendering actually changes the fillrate
http://dcemulation.org/1-newsdump/QRand ... ta-reg.txt

2 - Yes. It did not benefit anything to warrant advising its use.

3 - Can you prove that? From what I can tell, in KGL they all boil down to the same function calls. From my tests,glDrawArrays() is the same performance as glDrawElements()

The next step for my engine is to load some sort of universal map format.
For now, I have chosen to use the Quake 3 BSP format, as it is well documented throughout the net.
I have written a very primitive Quake 3 BSP loader optimized for use with glDrawElements()

[Bouz]

Looking at my (old) KGLX code, I can say I use sequences of glBegin(GL_TRIANGLE_STRIP) / glTexCoord2f() / glVErtex3f() / ... / glEnd()

The function glEnd() calls function end_triangle_strip() in gldraw.c, which computes matrix transforms through mat_trans_single4 once per vertex and then submits vertices through direct render through pvr_dr_commit().
=> the stip method allows you to compute and submit less vertices to the PVR (for a strip of 10 triangles, you compute / submit 12 vertices instead of 30).
=> more than this, for the same strip, you keep the same texture and the same transform matrix, so you don't have to compute it for each triangle.
=> I keep thinking it is faster this way

To my mind, the clipping is the hardest part of the 3D engine. If you are using BSP trees, then a large part of the problem is solved for your environment. You might want to use quad / octree partitioning to determine what objects are potentially visible.

[PH3NOM]

Looking at my (old) KGLX code, I can say I use sequences of glBegin(GL_TRIANGLE_STRIP) / glTexCoord2f() / glVErtex3f() / ... / glEnd()

Instead of glTexCoord2f() and glVertex3f() I thought it should be faster to use an array of vertices and texture coordinates, then pass the arrays as
glTexCoordPointer() glVertexPointer()

To my mind, the clipping is the hardest part of the 3D engine. If you are using BSP trees, then a large part of the problem is solved for your environment. You might want to use quad / octree partitioning to determine what objects are potentially visible.

I agree. BSP's do provide a nice way of determining the "Potentially Visible Surface", although a lot of algorithms I have seen do not bother to use it.
Ray Tracing would be a very interesting mode of determination

Small update, got the textures mapping correctly with Quake 3 BSP rendering, using my code written in pure C and GL

[Bouz]

Instead of glTexCoord2f() and glVertex3f() I thought it should be faster to use an array of vertices and texture coordinates, then pass the arrays as
glTexCoordPointer() glVertexPointer()

OK, I might be completely stupid, but I can't find the source code for these 2 functions!!!

... but I still don't see how they could be faster than strips

I believe the only way to be sure of it is to do the test!

I will know more when my mysterious Blender strip exporter will be ready!

[Bouz]

One last question, then I stop bothering you...
Do you use back face culling? This might be one other way of speeding up your engine (but if you are limited by the polygon submit rate, it won't change anything).
In all KOS examples I have seen, it looks like that back face culling is disabled. The reason might be that the rendering part is faster than the submission part.