Deadly Matter :: Update 2

#1

To do:

Main things still working on:
[ ] Story line to game design
[ ] Level design and gameplay
[ ] 3d assets and characters
[ ] Lots of endlessly on-going optimization

Main issues still working on:
[ ] Inventory issues (backpack)
[ ] Meshroad objects causing errors
[ ] Weapon animations (like the wrong GG shotgun loading anim)
[ ] FP Character incorrect skinning (weights) and animations
[ ] TP Characters making unnatural movements (slow motion, sliding etc.)

Still on the planning
[ ] Further development of the inventory system
[ ] Saving and loading games
[ ] Dialogue system

Anyway... still a long way to go!

#2 Great blog Nils. Love that website too! That is one super slick, kickass website, right there. Man, I'd kill for something like that.

#3 Great looking art! I also was thinking about batching draw calls, how are you going to handle it?

#4

You, sir, are my hero.
But seriously, this looks excellent, and great job with the site too. Kind of looks exactly like the shooter I've been waiting for since STALKER. Just wish I had time for them :P.

#5

Quote:@Dann: Man, I'd kill for something like that.

Haha, good to know the flight ticket will be more expensive then a website. Else I couldn't sleep at night ;-P

____________________________________________________________________

Quote:@Kory: I also was thinking about batching draw calls, how are you going to handle it?

I think there are several options:

1. Fall back to the old fashioned way of putting all the geometry in less files as possible. Developing almost whole (indoor) levels in a 3d application. But that is something I was trying to move away from in the first place :S


2. Explore the forest editor and try to know why a forest file with 10k items is showing less issues then 100 static objects. Are forest items rendered differently?


3. Find somebody who can code something like Unity's Draw Call Batching for Torque. The costs may be probably too high and will make me wander if I should port to Unity or UDK to avoid that...

In any way, modularity in level design is a new industry standard for a couple of years. Batching draw calls is needed for that to make it work more efficiently IMO. If T3D can't keep up with those developments then I'm afraid we have again more signs of decay :S

I'm going to do something crazy and try option 2 first!

#6 I like the website. Also i like the details at the models and mission you did. Great job!

#7 Love the zombie and nazi free sticker! XD

Drawcall batching ... in core/scripts/client/defaults.cs add

$pref::TS::maxInstancingVerts = "1000";//yorks this need to be added manually here

The default is actually just 200, most of my scenery models are low-poly so I use the setting 1000. Note this stock 200 is hardcoded and drops straight into user prefs.cs without being known elsewhere - hence my adding the line to defaults.cs.

Apparently using higher values can cause more lag than it saves on older technology. There's some cursory info on it in the forums but you'll need a divining rod to find it - it should be in a post/blog by Tom Spillman.

Remember to update or clean/reset your user prefs.cs file, then check to see if there's any great change in performance.

Also LODing forest objects to imposters really fast helps. In Airship Dragoon if you go on lower mesh settings my tree models only display when the camera is right under them - saves tonnes of fps on crap laptops. I also LOD out grass totally on lowest setting and have my low lighting setting disable shadows whilst retaining Advanced Lighting.

Apparently hainvg more than 6 (or was it 4?) terrain textures on a single terrain cell can cause a performance hit.

Nice models and textures by the way. :D

#8 @Daniel

Quote:Kind of looks exactly like the shooter I've been waiting for since STALKER.

But.... even STALKER has zombies ;)

___________________________

@Steve

U mean maxInstancingVerts == Draw call batching ?? :-O

You're right, the frame rate immediately increases significantly. But the lags are undoable. Player waiting 3s to move when mission is loaded is not good when using modern technology. But this is a good start :)

The "outdoor levels" are already optimised pretty well. Rendering a 4km2 nature reserve goes without much issues. A minimum of 30fps for an adventure game with all settings at maximum, is nothing to complain about. The forest file in the screenshots is 4.5MB... that's a lot of trees. It took me long time to come to that. One thing that could be improved though; changing the imposter to not always the last LOD. Not rendering imposters when smaller then 4 pixels for example, could improve large levels I think.

