Couple of questions regarding performance

#1 As far as I know, culling is performed per-object, so breaking your level up into smaller objects allows you to use Zones/Portals and occluder objects to optimise rendering. Your character AI shouldn't be too costly, but you should ensure that your character models themselves have several aggressive LOD stages. Oh, and make sure you apply this patch or something similar, which has caused performance issues with lots of AI characters in the past.

#2 If your game views are mostly/sorta top-down and your levels are mostly staying on the horizontals, the culling done by Torque out of the box (based on 2D grid subdivision) should be good enough. The hassles of portals or occluders should be avoidable as long as you don't have a lot of depth complexity in your level. And even if your viewing angle gets nearer to parallel to the terrain, setting up proper LODs and distance limits should help performance much more than Z&Ps -- which pretty much only make sense for indoor stuff anyway.

For breaking stuff up, try to find a reasonable balance between culling and batching performance. More objects means more fine-grained culling but it also means more time spent culling, more objects in the system, and, most importantly, more batches of geometry processed and sent to the card (Torque doesn't have a system to re-batch geometry on its own) which can quickly nullify any gains culling got you in the first place.

Quote:How can I restrict the camera to the mission area, so that it cannot leave the mission area?

Take a look at the script callbacks for the MissionArea class in the script docs. These get called for control objects that leave the area and allow you to plug custom logic in there (slapping the player around, etc).

Quote:Can someone please explain the difference between Basic and advanced lighting? I understand advanced is a deferred renderer and allows unlimited lights. What are the pro's and con's of the two?

AL renders to intermediate buffers and then basically mixes the final result out of the buffered information. BL basically straight to the (sorta) final buffers.

Biggest feature difference here in Torque is shadows. Out of the box, BL comes with projected shadows only which can become expensive. For stylized visuals they, or better yet just blob shadows (think an implementation of them is still floating around in the sources), can be just fine.

AL does "proper" shadowing using shadow maps. These are rendered in their own passes and need to be updated based on changes in the scene. Can get quite expensive too (especially for point lights) but can give you reasonably nice soft shadows. Non-shadow casting lights are pretty cheap in AL (the "unlimited lights" thing).

#3 Also one to watch are textures, the more textures you have the more texture memory is used, the more object that use different textures, the more loading of textures and unloading etc. etc.

For best performance I believe you need to convert your textures to .dds format.

Also if you have your art person combine as many of your commonly used textures into single texture sheet that will hopefully save you some processing time, note don't go overboard and make several massive textures as loading a huge texture just to use one texture off the sheet is worse than loading several smaller textures.

#4 Thanks for the help and explanations guys! So I think I go with advanced lighting.
One more question: As my game view is top-down (slightly isometric), and the camera distance is more or less fixed, does it make sense at all to use lods for the buildings/props/characters?

#5

Quote:One more question: As my game view is top-down (slightly isometric), and the camera distance is more or less fixed, does it make sense at all to use lods for the buildings/props/characters?

I'd say no. If you render a model from roughly the same distance and even the same elevation all the time, it makes no sense optimizing for different renders that never happen. In fact, the additional data and processing of it will make up for needless overhead.

If the camera allows zooming, things already look different I guess.

#6 Hello Rene ...

... and just to disagree with him ...

... yes, you should LOD those models as well due to people using smaller screen sizes than what you would expect or lowering their quality settings to gain better frame-rate on lower spec computers. It helps to always consider people who may be using machines which are the lowest spec the software will run on.

#7 Which also means providing low resolution textures. T3D will run on lower spec machines than we usually think, but the current stock art has poor/large textures that artificially inflate the requirements. For instance, you really need 1GB of video memory to properly run the Pacific Demo or else textures go missing and framerates are terrible. Discovered this a while back when a friend with a 512MB ATI card had these problems - upgraded to a 1GB ATI card (did not even update drivers) and the issues disappeared.

#8 Thanks rene. I'll have to Experiment, maybe I will allow a Little zoom in/out.
Regarding AI:
For pathfinding I have already implemented walkabout, which works very nice. I plan to have different behaviours for my AIs, like normal pedestrians that run away when there is danger Close, enemys that patrol, guard and attack Targets. Besides that a few cars that run around and avoid overrunning pedestrians. I plan to use UAISK for my AI. I guess the pathfinding part is the most ressource intensive part for my AI, and with walkabout it's taken care of in C++ und should be fast. Still, how many AIs is a realistic number to run around in a Level? Are there any better Solutions than UAISK...like Guidebot?

#9 Steve has a great point about different screen sizes.