Modernization Kit Beta Thread 2

#81 Okay, definition of a zone as it pertains to interiors.

Interiors are made up of zones. There will always be one zone in an interior, but there could be more (this is the whole "Zone and portalize your interior!" thing). When Torque goes to render an interior, it determines what zones of the interior are in view. Any zone that isn't in view doesn't get rendered. This is a very fast, simple, and effective way of culling very large amounts of geometry if the interior is properly set up.

The limit which would be imposed by the even faster MK renderer is 65k verts per zone in the interior. So if your interior consists of two zones, then each zone could contain 65k verts and the interior as a whole would contain 130k.

This has nothing to do with what zone an interior is currently in, or other objects in the zone, or any of that. Torque does do some extra fancy stuff behind the scenes here (This object is in this zone, but this zone isn't visible so this object doesn't have to be rendered), but that isn't pertinent to the discussion at hand.

So, for the example of "I'm looking at eight interiors", the answer is: That's irrelevant. Does each zone of each interior contain less than 65k verts of geometry for that interior? If the answer is yes, then you're fine.

Put another way, this limitation would be dealt with when modelling the interior. It's placement, what goes in it in the mission, etc. has no bearing on this.

Hopefully that clears this up.

Now then, to address specific non zone related concerns.

Quote:You also mentioned you optimized the code even more before making the VBO changes, how much of a performance increase are we talking about before the VBO changes?

As it stands right now, interior rendering for a particular scene shows up as 10% of CPU time on the profiler. In build 10, the same scene showed up as 40% on the profiler. In stock TGE it shows up as about 15% on the profiler. From other profiling data gathered I can guarantee that using one VBO per zone will drop it down to below 9%.

Quote:They use CSG based shapes for structures, and dts-style shapes for props, just like we are suggesting.

I'm going to second that suggestion. Do that. Properly place portals and zones in your interiors. Cut down on texture sizes (I don't care how nice that 1024x1024 texture looks, it isn't worth the 4MB of RAM and VRAM). These things will improve your performance more than anything I could ever do.

Quote:torque however isn't a speedy dts rendering engine.

Minor correction: Torque isn't a speedy rendering engine. But it's great for low end hardware (the MK isn't.)

Quote:DTS faster than DIF stuff

There are a lot of things that can contribute to that. Changing the lightmap probably isn't a performance problem, but the fact that each lightmap change means another draw call probably is. Fogging is more complex on interiors, and requires more CPU time to set up than fogging on DTS. DIF shapes also do a lot of other misc. setup for rendering which DTS shapes don't go through. Note that all of this misc. setup and fogging is gone the new MK renderer (misc setup obsolete and removed, fogging done in the vertex shader). The new renderer dramatically reduces the expense of additional draw calls by limiting the number of changes made to the current GL state and by using hardware vertex buffers for all interior geometry data.

And that should cover everything. Whew.

#82 So basically what you're saying is that the mk, running on decent hardware, will actually render as fast or faster then stock torque running on mediocre hardware?

Thanks for clearing up the exteriors of interiors, as that's the case, the speedier version is fine by me. Basically, there are a ton of things i can do to keep my interior zones waaaaaaay under the 65k limit, even if i used difs as props. I think worse case scenario is the torque demo building that has no portals and is fairly complex, would be one of the more complex objects in most games, which could really be tightened up quite a bit. I say onward to 9%! o_O or something...

#83 Holy crow. 9% vs 40% is a big difference. And the per zone limitation seems reasonable. I'm changing my vote to go for the performance.

#84

Quote:So basically what you're saying is that the mk, running on decent hardware, will actually render as fast or faster then stock torque running on mediocre hardware?

That's really dependent on what's going on in the scene, and what effects you're using, but for the most part, yes.

#85 The problem with DIF is... what if you want destructible buildings?

As for the question at hand, I'm also going the performance route. 65k vertices is /lot/.

#86 Just to keep you guys up to date on what I've been doing (I feel bad about the three months of silence, can you tell?)

I've set up a bug tracker (just for my use, sorry! If I had somewhere online to put it I'd certainly make it public, but for now it's just on my macbook) to help... well, track bugs and issues.


I've got a few issues to take care of.

Now then, I also wanted to chime in quickly on performance of the new renderer. As you can tell from the tracker, I haven't switched over to one VBO per zone yet, so this isn't representative of final performance, but it should serve to give you an idea of where things are going.


There's the scene I used for performance comparison. Big interior, animated DTS shape, particles, and, even though you can't see it, the terrain is being rendered (the 1.5.0 demo interiors are pretty bad).

In stock TGE 1.5., that scene runs around 80 FPS. In MK build 10, using the fixed function emulation shader (yes, it has one!), that scene runs at 65 FPS. In MK build 11, that scene runs at 95FPS. No joke, build 11 is up to 50% faster than build 10.

And that's what I've been up to for the past couple of days. I assume no one will mind if I bump this thread every few days with what I've been up to? I do want to keep you all informed, and this seems to be a better way than bombarding the mailing list with something every couple of days.

#87 @Alex

I don't think anyone will mind your thread bump info updates. I know I won't. :)

