GUI/HUD as DTS model instead of bitmaps?

#1 I don't believe that has been done yet, but sounds interesting.

#2 I don't think this has been done before. I can see one thing wrong with it... the objects mounted to the camera would be visible to everyone else which may look rather odd.

#3 You've got a point OneST8, but he could use a couple of strategically placed GuiObjectViews in the playGUI and put the objects in there.

#4 @oneST8 - thanks I didn't even think of that. Perhaps the server code would need to be modified to not send the gui objects to other clients.

@dreamer - I'll check out GuiObjectView too. Do you know if can it be a transparent overlay on the main canvas? Otherwise not too useful for HUD type interface.

#5 Probably need a new control for this as you don't want mouse events being interpretted by the control just an update on it. I looked at something similar to this for a mech combat game. You can modify the GuiObjectView control as this renders a dts in whatever environment you want.

#6 First of all you really don't want to mount any GUI to the camera/player! There is absolutely no reason why a gui would be server side. Your gui needs to be client side. GuiObjectView would indeed be a good starting point.
But why do you need a dts model? Render it out to a bitmap, and use the bitmap, it'll look better and it'll still have that 3D feel. Unless you want to have moving parts, but then you can use a sequence of bitmaps to fake the effect.

#7 Actually, in some instances, dts would work better than bitmap or sequences of bitmap. Extensive motions, or perhaps he wants lighting in game affect the gui too. or, say, add some physics bits, like, when player jumps or turns sharply, gui has slight inertia etc.

#8 A better way to acheive this would be to render the GUI to a texture with transparency and then paste that over the 3D camera view.

#9 Thanks for the suggestions everyone.

I believe there would be advantages to using dts objects for a GUI instead of bitmaps, such as shape animation, texture animation, lighting, and so forth.

#10 I've been doing this in another engine for ages. What we did was to render a seperate camera with the HUD elements on, and render the game seperately and composite the two ar runtime. YOu can do much the same thing with lighting if you have baked lighting. Have your animated objects and player cameras totaly seperate to the level with 100's of lights and falloff ranges and combine the scenery, HUD and animated objects at the end.

This produced a significant performance increase for us.

Simple way to do this 3d hudf thing in torque might be to modify the GUI editor to allow you to position 3d objects instead of bitmaps on the screen, and allow the artist to create animation for various actions they want in their 3d app. I might discuss the possibility of doing some of these things in my current project.

If you want a simple example of a 3D gui done in the way you suggest, check out Market value. the entire game was set up in 3dsmax in a WYSIWYG fashion. It's fairly simple in the use of 3d but still gets the point of this discussion across.

all the items were positioned and animated in 3dsmax, and simple functions for rollovers and clicks created to activate the animations.

the entire game only uses a about 3 textures and relies on lighting, environment maps and blendmodes to shade the objects.



you can see it all animated if you try the demo at:

www.leadfootproductions.com/MV.htm

It's possible and I'm hoping the art pipeline for torque we are working on will enable you to be able to work in the exact same way that Market value did it, since it uses the same 3dsmax exporter as market vallue. It allows you to attach HUD objects to a camera in max lock its position and or rotation to the camera and export the HUD elements with a draw order the artist can set via a custom render modifier in 3dsmax. which would be interpreted in torque via torque extensions.

#11 Thanks Adrian! Sounds like it worked out well in that game.

To get this pipeline working with torque, you would have to modify the Camera class so you can mount stuff to it, and also figure out how to get the client to render it but not be seen by the other players.

The GUIObjectView seems like maybe a better starting point to me. Main challenges would be to make it transparent (maybe it inherits that from GuiControl class? And also to pass through UI events down to the Torque engine if the user mouses on a transparent region on the guiobjectview.

But wait, if you can composite two cameras and overlay the hud on the gameviewport then many of the problems go away right?

Challenging no matter how you cut it, especially for a noob like me.

#12 This has already been done:
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6504

Try doing a little research before posting such definite answers.

#13 @J.Alan - thanks a bunch! Sorry for not spying that Resource before starting this thread.

#14 I have functioning Render-to-Texture in TSE -- IE, you can render the HUD, then map it to an object. I plan on using it for 3d cockpits.

#15 I was confused when a few people posted "I don't believe that has been done yet, but sounds interesting."

The first thing I thought of was "Air Ace". They have a fully 3d cockpit with textures rendered to the surfaces.

#16 @Ed I've never played Air Ace, but it sounds pre-rendered to bitmap for the gui. What we are talking about is not pre-rending but using real live .dts objects AS the GUI itself, so using the game engine to create a nicer GUI than can be done with the Torque .gui toolkit

#17 We havent done this in Air Ace, the cockpit is just a client side only visible part of the plane mesh.

However, we did this exact thing in Worms 3D a few years back and it worked fine.

Personally, I like the technique of having max do all the UI animations and stuff, as Adrian described.

In W3D, we did it all in maya. Basically had dummy locators which we could attach elements to, setup maya so that it had the same FOV as the scene and the aspect ratio was set to 640x480 to match our target res. Then the interface was simply animated by animating each dummy node with specific named animations (in, out, active, inactive) etc. We could do things like spinny whizzy bouncy stretchy buttons that whizz in and out when clicked etc! very easily.

Its also relatively easy to do in Torque. Simply need to get the transform for a named dummy and attach a specific control to it.. so say you have a max scene with dummy_button1 in it, you would parse the dts looking for the dummies, find which control they refer to (using some naming scheme) and then when animating the interface, you would for each update, get the transform of the dummy and set that as the transform of the control.

Easy!

#18 Thats exactly how we plan to do our torque extensions, since the exporter already supports animated nodes: Hopefully it won't be too hard :) Were still working om materials and collision at the moment. Here's how lights work when nodes are translated to the engine.

-----------------------------------------
LIGHTS:

The Max light is exported as a pivot that retains the name, position and rotation of the original Max light.

The pivot has a child node that identifies the light type and exports the light's color:

Node: B3DEXT_OMNILIGHT
Pos XYZ = RGB
Node: B3DEXT_DIRLIGHT
Pos XYZ = RGB
Node: B3DEXT_SPOTLIGHT
Pos XYZ = RGB


These nodes in turn use a child node to represent the light's range:

Node: B3DEXT_RANGE
Pos X = Light Range


A spotlight uses another child node to represent light cone angles:

Node: B3DEXT_FOV
Pos X = Inner Angle
Pos Z = Outer Angle

---------------------------------------------------
AMBIENT LIGHT:

Node: B3DEXT_AMBIENT

Pos X = Red (0-1)
Pos Y = Green (0-1)
Pos Z = Blue (0-1)



-----------------------------------------------
FOG:

Node: Scene Root
Node: B3DEXT_FOGCOLOR

Pos X = Red (0-1)
Pos Y = Green (0-1)
Pos Z = Blue (0-1)
Node: B3DEXT_FOGRANGE
Pos X = Near
Pos Z = Far

--------------------------

With a bit of luck these things and dozens of others that the exporter already supports will eventually make it into the loader for TGE.