Game Development Community

more than 1 GameTSCtrl - odd behavior

by David Massey · in Torque 3D Professional · 08/09/2011 (7:00 pm) · 5 replies

Trying to get a mini map working, and running into something odd..

If you open gui editor while in a mission, and drop a second GameTSCtrl onto the exisitng gui - it renders perfectly until you exit the gui editor... then it appears to have issues with zbuffer or something as it renders some of the underlying GameTSCtrl through the new one...

If you then open the gui editor - it renders pefectly as long as the gui editor is open!

I've tried tracking down what changes on the rendering when the gui editor is open, but have had no luck...

Anyone have any suggestions or ideas?

Thanks!

#1
08/10/2011 (11:04 am)
Maybe create GUIs for each GameTSCtrl, then call up the GUIs into your players GUI?
#2
08/10/2011 (11:14 am)
U can use a fxGuiSnooper mounted on the player with a hight z offset, and the right rotation.

My last comment is the perfect way for you. U don't require the postfx in a MiniMap.

HERE SOME INFO
#3
08/10/2011 (2:34 pm)
@S2P i actually tried that as well.. but same effect...

@Alfio Thanks for the snooper link - trying to get that to work, running into a snag with your comments there regarding the _renderScene function... the rednerScene(viewprot) called there isnt defined..
Poked around and see it defined as a virtual function doing nothing in EditCtrl... so.. commented it out.. and seems to be running fine...

Also trying to get a couple changes that I'm hitting some trouble on..
A) dont render players
B) dont render shadows...

Tried changing the renderScene to differnt masks, even just:
gClientSceneGraph->renderScene(SPT_Diffuse,TerrainObjectType );
but players still render ( although interiors dont...)

As for shadows.. no clue.. I'm *guessing* you can achieve that through the render instance? Any idea there?


as to postFx... dont think i need that... only render to texture for the final goal...
#4
08/10/2011 (11:12 pm)
For your issue with the player, you can solve it by editing the file SceneManager.cpp, around the line 360.

In fact, you can see that code was added, and this add always the player to the list of objects to be rendered.

//HACK: If the control object is a Player and it is not in the render list, force
   // it into it.  This really should be solved by collision bounds being separate from
   // object bounds; only because the Player class is using bounds not encompassing
   // the actual player object is it that we have this problem in the first place.
   // Note that we are forcing the player object into ALL passes here but such
   // is the power of proliferation of things done wrong.

   GameConnection* connection = GameConnection::getConnectionToServer();
   if( connection )
   {
      Player* player = dynamic_cast< Player* >( connection->getControlObject() );
      if( player )
      {
         mBatchQueryList.setSize( numRenderObjects );
         if( !mBatchQueryList.contains( player ) )
         {
            mBatchQueryList.push_back( player );
            numRenderObjects ++;
         }
      }
   }
Thus, commenting that code, the player should no longer be added to the list. I have not tried, so i could not tell if you can see strange effects. :P
#5
08/14/2011 (3:11 am)
Gotya - thanks for tracking that down....