Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
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:

Wonder what one is on Cemetech Towers.
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?
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.
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. Sad
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. Sad

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.
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.
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?
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.
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
      • cmpImageFunc

    • buildTranslucentBSP
    • renderImage * 2
    • renderNode
    • renderImage



renderImage(SceneState, SceneRenderImage) -> SceneObject::renderObject()


cmpImageFunc - modify to sort by texture, than buffer
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.
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.
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?
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?
As Elrune said, go 1000000 away in any direction:

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.
Water starts acting really weird around:

3.09687 53071.3 85.1651 (On cemetech city)
[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.
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.
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....
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement