Game Development Community

With the impending end of cpu speed increase, is there any plans for a threaded T3D?

by Kyrah Abattoir · in Torque 3D Professional · 07/08/2010 (4:11 am) · 37 replies

Aparently the engineers at intel are hitting some kind of wall in term of cpu speed increase around the 4ghz mark and it appears to be a physical issue, which is why we are seeing progressively more and more cpus with 4, 6 and probably more cores.

Seems the only way up now is through parallelism.

So are there any plans at GarageGames to swich T3D to a threaded system?
Page«First 1 2 Next»
#21
12/12/2010 (2:33 pm)
I am observing high CPU utilization, (one CPU in the two is maxed out and the other is low), and I am looking for insights as to the cause and for strategies to reduce the CPU load. (Engine: Torque 3D 2009 Pro 1.1 Beta 2, and my platform: Intel Core 2 Duo CPU).
#22
12/12/2010 (5:09 pm)
@Maria
All players (and thus Ai) render on the CPU (in fact I'm pretty sure that all animations go there) and I believe that anything else which won't fit on the GPU gets shoved to the CPU.
#23
12/13/2010 (4:38 pm)
@Maria:

With your game running (in release), open the console and type:
profilerEnable(1);
Press enter and let it run for a few seconds (preferably in the area where you have the high CPU usage). Then bring the console again, type the following and press enter:
profilerDumpToFile("profiler.txt");

You'll find a file callsed "profiler.txt" in the same folder where your .exe is located. Open it in wordpad (not notepad, due to line-break issues), and check which are the topmost items listed.

Usually collision is the #1 performance issue. This can be dealt with by not using visible meshes as collision (use separate, simpler collision meshes).

If you have many animated characters with lots of polygons (3000+), skinning might become an issue if you don't. You might also get performance issues if you use tons of bones (60+) in tons of characters (20+). Both cases can be fixed with proper usage of LODs: you can LOD both the joints and the models.
#24
12/18/2010 (4:41 pm)
@ Manoel, Thank you! I removed collision and animation, resulted in a small improvement. Also, did try the profiler (not sure how to act on this information…)


Ordered by non-sub total time -
%%NSTime %% Time Invoke # Name
0.351 -99.649 0 ROOT
99.518 1.900 6605 MainLoop
93.205 -0.912 6605 CanvasRenderControls
69.974 0.000 224 GameRenderWorld
69.972 0.004 224 SceneGraphRender
42.252 0.000 224 TraverseScene
42.252 0.001 224 RenderCurrentImages
41.603 -0.845 224 RenderPassManager_Render
35.260 6.385 224 RenderTranslucentMgr_render
#25
12/18/2010 (4:44 pm)
Why would the fps be faster in the editor, and slower in the executable? Is there extra stuff I can cut out and optimize in VB before I compile?
#26
12/18/2010 (5:37 pm)
That seems a little odd ...

I know this is real dumb, but you have checked that you're compiling a release and not debug build?

Also what's your GPU?

And do a full metrics
metrics("FPS GFX SHADOW SFX TERRAIN GROUNDCOVER FOREST NET");
#27
12/19/2010 (12:22 am)
Steve Thank you!!! No that was not real dumb, it was helpful as I had forgotten to switch from debug to release. The CPUs are now evenly distributing the load, and it is much faster. However, it becomes choppy when the PolyCount exceeds 2.5 million, and is almost painful when it hits 5 million and the DrawCalls exceed 15,000. It helped a bit more to set the camera speed to the lowest level speed, just to reduce the jumps.

The valleys have the most vegetation and water and are the worst parts, so if I could do something to optimize there?

(With Unreal I could embed Antiportals to block the processing of all shapes hidden from view... I placed them inside the hills and large rocks, which helped.)

(my GPU is NVIDIA Quadro FX 570M and yes I would love to upgrade, but... )
#28
12/19/2010 (12:27 am)
ps the movement is still smoother in the editor
#29
12/19/2010 (12:41 am)
2.5 to 5 million is kinda high ... (I think) Crysis kept it around/under 2 million.

optimize water = drop reflections and use a cubemap
reduce polys with either less stuff or reduce visibility range. Also LOD more and faster/sooner, use more imposters.

Alas T3D only has view fustrum culling.
#30
12/19/2010 (12:47 am)
What is the view distance and fog distance in your level set as ?
#31
12/19/2010 (11:14 pm)
15000 drawcalls? There must be something wrong with some of repeating models materials, that's A LOT of drawcalls.
#32
12/20/2010 (1:21 am)
whoa! I missed the drawcalls ... yeah ... they really should be no more than 2K. Are you not using instancing? And what Oscar said.
#33
12/20/2010 (1:27 pm)
For your difference between the editor side and the client side, it's good to know that in editor mode, what you see is the simulation on the server side, and not the client side.

So I think there is a bottleneck in the transmission of data from server to client (because what you see in editor is server side, you don't need any transmission of data to update the simulation).

Nicolas Buquet
www.buquet-net.com/cv/
#34
12/22/2010 (6:01 pm)
Thank you for all of your suggestions, it is now fast (wicked fast)!
#35
12/23/2010 (1:40 am)
Good to hear. Out of curiosity what exactly did you change?
#36
12/23/2010 (4:18 pm)
@Steve, I am very embarrassed to admit, but I have too much on my plate... I had forgotten (again) to switch from debug to release.

Most of the other suggestions had been implemented ab initio. I only changed the draw distance of the level from 2,000 to 500 and implemented fog at a height of 50. Running the release was the big change.

More to come soon, a demo video, an Alpha download and a paper with benchmarks...

Merry Christmas, Faith, Hope and Love and good wishes for the new year!!!
#37
12/23/2010 (4:57 pm)
Daft mistakes happen to me all the time, so I'm sure they happen to everyone else too.

Cool! Always good to see more blogs/videos of what people are doing.

:)
Page«First 1 2 Next»