#88 Cool! I'd love to also hear how you're fixing things, but a plain bump is enough for me. Mostly adding shaders? What are the issues you are running into? And gotchyas we should be watching for?

#89 Thats insane alex! good job. cant believe Mk is now running faster then Stock TGE!

#90 Very very cool Alex.

#91 Great work Alex!

Side note: Please contribute the VBO rendering speed-ups back to the base TGE code.

Side side note: What bug tracker are you using? If it will run on OpenBSD, I can host it for you... drop me a note.

#92 Okay, implemented the per zone VBO renderer. That increased FPS by roughly 5%, so the test scene now gets ~100FPS.

@EddieRay:

Quote:Side note: Please contribute the VBO rendering speed-ups back to the base TGE code.

Porting the enhancements back into stock TGE would be rather difficult, as the new renderer requires vertex shaders to calculate fogging. Doing the fogging in a second pass, or using a dynamic VBO alongside the static one, would decrese performance drastically, possibly dropping it below stock TGE.

Quote:What bug tracker are you using? If it will run on OpenBSD, I can host it for you... drop me a note.

I'm using Mantis. Presumably it'll run on OpenBSD just fine.

#93

Quote:Porting the enhancements back into stock TGE would be rather difficult, as the new renderer requires vertex shaders to calculate fogging. Doing the fogging in a second pass, or using a dynamic VBO alongside the static one, would decrese performance drastically, possibly dropping it below stock TGE.

I was hoping you might be able to adapt it to shaderless TGE... it might be worth a shot tho'. Isn't there something you're doing besides the vertex-shader fogging that is increasing performance... even if it's not the full increase?

Quote:I'm using Mantis. Presumably it'll run on OpenBSD just fine.

Email me so I can get the bug data from you and I'll try to set it up on my server tomorrow.

#94 Alex... all I can say is RESPECT :D

I really apprciate the way your keeping us informed of your progress (wish GG would take note !!! lol)

#95 The progress you are doing with this are great.

#96 Great work Alex and real winner in getting the performance boosts, build 11 looks set to be a major milestone for all those with an interest in the modernization kit. Let us know if we can help you out with any of the work.

#97 Sounds brilliant, can't wait for the next build! A question, though. For my project, I'd love to have the MK included. However, I want the game to be able to run for as many people as possible, and that means posibly older systems. Is there a way to turn parts of the MK off? For example, normal mapping of interiors? If not, it's okay - I can simply release two .exes, one with the MK and one without.

#98 Great Looking Stuff... Big Kudos to Alex and all that have helped in this...


one big thing though... poor ole Kork... he just looks like an afterthought in every Modern-ized TGE scene that i've seen him in...

every thing else in the scene is spectacularly specularized and bump mapped except him... and this makes him stand out like a sore thumb...

--Mike

#99 Sounds like a job for SpaceKork ^^

But it is definitely looking better and better :-)

#100 Sorry, I'm a noob to TGE (I just purchased it). What is the moderization kit and how do I get involved?