Code:

%NSTime  % Time  Invoke #  Name
 41.769  41.769   449868  TSMeshRender
 13.566  13.566   150592  ShapeBaseRenderShadow
  9.450   9.677      828  AdvanceObjects
  8.495  54.097   151051  TSShapeInstanceRender
  6.037  82.144   151051  ShapeBaseRenderObject


The current biggest hogs in terms of CPU time (minus the time spent in profiled subroutines, so until I profiled TSMeshRender, TSShapeInstanceRender was taking about 50% of the time).
I understand what you're saying in that post, since I'm used to reading gprof output, but I think other people would be very confused by that %Time column. Very Happy
KermMartian wrote:
I understand what you're saying in that post, since I'm used to reading gprof output, but I think other people would be very confused by that %Time column. Very Happy


%NSTime is the important one since it shows where the real crunch is happening.

My big challenge right now is figuring out how to restructure the TSMesh rendering code to make good use of vertex buffer objects to cut down on the amount of data per frame that's shoveled across from main RAM to the GPU. With the Cemetech towers test


For those of you who are wondering why I'm putting so much effort into the DTS rendering pipeline instead of working on LDraw objects, it's because my plan is to implement LDraw objects as a subclass of TSMesh, to allow the models to be seamlessly dropped in to vehicles, rigidshapes, and players.
Which is a great idea, and the DTS rendering greatly needed to be updated.

However in most of my experience features like that are add and then optimized.
In this case I'm optimizing first so I have to do less structural reorganization later.
elfprince13 wrote:
In this case I'm optimizing first so I have to do less structural reorganization later.
Logical enough, but to build off the theme Sigfig was getting at, I bet we'll come up with more optimizations after the LDraw system is in place.
I'm sure we will, but I don't want to implement the entire LDraw system with vertex arrays and then do a rendering rewrite to get it to play nice with VBOs (which will be necessary to get anything like the performance we want).
I guess you're right, working with the LDraw library and custom ldraw files isn't something you could switch over easily.
TSSkinMeshes are presumably the only meshes that will need to be configured for DYNAMIC or STREAM usage (I'm guessing that DYNAMIC will be more efficient since it will prevent constant reallocations) when I begin writing the VBO code. Everything else should be okay as STATIC. Though...this evaluation is based solely on the animation code, and may change once I take a look at how detail levels work, I'm anticipating that to be a question of using IndexBuffers, and not with how the usage flags are configured. What I'd *really* like to figure out is if I can use the TextureManager to batch rendering even more efficiently by minimizing state changes related to texture swapping.

LDraw poly-rendering code will inherit from the Standard or Sorted mesh classes, so this is all a plus.

I haven't yet decided whether the brick class will inherit from SceneObject or GameBaseObject. I need to investigate the finer details of networking a little more before I make that decision.
In my purely subjective test, camera movement was smooth in TGEA, even with >2000 barrels on screen. This bodes well for my current theory that switching to VBOs will drastically improve framerates in the Cemetech Towers scenario.
After LDraw you should implement an octree much like Retails for hiding hidden faces.
Jimmg wrote:
After LDraw you should implement an octree much like Retails for hiding hidden faces.
For the trllionth time (cf Luquido's massive rant after elfprince13 suggested the same thing) octrees are not a panacea for slow rendering.
KermMartian wrote:
Jimmg wrote:
After LDraw you should implement an octree much like Retails for hiding hidden faces.
For the trllionth time (cf Luquido's massive rant after elfprince13 suggested the same thing) octrees are not a panacea for slow rendering.
Jimmg wrote:
After LDraw you should implement an octree much like Retails for hiding hidden faces.

That was probably helpful, but there are other significantly more helpful things that can be done as far as object management is concerned, which are being done in Freebuild. Also, hidden FACE removal is a terrible idea, faces are cheap. It's hidden object removal that is key.

The one thing that Retail has that Freebuild will be lacking is Ben Garney's physics diaper, which is pretty sweet, but well outside the scope of what I have the time to implement.
Hopefully after we have LDraw fully implemented more coders will join the project and be able to tackle those bigger things.
CyberPrime wrote:
Hopefully after we have LDraw fully implemented more coders will join the project and be able to tackle those bigger things.
Better start advertising then. TOB doesn't have any people of that caliber, and Retail and RTB aren't likely to provide many either.
The LDraw community has been around since the DOS days and has a very mature audience comparatively speaking. I'm sure there are some high caliber coders who subscribe to those listservs.
Definitely. I'm sure it won't be too hard to find a few coders out there willing to dedicate their time to a side project like this Smile
What if no one does?
Lucas W wrote:
What if no one does?

Its a possibility, and I didn't wanna ask, but it must be considered.
  
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 UTC - 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