Game Development Community

Cheetah bogs down the game to a halt/near halt.

by K. Silver · in Torque 3D Professional · 07/22/2013 (6:42 am) · 27 replies

Not certain where to find the answer to this issue. I have experienced an issue of the game slowing down progressively to a halt or near halt after climbing into the the cheetah. This happens only when I am in a level I have created, but not in the ready-made levels: 'Empty Terrain' (desert) and empty room. I am running the Torque-3D MIT open source version. Obviously, I am missing something obvious. Care to enlighten me?

Another note: I just noticed that I had the identical problem when dropping some rolling boulders into my game level. So, next, I tried adding them to the pre-made desert level and had no issues (except that they slid, not rolled) down the sand dunes. So, it may be that ANY animation may be the problem.... Something I will have to check. Gives me another cross-referencing option, now.

Well, if anyone knows where to send me looking, please do so.
Page «Previous 1 2
#1
07/22/2013 (7:14 am)
K,

Really sounds like a problem with calculating ridgidShape collisions. I know it's possible for that particular physics thing to slow a machine down in really dense areas. I could determine more if I knew your system specs.

Ron
#2
07/22/2013 (8:29 am)
Are you using PhysX, Bullet or Torque collisions?

(You choose which one to include when you build your project in the project manager)

In my experience, everything runs perfectly with PhysX, 50/50 with Bullet and maddeningly randomly with T3D's built-in physics.
#3
07/22/2013 (8:50 am)
@ Simon: Torque Physics..... Hmmm.... Is there an easy way to switch my project over to Phys X Physics or do I need to rebuild my level from scratch, effectively?

@Ron: Remember, the physics works with the included module level, but not the one I created in the same project. Same system. Before we head down what may be potentially be the wrong path, let me see what Simon suggests as his thoughts seem to accurately indicate where I created my problem. My system: AMD E-300APU; ; Radeon HD Graphics; 1.30 GHz; 4GB RAM; 64-Bit OS;

Thank you both for such a quick reply.

On a side note, my rivers have a visual thickness of, well, just a surface. When close up, the river image disappears completely (for the closeup segment) although the 'water' still exists and interacts with the character (splashing, swimming, etc). Also, submerged fx still operate correctly. I am hoping that switching to Phys X Physics will clear up all these ailments; kind of a clearasil for Torque 3D!!!

~K

And, hey.... glad to be back after all these years.


EDIT: Starting a new project with the Phys X Physics to cross-reference working vs. non-working animations with only Phys X Physics vs Torque Physics as the difference. I will return with the results.

RESULTS: I tried to reproduce the problem on two different projects: the existing one with the errors using Torque X and the new one using Phys X. Okay, I was able reproduce the errors in new levels of the Torque X project and moreso if it possessed other than a flat terrain. However, even on a flat terrain the FPS degraded quickly enough. On the Phys X project, I could not reproduce the results at all in or out of terrain imbedded new levels.

THEREFORE SIMON (OR ANYONE), my question remains: Is there an easy way to switch out the Torque Physics and replace it with the Phys X Physics?
#4
07/22/2013 (2:07 pm)
The Cheetah is a piece of crap. It does bog down systems. It is ugly, it handles poorly and it has massive collision related issues designed into it. It's probably my biggest peeve with Torque. *end of rant
#5
07/23/2013 (10:52 am)
Thank you for the heads up, Dan! Glad to know it wasn't just me. :)

~K
#6
07/23/2013 (11:12 am)
Say, Simon, I just regenerated my project with Phys X Physics. Will that remove the Torque Physics package completely from my project and replace it with the Phys X Physics package or will I have residual Torque Physics Package code in my project?
#7
07/23/2013 (12:32 pm)
Just wanted to clear something up... I said it was my biggest peeve with Torque, but this isn't entirely true. Torque need not have anything to do with the content made for it. My issue is with the Cheetah as a third party asset, not the engine itself. Torque does what it says it does quite well. I can easily not drop that particular vehicle into my levels, which is exactly what I do.

Unfortunately there aren't a lot of options available to me unless I purchase a vehicle pack or commission someone to make a vehicle that I don't bitch and moan about, but the truth is that I don't need a vehicle in my game (and I'm tight!).

@K - just in case you're in a hurry and Simon doesn't answer you as quickly as you might like, I believe that PhysX will be implemented instead of any other physics system, leaving no trace of those others (Torque and bullet) in your build. The only reason I haven't ever done that myself is because a) I can't figure PhysX out, and b) I'm a n00b.
#8
07/23/2013 (12:39 pm)
! I'm in demand! hahahah Sorry K, I've only dabbled with Torque 3d, by no means an expert.

