KGLX - Rendering Issues
-
- DC Developer
- Posts: 108
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Sun Oct 04, 2009 11:13 am
- Has thanked: 2 times
- Been thanked: 92 times
Re: KGLX - Rendering Issues
Oh. Ok, this runs at 60 FPS just fine. Looks like you disabled near clipping.
- PH3NOM
- DC Developer
- Posts: 576
- Joined: Fri Jun 18, 2010 9:29 pm
- Has thanked: 0
- Been thanked: 5 times
Re: KGLX - Rendering Issues
Yeah, good eye but it is not a final solution. It is re-enabled in this build.TapamN wrote:Oh. Ok, this runs at 60 FPS just fine. Looks like you disabled near clipping.
I am trying to get a feel for what the DC can handle, now easily pushing over 100,000 polys/sec
- Attachments
-
- dc-engine-3d-111312.rar
- (2.3 MiB) Downloaded 101 times
- PH3NOM
- DC Developer
- Posts: 576
- Joined: Fri Jun 18, 2010 9:29 pm
- Has thanked: 0
- Been thanked: 5 times
Re: KGLX - Rendering Issues
Well, somewhere between 110k->140k polys at 60fps seems to be the max using GlDrawArrays().Neoblast wrote:Hum so the max at 60 fps is 100,000 polys?
Has anyone achieved better using KGLXs?
- Attachments
-
- dc-engine-3d-111612.rar
- (2.59 MiB) Downloaded 81 times
- PH3NOM
- DC Developer
- Posts: 576
- Joined: Fri Jun 18, 2010 9:29 pm
- Has thanked: 0
- Been thanked: 5 times
Re: KGLX - Rendering Issues
I just looked and KOS has an example to mark the performance of KGL.Neoblast wrote:Hum so the max at 60 fps is 100,000 polys?
My engine seems to achieve the same numbers as the trimark example in kos
- Bouz
- DCEmu Junior
- Posts: 46
- Joined: Mon May 10, 2010 3:42 pm
- Location: St. Bauzille de Putois (France)
- Has thanked: 0
- Been thanked: 0
Re: KGLX - Rendering Issues
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?
Second question: have you tried compiling KOS without the DEBUG flag?
- Bouz
- DCEmu Junior
- Posts: 46
- Joined: Mon May 10, 2010 3:42 pm
- Location: St. Bauzille de Putois (France)
- Has thanked: 0
- Been thanked: 0
Re: KGLX - Rendering Issues
And third question / remark: you could probably get more polygons by submitting strips instead of single triangles.
- PH3NOM
- DC Developer
- Posts: 576
- Joined: Fri Jun 18, 2010 9:29 pm
- Has thanked: 0
- Been thanked: 5 times
DC-Engine-3D - Next Step: Loading BSP formats
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 cullingBouz wrote: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.
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
- DCEmu Junior
- Posts: 46
- Joined: Mon May 10, 2010 3:42 pm
- Location: St. Bauzille de Putois (France)
- Has thanked: 0
- Been thanked: 0
Re: KGLX - Rendering Issues
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.
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
- DC Developer
- Posts: 576
- Joined: Fri Jun 18, 2010 9:29 pm
- Has thanked: 0
- Been thanked: 5 times
Re: KGLX - Rendering Issues
Instead of glTexCoord2f() and glVertex3f() I thought it should be faster to use an array of vertices and texture coordinates, then pass the arrays asBouz wrote:Looking at my (old) KGLX code, I can say I use sequences of glBegin(GL_TRIANGLE_STRIP) / glTexCoord2f() / glVErtex3f() / ... / glEnd()
glTexCoordPointer() glVertexPointer()
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.Bouz wrote: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.
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
- DCEmu Junior
- Posts: 46
- Joined: Mon May 10, 2010 3:42 pm
- Location: St. Bauzille de Putois (France)
- Has thanked: 0
- Been thanked: 0
Re: KGLX - Rendering Issues
OK, I might be completely stupid, but I can't find the source code for these 2 functions!!!PH3NOM wrote: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()
... 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
- DCEmu Junior
- Posts: 46
- Joined: Mon May 10, 2010 3:42 pm
- Location: St. Bauzille de Putois (France)
- Has thanked: 0
- Been thanked: 0
Re: KGLX - Rendering Issues
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.
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.