Performance in observer mode

#1 This is concerning and (to me) inexplicable. Got any output from the profiler, to see where all the CPU cycles are going?

#2 I haven't looked at the scoping code, but is it possible that when you jump to the new camera position a whole bunch of objects are coming into scope?

#3 Im using VC++.NET. How do I turn on profiler? I know how with VC6...

Thx

CG


EDIT:

Ok I cant find anything in the IDE and I read a post that mentioned that there is no more embedded profiler. There is a decent free one(registration required) at:

www.compuware.com/media.asp?cid=3019X36

#4 I seem to have broken the profiler. It worked the first time I ran it but doesnt want to work now.

I thought I could add some more info for you guys: Im using the fxRenderObject class that Melv wrote for my object. Its essentially a basic box.

I put a breakpoint in rxRenderObject::unpackUpdate(). I put the object really far away from the spawnlocation. Then I loaded the mission. With the player it doesnt call unpackUpdate() until I get close to the object. If I restart the mission and load it up, then switch to observer mode.... I get a break at updatePacket().

This is the reason why I was asking about the raycasting. Hope that adds a little detail:

Heres a stack trace if anyone is interesed:

torqueDemo_DEBUG.exe!cgRenderObject::unpackUpdate(NetConnection * con=0x017aa840, BitStream * stream=0x00b6c210)  Line 778	C++
torqueDemo_DEBUG.exe!NetConnection::ghostReadPacket(BitStream * bstream=0x00b6c210)  Line 496 + 0x2d	C++
torqueDemo_DEBUG.exe!NetConnection::readPacket(BitStream * bstream=0x00b6c210)  Line 656	C++
torqueDemo_DEBUG.exe!GameConnection::readPacket(BitStream * bstream=0x00b6c210)  Line 793	C++
torqueDemo_DEBUG.exe!NetConnection::handlePacket(BitStream * bstream=0x00b6c210)  Line 520 + 0x11	C++
torqueDemo_DEBUG.exe!ConnectionProtocol::processRawPacket(BitStream * pstream=0x00b6c210)  Line 225 + 0x11	C++
torqueDemo_DEBUG.exe!NetConnection::processRawPacket(BitStream * bstream=0x00b6c210)  Line 493	C++
torqueDemo_DEBUG.exe!NetConnection::sendPacket(BitStream * stream=0x00b6c210)  Line 637 + 0x2b	C++
torqueDemo_DEBUG.exe!NetConnection::checkPacketSend(bool force=false)  Line 621 + 0x11	C++
torqueDemo_DEBUG.exe!NetInterface::processServer()  Line 413	C++
torqueDemo_DEBUG.exe!DemoGame::processTimeEvent(TimeEvent * event=0x0012fc14)  Line 662	C++
torqueDemo_DEBUG.exe!GameInterface::processEvent(Event * event=0x0012fc14)  Line 71 + 0x11	C++
torqueDemo_DEBUG.exe!GameInterface::postEvent(Event & event={...})  Line 153 + 0x11	C++
torqueDemo_DEBUG.exe!TimeManager::process()  Line 1225 + 0x17	C++
torqueDemo_DEBUG.exe!DemoGame::main(int argc=4, const char * * argv=0x01201740)  Line 481	C++
torqueDemo_DEBUG.exe!run(int argc=4, const char * * argv=0x01201740)  Line 1142 + 0x1a	C++
torqueDemo_DEBUG.exe!main(int argc=4, const char * * argv=0x01201740)  Line 1178 + 0xd	C++
torqueDemo_DEBUG.exe!mainCRTStartup()  Line 259 + 0x19	C
KERNEL32.DLL!7c4e87f5()

#5 He's not talking about the IDE profiler. TGE has a built in profiler. I forget it's location, but if you find it there is just a define you need to activate and then enter a few console commands and it will profile for you.

#6 Platform/profiler.h; there is a define to enable it. I think the Engine Reference also discusses this.

#7 Ok I got it worked out. Ill explain what I found... Im a newbie still so I may be wrong about it but anyways:

The problem was what I thought. The camera "sees" the entire map and all its objects and renders them onload.

In ShapeBase::onCameraScopeQuery()

if (mSceneManager == NULL) {
      // Scope everything...
      gServerContainer.findObjects(0xFFFFFFFF,scopeCallback,cr);
      return;
   }

The camera isnt added to the scene like the player is and mSceneManager == NULL. It then goes out and finds "All" the objects. This was my performance killer. I added the Camera to the scene and it seems to be using the zones like the player. Now I just have to workout dynamic unloading....

How to add to scene(code was already there!).

In: Camera.cc -> Camera::onAdd()

comment out:

if(isClientObject())
      gClientContainer.addObject(this);
   else
      gServerContainer.addObject(this);

and uncomment:

addToScene();

You should have this:

bool Camera::onAdd()
{
   if(!Parent::onAdd())
      return false;

   mObjBox.max = mObjScale;
   mObjBox.min = mObjScale;
   mObjBox.min.neg();
   resetWorldBox();

   addToScene();

   /*
   if(isClientObject())
      gClientContainer.addObject(this);
   else
      gServerContainer.addObject(this);
   */
     
   return true;
}

Now in
In: Camera.cc -> Camera::onRemove()

comment out:

if (getContainer())
       getContainer()->removeObject(this);

and uncomment:

removeFromScene();

Your method should look like:

void Camera::onRemove()
{
	removeFromScene();
	
	/*
	if (getContainer())
       getContainer()->removeObject(this);
   */

   Parent::onRemove();
}

Thanks for your help.

CG

#8 Old thread but I just ran into this same problem..

is there any reason that the camera was not originally added to the scene?
I'm wondering why those lines were there but commented out?

#9 I just checked tge 1.5 and this is still the same in there, with the camera not adding itself to the scene.

#10 Same problem in TGEA RC1.

#11 I'm getting ready to test with it added to the scene.

just looking at the code, I don't see any reason it shouldn't be added to the scene, but guessing there was _some_ reason it was there and then commented out :)

have you tried these changes Stefan?

#12 Maybe it wasn't added because the original coder was thinking that it didn't need to be rendered.

#13 Just did some testing in standalone and client server for themusiclounge, all seemed ok. Maybe a bit more lag now when I fly between zones but didn't notice any problems yet.

this would also happen for us anytime one of our players sat down, all of a sudden everything would come into scope for them when the orbit camera turned on.


I suppose the stock death camera in torque's fps sample has the same thing happen?

#14 I ran into one small problem after makign this change, we had depended on the player's clientside id being long lived, which it always was before, after this change it no longer was that caused some odd behavior for us, all we had to do to fix it was

%player.scopeToClient(%this)

after we created the new player object on the server, so it's always going to be in scope for the owning player.

thanks for this ancient info here chris :)

#15 I have not tried any changes to stock. Haven't got the time.

A question: Didn't this work OK back in 1.2.2?