Heres a good argument (keep it civil)

#1 Is dif inconsistent like BSP?

#2 Depends on what the geometery is used for rendering only or collision only or both? For rendering BSP is pretty much dead on recent graphics cards as it is faster to let the card do the culling, and still appliciable for collision detection.

#3 Hmmm k, we were just arguing about what the best way to do mapping would be. Edit: Spelling

#4 I would LOVE to be able to make everything in max instead of going to quark. quark is a good program but i have a hard time getting the level of detail with quark that i can get with max.

#5 You see, i'm working on my own editor (look in my plans). I have sooo much ideas, and so little time. So, one of these days on our site i'll ask people what they wnat in the editor, i'm thinking about making a complete editor, for torque. Terrain, 3DS Importing, Plugins Architechture, World editing, all kinds of stuff, but thats all talk, so anyways back to work for me.

#6 *cracks whip*

#7 I prefer using 3dsmax as my editor. A few years ago BSP was the only way to go, but these days occlusion is less of a big deal. Not haveing to create solid closed hull geometry has big benefits, artists can build levels optimized by removing backfaces, faces that are never seen by the camera, often underside or on top of tall objects in places the camera never sees.

Often with experience you can reduce your level geometry by at least half what you would using a similar BSP level.

You also don't usually need completely acurate collisions which is in many cases a waste of CPU, and can effect gameplay adversely rather than being the big bonus one would expect.

For instance in my current MP vehicle combat game that plays like a high speed FPS, all the visible geometry is not used in any actual Gameplay AI so it has no collision and no linepicks. It just visual, and for collision I have low poly proxy meshes that are placed to make things easier to drive around the levels. Its not anywhere near as simple as the tunnel like collision in some racing games, but it does average along complex surfaces, smooth over jagged detail edges and sharp corners so that its harder to get caught up on scenery improving the speed and flow of gameplay. Often no one will care if your vehicle doesn't come within 6" of the wall if they even notice.

these collision polys are simple single sided affairs with no thickness placed where needed, as we dont need convex hulls we lose all the extra polys that would be needed to make these solid objects. on average in my levels I only need about 600 collision polys per 20,000 to 30,000 visible polys.

In more demanding levels this low poly collision can be split into chunks that make up the entire level, we currently have up to 40 chunks within a 2 mile area in a large detailed test level, as the player moves about the level triggers turns on and off collisions and dynamic lights. As were using static lightmaps only animated objects need to be lit dynamicaly. Our DX7 engine doesn't do stencil buffers or fancy shader effects, so we use similar range systems for our shadows, so shadow casters and recievers have ranges from lights and often project onto low poly collision, run pretty complex levels with crazy dynamic polygon shadows, without much trouble.

Another benefit of using a 3d app as a editor and modeler for levels, is that we also have full Xref support in our engine, so each xref object and scene in max automaticlay becomes a seperate geometry file that can be streamed in realtime off of the HD as needed.

Our exporter supports a lot of advanced max features. for instance every light in the level is exported as a node,with child nodes who's xyz value represents RGB. this means that a light animated in max keyframe editor can have a dynamic equivalent in the game. another child node can be used for ranges, and we suddenly have artists creating levels with animated light colour and ranges done in the max keyframe editor. we have spline sampling for our keyframe data to optimize the file size and use these little max features through out our games for animated ambient lights, fog, animated textures, cameras and FOV, animated brush FX, transparency. we also use them to set friction values for physics, colision types, and values. All sorts of things.

This takes a lot of menial work out of the coders hands, and lets the artists and level designers have full control of a game level/environment from directly within their favourite 3D app.

To get a quick look at a 30,000 poly level with 500 polys of collision you can check out this small work in progress video clip I created. this runs on a Pentium2 300 with a GF2 at 40 - 60 FPS with the glow and bloom turned off the vehicle has 1000 polys, and an early implementation of verlet physics that we developed. 3.8mb WMV please bare in mind that this is a very early buld of a level and doesn't reflect on the quality of my work lol.

#8 Http://s93153354.onlinehome.us/movieb.wmv for the movie, sorry about the long post, I'm going to be asking a couple of people whether something like this would be possible in TGE and perhaps working on it as a sideline project. Allthough not being very familiar with TGE I'm not sure how feasable it would be. It's possible that the engine is too deeply built around a BSP/CSG to make it a reasonable project to undertake.

#9 Torque's not predicated on a BSP/CSG system. It just happens the current interior code is designed around such a system. If you already have all that rendering code, it would be fairly straightforward to port it to Torque. Are you at all familiar with how Torque is set up internally?

(Your link, clickable: s93153354.onlinehome.us/movieb.wmv)

#10 So, DIF is better than BSP and 3ds? As for the faces, I believe you can hollow a box, ungroup it and remove some faces.


Edit: So all my work on this editor was in vain??/

#11 Nice work Adrian, you've come a long way on the level design since the last time you showed an ingame video. What's the thinking on all the overbright lights?

#12 Um, lol. Well Ant the coder found a per object glow effect and got a bit carried away with it, at the time I had no control of the effect as it was still hardcoded. Bit more subtle now though. basicaly as you accelerate the camera angle widens slightly, the vehicle accelerates forward a little and in this case the acceleration alse creates a less than subtle bloom effect.

were using the bloom a lot less as it interferes with the effectiveness of weapons systems and tageting players. Unfortunatley my athlon 1200 isn't that great at capturing video clips either and was forced to use an older version of fraps due to a lack of SSE support in my CPU.

#13 BSP splitting of faces is what's bad... I was able to remove the splitting in our QuakeII based engine while taking advantage of the surface clustering. Works friggin' great.

#14 As I understand it, BSP is done when you export from quark to dif anyway, isnt it?