Edit : see Michael Hall's response.

As of right now, (make that as of last I fiddled around with T3D, 4 months ago) you need to download the PhysX SDK 2.8.4.6 and add the Path to you environment variables :

TORQUE_PHYSX_PATH E:devPhysX_SDK2846
#9
07/23/2013 (12:43 pm)
Quote:
... will I have residual Torque Physics Package code in my project?
Torque's built-in rigid physics coexists side by side with either of the supported 3rd party physics solutions.
#10
07/23/2013 (12:46 pm)
Also, a FYI: none of the vehicle classes (at this time) actually make use of either of the "improved" physics systems.
#11
07/23/2013 (1:06 pm)
@Michael : My bad on the coexisting physics, then.

As for the vehicles, a few months back, I had reintegrated the hover vehicles and it was practically impossible without compiling physX. I know the vehicle handling is not bound to any specific physics implementation but collision shapes are handled by physx, right? Vehicles falling through the terrain was my main issue.
#12
07/23/2013 (1:54 pm)
Hehehe! My wife and I had a blast digging our way through the terrain and falling through with the cheetahs. Now, we're designing hovercraft and other fun stuff. We don't need them yet in our current project, but we have aspirations of using them in future segments of this project. By then, I will have had to dig in deep (pun intended) to find out why the cheetahs fail. Until then, I'll play with it from time to time.

On a side note, any idea why my river surface keeps disappearing-in segments-when I get close to it with camera or character?
#13
07/23/2013 (3:56 pm)
K,

It's a known occlusion error. I have been dealing with the river issues forever. Once we got the fix for 'far off rivers vanish', then we ended up with the less intrusive 'rivers disappear' at certain camera angles when too close.

It will get fixed eventually.

Ron
#14
07/23/2013 (4:37 pm)
Hmmm.... Any work-around until then that you (or anyone else) knows of?
#15
07/23/2013 (5:22 pm)
Maybe the river surface issue is tied to the reflections? I haven't had the problem at all, but I set reflections to strength=0.25 and size to 1024. I also set emission to true. Worth looking into if for no other reason than to check those off the list.
#16
07/23/2013 (5:25 pm)
I will check on that right now, Dan.

Okay, I am game..... Where do I find those variables for modification? I have looked under the 'Reflect' tab of the river...... not there. Ya got me stumped.
#17
07/23/2013 (7:11 pm)
Hmmm... weird.

imageshack.com/a/img29/249/xxff.jpg
#18
07/23/2013 (7:58 pm)
yep... that is one of the errors. I am working it. Unfortunately, I can't tell you an approximate date for a fix.... It is on my list though, along with many others.

Actually Dan, Reflections are calculated POST object creation, so it's not that. It has to do with rivers being out of 'visual' range or 'under' visibility range as determined by view distance. Basically, T3D can not determine (under certain conditions) if the river object should be rendered or not based on distance from viewer.

Ron
#19
07/23/2013 (8:04 pm)
Oh yeah... As for your vehicle error... No offense but, the min specs for STOCK Commercial T3D 1.2:

OS: Windows XP SP3/Vista/Windows 7
Processor: 1.7 GHz Processor or better
Memory: WinXP - 1GB RAM/WinVista, Win7 – 2GB RAM
Graphics: Graphics: DirectX 9.0c Shader 3.0 supported, Nvidia 6800 or 7300 or better, ATI Radeon X1300 or better
DirectX®: 9.0c
Hard Drive: 4 Gb free disk space

Your 1.3 gig processor seems a tad low end so expect problems with collision since the processor needs to calculate those on top of the graphic requirements.

Ron
#20
07/24/2013 (7:29 pm)
I switched my main production over from my laptop to my desktop which has:

OS: Windows 7... 64bit
Processor: 1.65 GHz Processor or better
Memory: 4GB RAM
Graphics: Graphics: DirectX 11, AMD Radeon HD 6300
Hard Drive: 799 Gb free disk space

I brought in the cheetah and it pretty much froze me solid, though not quite. I did have to quit out to recover use of the game project, however. I might try some boulders later to see what happens. If they're a problem, guess I'll buy a new processor and video card. Eventually, I'll have the problem licked!

Though.... I am a bit confused.... Why do the cheetahs work in the stock project level but not in a user made project level?
Page «Previous 1 2