GG, please, keep BSP support for T2

#1 In another thread Stephen meant there would probably be DTS legacy support, so maybe there would be legacy DIF support.

#2 I just hope there will be a bug free solution. While constructor is amazing an' all, it doesn't work very well and the maps it produces don't always work. I fear integrating a new tech such as polysoup will just mean more point releases before a stable build is done, making it impossible to launch a title until all the bugs are fixed.

#3 It's all down to design goals. Personally - I have no problems with either technique, I can work with Hammer, Quark, Constructor, Max, Maya- you name it but consider this: if you want to do games for modern audience you can't base on solutions that are becoming increasingly obsolete (unless you have nice niche of hardware actually using obsolete solutions- like mobile phones re-using old PC games technology for example) .

It's a tough job of balancing accessibility/ease of use with performance/technological progress. I do not really envy GG people having to solve this dilemma.

#4 There's no sense into dropping something simpler to make and faster to render simply because "it's out of fashion".

#5 Someone made a very good point, most likely at one of the round tables at IGC (if it wasn't just something someone mentioned to me).

There may very well still end up being a way to load DIFs, there won't be a render module for BSP type geometry (someone could write one though) but basically it would convert the data to polygons. (which should be reasonably "trivial"). On that same note, there's really no reason or indication that constructor will go away. It could be extended to do more general polygon editing. Basically all the advantages of a proper level building tool without the headaches of BSP....

#6 For the record, I personally am on the side of keeping the DIF format for the times when you need the additional performance, but I'm just one voice of many (and not only the community in general, but game industry in general is behind moving to full poly soup as the primary option).

As it stands right now, we won't be porting over a full BSP style rendering/collision graph, but the modular nature of Torque 2 allows for both reading .map/.csx files in as poly soup, as well as easy addition of custom BSP implementations if your project requires it.

#7 The thought the BSP's are any more faster than rendering poly-soup is just not correct. BSP trees were good back in the days of software renderers, when you had to be careful to have as little overdraw as possible (it's easy to draw from front to back order), but those days are long gone. Now it is much more important to draw polygons by material (and thus lowering state changes) - something a BSP does not help with at all. BSP's are not even good for collision detection anymore, since they tend to dramatically increase the polygon count.
Still, it is easier for many people to model levels with solids - there's no reason why a good exporter couldn't be written for constructor.

#8 BSP optimizations have nothing to do with draw order or state changes--it has to do with early out culling for rendering optimization, and guaranteed convex brush checks for fine detail collision checking--neither of which are possible with free poly implementations.

You are correct that state changes are important for optimization, but the benefits of BSP aren't related to either draw order or state change minimization.

#9 Edit : arrh Jaimi you erased your post too quickly x|

Quote:I am sure we are boring everyone else.

In fact it is actually very interesting to read ^^'

Quote:Still, the point I wanted to make was that having a poly soup would not preclude making a world out of solids, which is what the original poster seems to be preferring.

Yep I was worried mostly about that (it is a good thing that Ctor is not completely out), but my question was also about performance. I may prefer saving any power I can for rendering very detailed characters instead of very detailed buildings.

#10

Quote:arrh Jaimi you erased your post too quickly

Sorry - I thought maybe I was being to argumentative. I get into "lecture mode" and find it hard to stop.

Quote:but my question was also about performance

