| Author |
Message |
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10248
Location: A galaxy far far away......
|
 Posted: 22 May 2010 02:32:41 pm Post subject: Mah Head Asploded: On Tracing Rendering Bugs |
 |
|
One of the symptoms of rewriting the 3Space (the "TS" in .dts) rendering system is frequent asplodedness. Here you see me attempting to track down which of my buffers is misbehaving:
one of Cemetech Towers:
Minifig:
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative
 
 |
|
| Back to top |
|
|
Lucas W
Expert
Joined: 07 Sep 2009
Posts: 577
Location: Australia
|
| Posted: 22 May 2010 09:14:38 pm Post subject: |
|
|
| Wonder what one is on Cemetech Towers. |
|
| Back to top |
|
|
elrunethe2nd
Power User
Joined: 21 Nov 2008
Posts: 362
Location: In my infernal forge...
|
| Posted: 23 May 2010 11:16:06 am Post subject: Re: Mah Head Asploded: On Tracing Rendering Bugs |
|
|
| elfprince13 wrote: | One of the symptoms of rewriting the 3Space (the "TS" in .dts) rendering system is frequent asplodedness. Here you see me attempting to track down which of my buffers is misbehaving:
one of Cemetech Towers:
Minifig:
|
Similar effects occurred when you went miles and miles from the spawn point in TBM.
if you go 1000000 away from the spawn with the edit stick with TBG, does it still mess up as epically?
_________________
 |
|
| Back to top |
|
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10248
Location: A galaxy far far away......
|
| Posted: 23 May 2010 09:45:51 pm Post subject: |
|
|
So: I have my IBOs (Index Buffer Objects - GL_ELEMENT_ARRAY_BUFFER) up and running. I still need to debug my interlaced VBOs (Vertex Buffer Objects - GL_ARRAY_BUFFER). These will add a minimum requirement that your graphics card support OpenGL 1.4, but I should result in a substantial performance improvement once I have everything sorted out.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative
|
|
| Back to top |
|
|
KermMartian
Site Admin
Joined: 14 Mar 2005
Posts: 55886
Location: Earth, Sol, Milky Way
|
| Posted: 23 May 2010 11:54:36 pm Post subject: |
|
|
| elfprince13 wrote: | | So: I have my IBOs (Index Buffer Objects - GL_ELEMENT_ARRAY_BUFFER) up and running. I still need to debug my interlaced VBOs (Vertex Buffer Objects - GL_ARRAY_BUFFER). These will add a minimum requirement that your graphics card support OpenGL 1.4, but I should result in a substantial performance improvement once I have everything sorted out. |
Nice work, elfprince13. I was sad to hear on IRC though that in tests on two different graphics cards you see no improvements in frame rate. 
_________________
 
 
 |
|
| Back to top |
|
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10248
Location: A galaxy far far away......
|
| Posted: 24 May 2010 12:08:05 am Post subject: |
|
|
| KermMartian wrote: | | elfprince13 wrote: | | So: I have my IBOs (Index Buffer Objects - GL_ELEMENT_ARRAY_BUFFER) up and running. I still need to debug my interlaced VBOs (Vertex Buffer Objects - GL_ARRAY_BUFFER). These will add a minimum requirement that your graphics card support OpenGL 1.4, but I should result in a substantial performance improvement once I have everything sorted out. |
Nice work, elfprince13. I was sad to hear on IRC though that in tests on two different graphics cards you see no improvements in frame rate. |
Aye, I just finished both rewrites, and it doesn't seem to be helping, contrary to everything I've read about the use Vertex Buffer Objects. It seems I may have to do further work to try and avoid constantly switching buffers+textures (i.e. have all bricks with the same model + coloring render at once). Otherwise even with the improvements we're still going to be CPU bound because of the enormous number of OpenGL state changes that have to be handled for every mesh. There are two upsides to this, which are:
A) I now have a much better understanding of how to go about this, so I'm going to continue working on setting up interiors, terrains, and everything else for using buffer objects as well (and finish my work with TS meshes, because at the moment I'm only doing static meshes and not animated ones as well).
B) As long as we're CPU bound (and buffering models on the graphics card), we get more geometry per frame for free. What this means is that with my current setup, on any reasonably newish GPU, we probably wouldn't see any framerate different between Cemetech Towers as it is now, and Cemetech Towers built with LDraw models. Obviously we'd like to up that performance, but I think the transition to higher quality models won't hurt too badly.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative
|
|
| Back to top |
|
|
CyberPrime
Power User
Joined: 19 Apr 2009
Posts: 370
|
| Posted: 24 May 2010 03:56:28 pm Post subject: |
|
|
| That's a shame that we're not achieving much of an improved framerate. Granted, it's nice that we have better models. I suppose we will have to work more on the network lag. |
|
| Back to top |
|
|
calc84maniac
Epic z80 roflpwner
Joined: 01 Aug 2006
Posts: 1503
Location: The ex-planet Pluto
|
| Posted: 24 May 2010 09:28:10 pm Post subject: |
|
|
Indeed, I thought that was the whole speed issue. Fix the issues with the constant communication of data for every block across the network. What would have made the LDraw support increase the framerate anyway?
_________________
~calc84maniac has spoken.
Projects:
TI-Boy SE
F-Zero
Super Mario (aka Project M) |
|
| Back to top |
|
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10248
Location: A galaxy far far away......
|
| Posted: 25 May 2010 01:17:37 am Post subject: |
|
|
| CyberPrime wrote: | | That's a shame that we're not achieving much of an improved framerate. Granted, it's nice that we have better models. I suppose we will have to work more on the network lag. |
| calc84maniac wrote: | | Indeed, I thought that was the whole speed issue. Fix the issues with the constant communication of data for every block across the network. What would have made the LDraw support increase the framerate anyway? |
See, here's the thing: right now the framerate issues are NOT network lag. They are the result of the CPU not being able to push geometry to the GPU quickly enough. The TS rendering system abuses OpenGL significantly, and I've been cleaning it up all week. The changes I made today actually appear to have dropped the framerate by about 20%, but I'm hoping that by reworking the way in which TSShapes are inserted into the scenegraph and the way in which SceneRenderImages are sorted so that models which share texture and vertex data will be rendered without extraneous state changes I'll squeeze a lot more performance out of it. The question at this point is whether I can afford to qsort by primitives (individual calls to glDrawElements), or whether I need to sort at a higher level and use some form of hardcoded buckets for the low level.
Network lag will eventually be an issue to address, and moving the LDraw bricks off of constantly ticking shapebase objects to a new class will help with that, but profiling shows that the rendering issues are a lot more pressing right now. A big tip-off on that count is that even playing as a single player on your own computer (where Torque makes use of a special internal fake-socket for sending updates, instead of the normal network layer), you still experience the same framerate issues as you do over a network.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative
|
|
| Back to top |
|
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10248
Location: A galaxy far far away......
|
| Posted: 25 May 2010 12:34:42 pm Post subject: |
|
|
Here are my notes from today/last night:
| Quote: | DO WORK WITH SceneRenderImage, and cmpImageFunc. We should produce one for each primitive.....
TODO:
- figure out where .dif fits into the picture
- fix up TSSortedMesh and TSDecalMesh
- Break out sorting by mesh.
TSPrimitiveBatcher
- ->renderObject.
- Maintain current texture and other settings.
- Take over rendering duties from shapebase, et al.
TSBatchRenderImage -
- TSShapeInstance
- TSShapeInstance wrapper mesh index
- primitive index.
- textureSortKey - textureHandle
- bufferSortKey
- the usual stuff
SceneState:
- renderCurrentImages:
- sortRenderImages
- buildTranslucentBSP
- renderImage * 2
- renderNode
- renderImage
renderImage(SceneState, SceneRenderImage) -> SceneObject::renderObject()
cmpImageFunc - modify to sort by texture, than buffer |
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative
|
|
| Back to top |
|
|
DShiznit
Guru-in-Training
Joined: 14 Jan 2007
Posts: 3690
Location: The 24th Century
|
| Posted: 25 May 2010 07:17:19 pm Post subject: |
|
|
| I think you should just leave DIFs alone if you can for now, I don't think they're used in large enough quantities to make much of a difference, and reworking them might be more trouble than it's worth. |
|
| Back to top |
|
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10248
Location: A galaxy far far away......
|
| Posted: 25 May 2010 10:40:04 pm Post subject: |
|
|
| DShiznit wrote: | | I think you should just leave DIFs alone if you can for now, I don't think they're used in large enough quantities to make much of a difference, and reworking them might be more trouble than it's worth. |
render calls for DIFs and opaque TS meshes are sorted the same way in the rendering queue (and DIFs can even have TS meshes baked in), so it's something I should take care of.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative
|
|
| Back to top |
|
|
elrunethe2nd
Power User
Joined: 21 Nov 2008
Posts: 362
Location: In my infernal forge...
|
| Posted: 27 May 2010 08:55:49 pm Post subject: Re: Mah Head Asploded: On Tracing Rendering Bugs |
|
|
| elrunethe2nd wrote: |
Similar effects occurred when you went miles and miles from the spawn point in TBM.
if you go 1000000 away from the spawn with the edit stick with TBG, does it still mess up as epically? |
_________________
|
|
| Back to top |
|
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10248
Location: A galaxy far far away......
|
| Posted: 27 May 2010 10:14:14 pm Post subject: Re: Mah Head Asploded: On Tracing Rendering Bugs |
|
|
| elrunethe2nd wrote: | | elrunethe2nd wrote: |
Similar effects occurred when you went miles and miles from the spawn point in TBM.
if you go 1000000 away from the spawn with the edit stick with TBG, does it still mess up as epically? |
|
I have no idea. Presumably at some point you'd encounter overflow bugs, but I'm not sure how far away you'd have to go. With 3 axises, a 2s complement integer coordinate system would be topologically like a hypertorus, but IEEE floating point implementations shouldn't wrap, so I do think it's a wrapping problem, just some sort of weird overflow error. Can you map the exact point at which things get screwy and take a screenshot + give me the coordinates?
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative
|
|
| Back to top |
|
|
Lucas W
Expert
Joined: 07 Sep 2009
Posts: 577
Location: Australia
|
| Posted: 28 May 2010 12:37:13 am Post subject: |
|
|
As Elrune said, go 1000000 away in any direction:
 |
