Rendering 2 different scenes from the same SceneGraph
by Chris Groot · in Torque 3D Professional · 05/12/2011 (9:07 am) · 6 replies
This may be hard for me to explain but I will try my best to explain it. I would like the ability to render two different "scenes" using the same scenegraph. To make this more clear an example of what I wish to accomplish may make it easier. Picture a split screen game on the left I would like to render a character editor of sorts, where the camera revolves around the character model and allows me to change clothes, weapons, etc. and on the right I would like to render the character within the actual 3d environment and be able to control/move the character. I have experimented a little bit with the clientSceneGraph rendering and I have been unsuccessful at getting my desired result to work. Would anyone know a good place to split the renders? I thought maybe within the GameTSCtrl renderWorld function, branch the two different renders? The reason I want to branch the renders is I would like the ability to render one or the other or both at the same time. One other thing is once I figure out where to split the renders, I'm not sure what I have to call within the scenegraph to make it work properly? I imagine I could clear the scenestate, prep render images for whatever I want to render within this render call and then actually render it.
Any ideas are welcome, I'm pretty much still trying to design a good structure before jumping in too much more.
Any ideas are welcome, I'm pretty much still trying to design a good structure before jumping in too much more.
#2
Would the character editor be required to run server-side? If not, I'd recommend starting with GuiObjectView and going from there with a completely client-side solution. When you need to signal things back to the server (like when the user has changed the weapon on the model), you can send messages.
The problem comes when you want to render more than a couple of TSShapeInstances in your Gui and rather want to have a full scene. At that point, the forced "one scene only" nature of Torque's scene management becomes a problem.
I've never actually tried it, but I think that on 1.1 final, it should actually be pretty simple to have a separate scene--most easily a separate networked one. There's very few places in the code that would need to be adapted to do that (like, for example, getting SceneObject::addToScene()) to add the object to the correct scene.
If you put it all into the same scene, I would recommend building the two scenes in two separate places within the same world. If they are more than the far rendering distance away from each other, you could even just render through two different cameras with no need to hide anything. However, that could run into floating-point precision problems when the coordinates get pretty big.
If you want to really have the same scene render in two different ways, the key would be directing the culling (to filter out the objects you really want) as well potentially the rendering of individual objects. This can be done via SceneObject flags and/or SceneObjectTypes.
05/12/2011 (10:00 am)
From your description, it doesn't sound like you actually would be rendering the same scene and maybe more that you are running up against Torque's built-in "there is only one scene at any one time" decision.Would the character editor be required to run server-side? If not, I'd recommend starting with GuiObjectView and going from there with a completely client-side solution. When you need to signal things back to the server (like when the user has changed the weapon on the model), you can send messages.
The problem comes when you want to render more than a couple of TSShapeInstances in your Gui and rather want to have a full scene. At that point, the forced "one scene only" nature of Torque's scene management becomes a problem.
I've never actually tried it, but I think that on 1.1 final, it should actually be pretty simple to have a separate scene--most easily a separate networked one. There's very few places in the code that would need to be adapted to do that (like, for example, getting SceneObject::addToScene()) to add the object to the correct scene.
If you put it all into the same scene, I would recommend building the two scenes in two separate places within the same world. If they are more than the far rendering distance away from each other, you could even just render through two different cameras with no need to hide anything. However, that could run into floating-point precision problems when the coordinates get pretty big.
If you want to really have the same scene render in two different ways, the key would be directing the culling (to filter out the objects you really want) as well potentially the rendering of individual objects. This can be done via SceneObject flags and/or SceneObjectTypes.
#3
05/12/2011 (10:10 am)
Thank you for the responses! This gives me lots of ideas and things to try. I'm most interested in the last thing you mention Rene. That sounds like a viable solution to me, I am going to try to look into the SceneObject flags and cull the unwanted stuff for the character editor and render only the character and see how that pans out.
#4
Thanks for the help and the suggestions always appreciated!
05/16/2011 (3:39 pm)
Just to give you guys an update I got the multiple rendering to work. I currently can render my character editor rotating about the character, I can also subsequently render the character in-scene moving and whatnot. I accomplished it by using SceneObject flags like Rene suggested and then combining that with swapping camera modes for each render so I could rotate about the character in the editor apart from the rotation of the character in the scene. Thanks for the help and the suggestions always appreciated!
#5
Waiting for a Resource from you ;)
05/17/2011 (7:49 am)
>I currently can render my character editor rotating about the character, I can also subsequently render the character in-scene moving and whatnot.Waiting for a Resource from you ;)
#6
05/17/2011 (8:06 am)
Umm...it's currently pretty well enmeshed within my project, but I'll see if I can separate out the necessary components and get that up in the resources :) 
Associate Chris Haigler
Jester Dance