I'm only having issues with the "indoor levels" (the lab in the screenshots). It's build up with static meshes, far less the amount of items you see as forest in the "outdoor levels". Most meshes do have multiple LOD's (and imposters when possible).

Thanks Steve!

#9 Torque has most of the functionality that other engines also have, it is just that nobody so far used it much in real practice and because of that issues have not been fixed, the best settings have not been found and no unified workflow has been developed so far.

If you have complex indoor levels, you can consider using vis-areas, so only parts of the level will be rendered at a time, this will save a lot of performance. Many games use this, for example if you enter a dungeon in an open world roleplay game, they stop the outside world being rendered and load in the interiors, either through a door with loading time or a corridor, where at some point the stuff you no longer see stops from being rendered.
But I still try to find a good workflow for this, have not found a good solution for all so far.

#10

Quote:
Not rendering imposters when smaller then 4 pixels for example, could improve large levels I think.

Yeah, LODing out of imposters would be a good idea - it doesn't work in stock code (I tried it ages ago, causes all sort of weird artifacts).

Preloading has always been a bit of an issue with Torque, I believe that there is a limited system that shows the top LOD of all objects in the level to the camera before the player gets the camera (at least I think this was implemented ... not sure now I'm talking about it).

Also objects, animations, audio and particles lag on first use - even when set to preload (for audio anyway).

I think another system might be to load the level, create the client camera, KEEP THE LOADING SCREEN VISIBLE, and then rotate the camera 360 degrees to view the whole world from the start position and thus load everything visible into memory. There would still be a pause but the player wouldn't be able to see the world to notice the initial lag, they would just be viewing the load/start screen. (I did something similar in Airship Dragoon to get all the Ai to mount and load weapons before the player gets to view the world and control the characters).

#11 @Duion:

Quote:If you have complex indoor levels, you can consider using vis-areas, so only parts of the level will be rendered at a time, this will save a lot of performance

You mean zones & portals? Using those by default...


__________________________________

@Steve,

Ya, a 360 cam is a good idea! Sounds much better then showing a 3d object containing all textures during the mission loading, I thought of recently.

#12 Actually I have a 3D object with additional textures hiding under the terrains in Airship Dragoon ... didn't seem to help much on preloading particles and objects though, might have helped a bit for other things, it was hard to tell.

#13 And these kind of scenes have performance issues? I already made scenes with maybe a thousand static objects and there were no noticeable issues. The issue is maybe somewhere else.

#14 @Duion

Quote:And these kind of scenes have performance issues? I already made scenes with maybe a thousand static objects and there were no noticeable issues. The issue is maybe somewhere else.

3339 static shapes to be precise (in the pic you see mostly prefabs) The level is far from finished.
You'd say it shouldn't be an issue...

#15 Ok, that gets quite a lot. Is this just one scene or the whole mission file? Did you make sure the vis-areas keep the most from being rendered? I never build vis-areas but in theory they keep stuff from being rendered that is not in the vis-area you are in.

#16 I find out you get better performance, if you hold the number of objects in the scene as low as possible. So maybe it is better to make one larger model, as split up to 20 models and use it as prefap.

To solve the problem with initial delay, about loading models or particles, you can place the models/particles below the terrain, so they gets preloaded and you then don't get the delay, if the model/particle is used the first time.

#17 what about level of detail? I have quite a few building objects in my map, with 3-4 levels of detail, the same could be applied to larger objects in view, closer you are the better the detail.

Edit: forgot to add... the object that is way out of view just make it a simple shape that has really low poly count, so its still an object in viewing distance, instead of an imposter.

#18 What I wrote in the blog post is that it was an experiment with modular design. I am not an expert so it was trying out stuff and see where it goes. If you want to know more about modularity in level design you can google it or read in this doc (PDF epic games) for example.

My goal was to move away from the old school method of depending heavenly on the 3d application and use the capabilities of the editor at bit more. T3D's editor isn't perfect but it does the job pretty well if you get to know it. This picture maybe is an example what I have done exactly:
[ + ]

The 4 mount racks in this picture consist out of: 10 static shapes, 1 diff map, 1 normal map, 1 spec map, 1 glow map and 2 sequence maps (DDS DXT1 where possible). By putting together a variety of prefabs (in the pic you see 4 different mount racks and single servers on a pallet) you see a great variety trough out the whole game. I can be different all time because you're not bound to a single mesh. This technique is used in lots of AAA games in the last couple of years.

But one thing I probable didn't think through is that the geometry can have too less polygons and end up as draw calls being totally inefficient. I'm not an expert but I read about a threshold for GPU's. Also seems instancing (PDF NVIDIA) important to reduce the draw calls. Sure, you notice that I'm a designer, so I won't go into deep with this. I don't know all about T3D yet, because it's simply a lot of knowledge! That's why an experiment and that's why I learned again from it.

I'm not worried about the level as most objects are placed as prefabs. The good thing about prefabs is that you can change the content at any time. So if T3D and the GPU's can't handle the draw calls I'll bring down the amount of objects in those prefabs until having just one single mesh.

Shapes are designed with LOD's by default, of course depending on the amount of polys.

Thanks for the tips guys!
Great community still going strong!

#19 Saw your scene shots. I'm worried. While this is a great design. Very beautiful. However, a model of the scene there are too many bodies, so that the production does not very well. Will increase the calculation. Some small model best to lose a single file into a DAE. So not only can enhance the computing speed. Also can save a large amount of computing resources.

#20 Completed a battlefield. Then I can save the following parts from a large number of resources:
A: A scene action and non- action area regional model polygon control .
B: A scene action and non- action area regional material management control.
C: large and small particle effects particle effects as much as possible to share materials or uniform material .
D: control illumination parameters. Preferably less than 80M instant projection only has to be divided into three or four over .
E: conditions permit the best use LIGHTINGMAP to show scenes of light and shadow .
F: The scene is a battlefield fighting a battle point cut processing .
G: in the right position to do little tricks to join the Trigger stage , such as the memory can be completely removed from the budget for some scenes or start a scene . ( COD or Battlefield 3 for example, we often jump from high places , of course . you can not go back and blanket . basically , these places will certainly put a Trigger will sometimes tell you to save node )
H: Set in a suitable place to set Occluder to mitigate graphics load.
I: flexible use of PHYSX ZONE ZONE and to control the battlefield calculation and rendering.
J: points of light within the scene projection calculation not possible unless heighten the atmosphere story .
K: Particle one but after the show kicked off from the scene on the very spot .
L: Leave at least need to calculate the scene used in a variety of dynamic objects parent . Logic to facilitate reproduction or cloning calls.
M: battlefield all occurrences of the best weapons are weapons by one parent to adjust some parameters copy or clone from. ( Remembered << Battlefield 3 >> , you do not pay attention to those on distant battlefields completely invisible maternal role in those places weapons and vehicles haha. )
N: In order to reduce as much as possible to optimize the calculation of AI waypoint with NAV MESH settings. ( Battlefield 2 >> << remembered only waypoints and AI actionable locale restrictions )
O: engine conditions permit directly from the NAV MESH best to control the player with the best area of ​​operations of AI can also be directly replaced the original scene of the collision model .
P: the best generated directly from the NAV MESH small map ( you can refer to the dark descent 2 >> << practice ) .
Q: Do not necessary to completely run out of the scene . Stage settings need to be considered .
R: a battlefield not more than five standard objects .
S: greater use of the story , let the memory vented.
T: Let your enemies on a person dies before birth . Taking into account the battlefield Yudi sex . Enemy always appears in a position relatively close from the protagonist or waypoint .
U: the enemy 's body basically to quickly clear ---- ah , the future and I can not say too much -----
V: Finally able to say one , when your engine or your FPS do not use NAV MESH collision, try to ignore fall below a certain unit of the collision. --- And all of this is sometimes the engine functions , while more time TA is re- structured