|
| Back to top |
|
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10248
Location: A galaxy far far away......
|
|
| Back to top |
|
|
Lucas W
Expert
Joined: 07 Sep 2009
Posts: 577
Location: Australia
|
| Posted: 28 May 2010 01:51:56 am Post subject: |
|
|
Water starts acting really weird around:
3.09687 53071.3 85.1651 (On cemetech city) |
|
| Back to top |
|
|
KermMartian
Site Admin
Joined: 14 Mar 2005
Posts: 55886
Location: Earth, Sol, Milky Way
|
| Posted: 28 May 2010 10:25:12 am Post subject: |
|
|
[quote="elfprince13"]My question is whether or not it happens before you get to 1,000,000? That is a suspiciously round number.
Anyway, it looks like a problem with calculating the depth of individual triangles in the scene.[/quoteI was hoping it would be one of those suspiciously power-of-two numbers like 65535 or 32768 or 131072.
_________________
|
|
| Back to top |
|
|
elrunethe2nd
Power User
Joined: 21 Nov 2008
Posts: 362
Location: In my infernal forge...
|
| Posted: 28 May 2010 01:35:39 pm Post subject: |
|
|
I have never tried to get the specific point of collapse, but it seems to mess up everything.
If you load an iGob, the building can melt, or s often strewn around on load. Building anything and saving has the same issue.
I find that it's only really useful to avoid being killed by an abuser, as guns don't work properly there either.
_________________
|
|
| Back to top |
|
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10248
Location: A galaxy far far away......
|
| Posted: 30 May 2010 10:39:32 am Post subject: |
|
|
Lucas, thanks for the report. That is a good initial observation
| KermMartian wrote: | | I was hoping it would be one of those suspiciously power-of-two numbers like 65535 or 32768 or 131072. |
My suspicion is that it is going to have more to do with a floating point break down than an int....
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative
|
|
| Back to top |
|
|
|
![[t]](/forum/templates/Cemetech6/images/twitter.png)
![[t]](/forum/templates/Cemetech6/images/fb.png)
![[RSS]](/forum/templates/Cemetech6/images/rss.png)
