Modernization Kit Beta Thread 2

#61 I like the second version, but it looks like there is some kind of ambient light component being added in because the stuff that used to be black off in the distance is now gray. Also, the "grout lines" seem to stand out more than maybe they should. Have you tried turning on anisotropic filtering with version 1 to see what that looks like (just a guess - not even sure if that would have any effect here)?

A good example of an extremely popular casual game that is 3D is Disney's Toontown Online.

#62 Right, I'm doing some final architectural overview/tweaks to the new interior renderer before moving on to other things.

At the moment, the new interior renderer does a preprocess pass on the interior. It loops through each zone. For each zone, it loops through all the surfaces, and groups them according to material and lightmap. All surfaces with the same material and same lightmap are put into an mkInteriorRenderBatch, which contains the lightmap, the material, a vertex buffer and an index buffer. When rendering, we determine which zones are visible and then render all the batches associated with those zones.

The new renderer supports interiors of any size.

Now then, I can squeeze more performance out of this by putting the entire zone into a single vertex buffer, and then each batch would only contain an index buffer. This would improve performance (possibly by a substantial amount), but it would place a cap on the number of vertices per zone, specifically ~65,000 (for comparison the great hall from the TGE 1.5.0 demo contains 55k verts).

So, would you guys like better performance with the possibility of having to change your interiors, or less performance (but still significantly faster than before!) with no limits on what you can do with your interiors?

#63 I'd vote for less performance but no limits on vertices. It seems that if the great hall has 55k verts, that is getting too close to the limit. Ideal solution would be to have a preference setting that determined if you use a single vertex buffer or not, but not knowing how isolated the code is, that may not be possible.

#64 Less performance sounds good to me.

#65 Less performance but no limits on vertices sounds really good for me to!

#66 My vote is for the no limit as well. I have a few cities with a good deal of interiors.

As far as the normals, i haven't had a chance to go over the issue yet, but i know i can get up to about 10 materials to work fine and load most of the time. Which is fine for the majority, but it seems thats the breaking point. It could be that i'm just making typo errors (although i have triple checked the scripts in the past), so let me check into it more before anyone goes into debug mode.

I do have to thank you yet again Alex for all your amazing work on this and I'm sure other (lesser known) contributions to the tge.

#67 I agree with less performance and no limits.

As a tangent, how do DTS objects fit into the equation? I'm always prone to having more DTS than DIF, though I'm trying to balance that better.

#68

Quote:Now then, I can squeeze more performance out of this by putting the entire zone into a single vertex buffer, and then each batch would only contain an index buffer. This would improve performance (possibly by a substantial amount), but it would place a cap on the number of vertices per zone, specifically ~65,000 (for comparison the great hall from the TGE 1.5.0 demo contains 55k verts).

I think it depends on how much of a performance gain. Is this the real bottleneck that is slowing down interiors with MK?

#69

Quote:As a tangent, how do DTS objects fit into the equation? I'm always prone to having more DTS than DIF, though I'm trying to balance that better.

I agree with Don here, since the release of Constructor and the DTS-bake-in feature working with high detailed DIFs is beginning to grow less and less important (granted that baked-in-DTS culling is implemented).
If (baked-in)DTS shapes doesn't count, would ~65k verts be a problem?

#70 At the moment DTS shapes don't go into the equation, baked into the dif or not (I'm still working in 1.5.0).

Also, just in case I wasn't clear, it'd be a limited number of vertices per zone, not for the entire interior.

@EddieRay: Yes, it is. Switching VBOs is the only operation I can optimize out now. Everything else is as fast as it can get.

#71 For example: I'm standing in a town that has about 8 buildings and i exceed the limit just looking at them... How does that fit into the per zone limit? Say even if i use portals to keep the inside render count down.

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 far as DTS, if you're using more dts object on your interiors then DIF's or even on your levels, then your going to kill your frame rate regardless of the mk being optimized or not. DTS objects are not intended to be used that way in just about any modern engine. BSP is the way to go especially with these spiffy updates. Aside from outside objects, doors and player objects that is.

#72 @Jason:

Quote:As far as DTS, if you're using more dts object on your interiors then DIF's or even on your levels, then your going to kill your frame rate regardless of the mk being optimized or not.

The problem with the DTS-in-DIF currently is culling, or to be more precise, the lack of it. This is a engine-issue and nothing a MK-addon should need to worry about.

Quote:DTS objects are not intended to be used that way in just about any modern engine.

I beg to differ; Epic have proved quite the opposite with just about every engine-tech they released since 2003 ...

#73

Quote:
I beg to differ; Epic have proved quite the opposite with just about every engine-tech they released since 2003 ...

that's not true at all actually. They use CSG based shapes for structures, and dts-style shapes for props, just like we are suggesting.

