Rotation in GuiControls ?

#1 You may want to consider integrating the TGB layer into your project, and use that instead. By the time you start building up a lot of nifty "active GUI" functionality, you've in some ways approached how TGB can be used as a GUI layer on top of Torque.

#2 I wondered if you were going to mention that, Stephen!

;)

actually i meant to mention that as an alternative in the post,
it may indeed be the thing to do.

i'll take another look at the nifty 2D stuff TGB offers.

thanks.

#3 Hehe...am I that predictable?

In all honesty it's a huge gain for not that much work. While the editors have diverged due to extended and enhanced functionality, the underlying system was built from the ground up to integrate with other Torque engines, and what you can do with it is pretty amazing.

#4 Well i remember you suggesting it about a year ago as well.

is there a demo of TGB which shows off the various GUI features ?
or is it more like everything seen in the various games could be GUI ?

another approach we've considered is integrating Flash,
but in such a way that it's framerate isn't tied to the 3D engine framerate.

#5 Other than some "not ready for the public" work I've done personally, there isn't anything specific available.

The fundamental thing to keep in mind though is that due to how mouse events work with TGB objects (you can set two modes: a central dispatcher that receives all mouse events and passes them on via a large switch statement, or you can set each and every SceneObject to receive mouse events), you can almost trivially duplicate most major GUI capability with just a couple of dozen lines of script--and still have all of the cool movement, animation, mounting, rotation, and in some cases physics/collision capabilities of TGB objects.

But yah, any SceneObject can receive mouse events--in a standard callback system. From there, it's TorqueScript, you can do whatever you like :)

#6 I was actuallygoing to post the exact same question, since we are also interested in creating a more "spectacular" GUI. Reading this, a few questions come to mind. I will not go into specifics at all, just looking for generic answers for the moment, if possible:

Part 1, on the use of TGB:
1-How can it actually be used as a layer within TGE?
2-Is it possible to communicate between the two engines through script? How?
3-Would we have to run both engines at the same time (i'm thinking server synch for example)?
4-In that case is it possible to synch both servers? If yes, how? (I assume it could be done in script).

Part 2, if not using TGB (because TGB comes with a license fee ;) ):
1-What are the alternatives?
2-I saw a resource for rendering GUI elements on 3D objects here. How viable is this option?
3- Orion talked about integrating flash, is that doable?

Thanks a lot for any answers you could give, I do appreciate all the help I can get about this.

#7 You don't actually run two different engines--you simply (with a source code license) compile the TGB functionality into your engine. From there it's a matter of setting up the t2dSceneGraph on top of your 3D scenegraph.

All of your part 1 questions come from a false assumption--it's just one engine, with both TGB and TGE functionality.

1) Re-writing whatever portions of the GUI functionality you need to rewrite, for one.
2) Not sure I understand the question--use the resource and see if it works for what you are looking for?
3) Has already been done by multiple folks, and I think there is a resource on it. Doesn't make it a perfect (or even good in some cases) solution for everyone, but it's an option.

#8 Thank you for your answers Stephen. Been doing a little bit of digging and found out a bit more about integrating TGB with TGE. Seems too easy to be true! It's just a question of red tape now before we can get a developer license for TGB and test it out. I beleive it's the best answer to our needs.

As for the GUI as a texture resource, I will be looking at it more closely since it seems possible to have TGB levels mapped on an object which would make it even more interesting. It has been done, now all that remains to be seen is how. The only thing that worries me about this resource though is that it's not directly integrated in the engine (why? I don't know, it seems pretty cool to be left out!). This will make upgrading to a new version of TGE a bit tedious.

I will definitely have more questions once we start the integration so look out for me! ;)

#9 Some caveats to keep in mind while you are integrating:

--TGE is fully networked, TGB is not. However, since the objects are going to share the same root class hierarchy (down to NetObject at least), it would appear that you now automatically have networked TGB objects. Not true--it's not a trivial thing to re-work TGB physics to be tightly integrated with TGE ghosting. I'd suggest that you use this for client side only work unless you have an intimate understanding of all aspects of networking.

Important to note that the NetObject within TGB class hierarchy is the minimum necessary for NetEvents to work, while the TGE NetObject allows for full ghosting, so be careful that you don't break ghosting functionality during the integration.

--TGB is a separate product, and has branched in some cases rather signifigantly from core Torque. Datablocks and namespaces especially are used differently, and can cause issues if you aren't very familiar with the concepts.

Additionally, the builder itself is not going to be trivial to get up and running, since again it's branched out for specialized functionality. Personally, that's fine--for the use of creating a GUI inteface, most of what you are going to want to do will be dynamic in any case. It's certainly doable, but not going to be "drop in and compile" like the core code will be.

--We almost never integrate "special use" resources that are applicable to certain genres, game play mechanics, or general engine usage. Yes, it's really cool functionality--but it requires a full inclusion of the TGB source tree, a license for both products (at the source level in the case of TGB), and ultimately isn't valuable for a signifigant portion of projects, so we don't feel it should be part of the baseline engine at this time.

All that being said, the shared technology between the two products has been managed internally to stay consistent whenever possible, and the integration shouldn't be an amazingly challenging project :)

#10 Thanks for all the tips, Stephen.