How to: Avatar display in RTS UI

[KungFooMasta]

I'm trying to achieve the affect in starcraft/warcraft III that shows a model representing the unit in the UI. I know this is a RenderToTexture from a camera pointing at a particular mesh, my question is, do people just position the mesh in some far away location so its not visible in the scene?

Is there a way I can render an object such that only 1 camera can see it? Are there better methods to achieving this?

[KungFooMasta]

I think MovableObject::setVisibilityFlags and Viewport::setVisibilityMask will give me what I want. Still, if anybody has any ideas or comments they are welcome.

[madmarx]

1/ Don't put everything in the same scene! It makes it harder for the scenemanager to organise your content. I would create a dedicated scenemanager. I have done it many times for dedicated rtt with ogre 1.4.
This is the easy way to code. But rendertottexture is expensive in term of power.

2/ I think you don't need at all a render to texture that is expensive.
I'd rather draw in stencil buffer the inventory (put inventory at 1 and just let the window for the unit at 0), and then add the drawing of my unit (using stencil test).

It must also be possible to first draw the unit, and then the inventory (with depth check at 0), and in the end the rest of the scene.

In both case, you just need to be careful not that your unit Z-write mess up the Z buffer of the scene (or just call clear Zbuffer!). You can also just create a viewport on top of your scene to draw it, but I think it's more cost than the stencil (that has been widely use for that precise purpose).

To select the order of rendering, you can have a look at renderqueuelistener or renderqueuegroup (or even at renderqueueinvocation).

[_tommo_]

I thought ogre had a classd to show an entity in the GUI, without any render to texture.

Anyway, i suggest you to forgot about the render to texture, because you can place an entity before everything and relative to the screen using a custom material:
-use depth_write always
-in the shader transform using only view matrix

This way an ordinary unit is always drawn, and it's world position is not taken into account... note however that the second point could need much tweaking to move/zoom the mesh around.

I think that for 3/4 entities this approach is faster and simpler than a separate scene manager, wich is useful when you actually have a second scene going on.

[madmarx]

Well I also think a second viewport (for the whole inventory) would save you power :
-> less entities send to the calculation (because frustum is littler).
->less transform calculated for the big scene, because it is littler (of ccourse create a littler viewport in that case)
-> less fill rate for your viewports effects

It makes a real + for perfs if the application is GPU bound.

note: if you do a RTS, you can begin with RTT everywhere, and after checking that your pathfinding algorithms are running smoothly in realtime, you can go back to the optimisation of the GPU part.

[KungFooMasta]

Are there any links or wiki snippets that give a decent intro to working with the stencil buffer?

It makes it harder for the scenemanager to organise your content.

madmarx, how many models did you have in your scene? I figure I would have to have 1 mesh per avatar, so it would probably be around 10 to 15 models. Is that really enough to have a significant impact on the scene's organization?

I think for first pass I'll use RTT, and then after I get it working, I'll try out the methods suggested here.

[madmarx]

>>It makes it harder for the scenemanager to organise your content.

The number of meshes in not important. It's the number of Entities in the whole level that is a problem. If you have 5000 Entities with 2 meshes, the scenemanager have to check which to send to the GPU. To do that each scenemanager uses it's own management (ex : an Octree / a portal based graph / ...). If it is a balanced tree for example, when you add an entity very far, the scenemanager will look for the more appropriate of its graphnodes to add the content, and detach attach/some other branch to make the whole graph more performant.

Creating another scenemanager is really easy with ogre ^^.
from my code :

Code: Select all

mFSQSceneMgr = Ogre::Root::getSingleton().createSceneManager(Ogre::ST_GENERIC,"FSQS_SceneManager");
mFSQdefaultCamera = mFSQSceneMgr->createCamera("!_FSQ_Camera_!");

But If you have 15 entities in your scene, you can wihtout a doubt put everything in the same scene. But I would'nt do that, because 'it pollutes space' : for example, if your magicien_unit has lights it can have some consequences, or if some nodes share the same names, etc...


In the end, I think the best would be to use 2 viewports : 1 for the up part of the screen, and another for the down part. Then draw your man, and then draw the 'inventory' (set a later render queue for inventory).

For stencil, I know how to use it in pure opengl, but it seems a little harder with Ogre : it's in Compositor scripts, and I have not used them yet.

Have a nice day!!

[Noman]

I'm not convinced that RTT + separate scene is not the best solution. Why does everyone think that its so power-heavy? The texture doesn't have to be big (128x128 or 256x256 will do), and the amount of overdraw for drawing the quad on the screen isn't that big either. Yea the quad is an extra batch, but 1 batch isn't that much.

[madmarx]

@noman
Why do I think that?
logic + experience.

I did not take the quad drawing into account, because it has no impact (or veryvery little).

I think it will give worst performances because :
- it needs to draw more pixels (more fill-bound) (it means that if KungFuMasta wants to use compositors later, it will cost him more than without the first RTT).
- need to change the rendertarget
- need more texture memory

Now, early optimisation is not necessary, and RTT can be used if it's easier to program.