#74 @Stephen: That was actually the point I aimed for, unfortunately I didn't make myself clear enough. :)

#75 I'm going to have to step up and confess I don't understand the 'per zone' definition. Can someone give a 'artist-speak' clarification?

Now, let me back up a moment - a second confession is in order, also. It could be argued that my opinion is sort of moot on this since I'm not modeling the same way it seems most people are.

For now, everything I've worked on has been DTS shapes for buildings. Why? Well, that's the way we worked on the GameCube - every room was 100% unique geometry built in maya and exported with hand-made polysoup collision. After doing that for 6 years, it's a really slow transition to DIFs; and even with a good tool like constructor, I can't stand not being able to edit my UVs. Add in that this is in my spare time, and I'm not really up to speed on the Torque guildelines / pipline at all.

So, that's what's behind my DTS question, just as a point of clarification.

#76 The problem is really not so much culling with interiors, unless your interiors are huge with a large amount of dts objects in a zone, culling wont do much for performance. Which is maybe the reason GG hasn't implemented it? Although I'm sure it is possible to make a staircase with 30k polys, in which case would make a major improvement with culling, but that is overkill for a real-time engine.

Poly based render is slower then brush based render by a great deal, totally due to the difference in structure of the 2. Really the key issue with using BSP models is details and currently they look pretty good and render pretty darn quick to. Adding the MK to that even with the performance hit (hopefully a slighter one when it's all said and done) will help make structure DTS objects less desirable. I'm not sure how Epic did it, but I'd like to see that one in action, torque however isn't a speedy dts rendering engine.

#77 In general, we've found that we get better frame rates using DTS's vs. DIF's (for certain DIF's at least - and we don't really have any "complex" ones). But our objects are generally viewed from outside (props off to the side of the action, etc.). The DIF version *should* be fast, but it's not for some reason (which we've yet to uncover). So don't feel bad about using DTS. You lose the self-shadowing (via lightmaps) but it might not matter for your game (i.e. for scenery flying by in a ski-racing game - which you can't even really see clearly or long enough to matter, etc.).

The MK tends to make matters worse for DIFs viewed from the outside. When the player is inside, you can take advantage of the BSP culling, and triangle culling of things that TGE thinks are "in view" but are actually behind huge DIF planes that are close to the camera (assuming they're drawn first), but it seems the whole thing is aggravated when you can see the outside of the DIF on-screen... if it's using material(s) and/or has some complexity to it.

Frame-rates are a big issue, so I'd vote for maximizing frame-rate in the MK even if it has a few limitation associated with it.

#78 My (uncomfirmed) suspicion for why DIFs tend to drag the frame-rates is because of the lightmaps - and how they cause lots of texture unit changes during even the rendering of a single DIF that uses a common base texture on every surface. Depending on the world-unit side of the DIF, and the lightmap scaling, there can be a lot of separate lightmaps associated with even this "ideal" kind of DIF. But then again, rendering a frame of all the different geometry types tends to involve a lot of different textures (and texture switching), so maybe it's something more subtle. Maybe the TGE DIF rendering doesn't order vertices/triangles to maximize the effectiveness of the transformed-vertex cache... or such...

#79 @Don: Zoning is the same as culling with one major exception, zoning uses portals (hidden meshes that block out renderable objects through doorways, windows or other holes in a bsp interior. Culling is rendering only what is seen, so if a player turns something out of view, it's set aside in the scene render. If a poly based object, like a pipe, ladder, metal staircase, and so on (dts) is *baked* into a BSP based object (dif) culling isn't used (supposedly) to keep that object from rendering until you're out of that zone, even if it's not in view.

The gamecube rendering engine is quite a bit different (obviously) then the Torque engine and I really have no idea what model base is exported out of Maya to make objects on the gamecube. Realistically though, you can export a DIF out of Maya as long as it's not too complex.

#80 Regarding culling, I think the "DIF occludes other objects so they should be culled" has a significant impact on frame rate... for outdoor scenes at least. There's a significant amount of rendering there that could be avoided altogether. I mean, if you have one large DIF duplicated in your mission, and you walk up to the front of it and it blocks the 5 copies behind it completely from view, that's a lot of objects/surfaces/triangles that don't need to be drawn. For outdoor missions, I think TGE frame-rates suffer from the lack of this feature, if there is a significant number of objects in the mission. For wide rolling-hills with just a few objects here and there, or the players fly through the "air" and can see everything in the facing direction, it wouldn't make a difference, certainly, but if you want to have lots of stuff for your player to see, and you can take advantage of it with your gameplay, then those objects can effectively be placed to cull huge swaths of other objects from view when the player is nearby them... increasing the overall frame-rate while actually increasing the "detail" of the world.