In my opinion, there is great potential for slowdown due to implementation details with a BSP. (they're inefficient, because they make too many polygons, and they present the data in an order that is inefficient for rendering).
However, there is also great potential for slowdown with polysoup due to artistic details (it's much easier to make slow to render scenes - when nothing is stopping you from making crazy curved walls with 10,000 faces... etc)

I feel that with a knowledgeable artist, that you can create levels that render faster with polysoup than you could with a bsp, given a perfect bsp renderer and a perfect polysoup renderer.

#11 Torque 2?

Is it TGEA?

#12 No Sun Yu, it is the next gen. engine from GG.

#13 Thanks, Stephan. Are there any pages introducing Torque 2?

#14 Interesting stuff ... I, for one, will be HAPPY to get rid of BSP editing ... so much faster to get nice shapes in a 3D program. I have to admit that in certain instances, the 'world' space texturing in BSP editors like Constructor are great, though.

One question about this polysoup biz... does this mean that ALL polygons will be drawn on the screen, or can you still 'portal/zone' out areas to not draw??? i.e. so that it won't draw all of the interior furniture, etc, while outside???

#15 Sun Yu go here

As for BSP vs Poly Soup-

I've listened to much of the debate thats gone on and while I agree that poly soup is the future. I think its premature to drop BSP support. Torque tech is used to make a very large variety of games. If you are making an action FPS poly soup might make a lot of sense. But game genres such as MMO's rely heavily on DIF culling to maintain a stable frame rate. Some of the game worlds I'm working with right now are going to possibly have hundreds of players/buildings in a very small area.

As for T2 dropping BSP-

I'm not too terribly worried about it. I'll be testing out poly soup to see if its actually practical and if its not I'll add dif support. That is if Torque 2 is actually modular I should be able to make my own module to add .dif support.

#16 Okay, so here is the thing about BSP and Torque:

Torque doesn't use BSP for any rendering optimizations. At all.

At run time, Torque only uses BSP to speed up the ray cast calculations against the Interiors and even that algorithm doesn't make use of the fact that the Interior geometry is convex (but the tsShape code does...ironically).

There is a simple "bins" system that is actually used for getting a list of brushes/polys for the Player, Vehicles, Items, etc to collide against because it turned out to be significantly faster than using the BSP tree. Quite possibly, using this same system for ray casts could offer comparable or better speeds than the current BSP ray casts. This "bins" system is also completely applicable to a polysoup implementation (it was a really early implementation of the system that evolved into what you see in TorqueX and will see further extended into Torque 2).

So what does BSP actually gain us?

Directly it gains us two things: easy hidden surface removal and easy zone generation

When you restrict yourself to closed convex volumes (aka brushes) you can use a BSP tree to quickly and efficiently (hah) do hidden surface removal and to generate sealed (leak free) zones. However, this is an "offline", pre-process step and using a BSP doesn't directly help our run time performance.

As Jaimi touched on, hidden surface removal is actually largely counter-productive with modern GPU's where how many triangles you render is often far less important than how few state/texture changes you go through to do so. And, honestly, most artists are so inexperienced with the proper use of detail brushes that the hidden surface removal often results in *far* more polys than you are culling out (cutting a floor poly into 16 new polys to save on rendering 1 poly from the bottom of a column helps no one). The polysoup equivalent of most Interiors would likely have less polys since the artist will manually do the hidden surface removal and you won't get hard to diagnose "missing faces".

Zones are actually pretty easy to recreate in a polysoup environment. All you need is a way to associate a list of polygons with a specific zone (tag them, texture them, or create an inclusive volume) and some flat, rectangular "portal" polys with a "front" and "back" zone tied to it somehow. Yes, this would be more tedious to do by hand for the artists but not painfully so (especially with some helper tools in the modelling applications) and it could actually allow for far better control and even for some interesting "tricks".

Indirectly, the use of BSP's during the pre-process/export forcecs you to use closed convex volumes (again aka brushes) which means your collision meshes always match your visible meshes so you end up with poly perfect collision. The use of these convex collision meshes also can greatly speed up the convex vs convex collision calcs in the engine like with the Vehicles and with the scene lighting.

Theoretically, if you were to switch the ray casts to using the "bins" system rather than the BSP tree plus add support for "portals" and "zones" to your 3d modelling exporter, then you could use the Interior system for polysoup pretty effectively right now (before you ask I don't plan to do that anytime soon so don't go getting too excited =P).

Dropping the "BSP" from Torque 2 in favor of a robust polysoup solution is not that big of a deal since Torque has never used BSP in a highly optimized manner anyway (it wasn't as useful in an open terrain environment as it is in a completely enclosed brush environment). I, for one, would be more than happy to lose the unpredictable and hard-to-use automatic HSR and zoning as long as the artists can still accomplish those effects somehow. So, ding dong let the BSP die! =)

#17 I did want to follow up on this with one more piece of information.

The BSP is used to decide which objects are in which zones at any given point in InteriorInstance::getOverlappingZones(). This would also require replacement to switch the Interiors to being purely polysoup. Perhaps by having the artists define a set of convex volumes that roughly define the shape of the zone? Or something even courser than that?

Anyway...I just wanted to point that out.

#18 Thanks much for that info, Matt. Good to know. This may or may not be the place to ask, but there's currently (1.5.2 with Lighting Kit) a huge difference in how DIF vs DTS objects get lit... will the polysoup method look good, but saccrifice on lighting?... maybe we are doing something wrong right now, but DTS shapes light terribly, which is why I'm struggling so much with trying to make 'organic' interior DIFs.

#19 Looking at how the static meshes are lit in TGE 1.5.2 might give you a better indication of how things will look in Torque 2 if we decide to go with lightmapping (as opposed to a fully dynamic shadow solution).

#20 Does that mean vertex lighting or per pixel? Because the vertex lighting doesn't work so hot for many things, including environments... been tried on 'cave walls' at least ... That was a dynamic 'flashlight' that didn't work well... even on characters' faces, which contain a lot more verts.