#1 That's great to hear :) and thanks for the price drop/sale currently

I am curious were you able to get the rift to work with this or it still kept crashing the level?

#2 Hi NiN,

Are you sure the Rift demo works without a Rift? I remember I couldn't even launch the Rift template even without the pack.

I tried again now and I get a 0x000000 NULL reference as soon as I start the mission.

(Though there's really no reason the pack shouldn't work with the Rift as all of the warping of the view for the Rift should be done at a lower level than the GUI.)

#3 It does work without the rift i'm not sure why your getting that issue but what I will do is grab the pack and see if I can get it to work.

#4 Hi NiN,

Thanks! Let me know how that works out and if there's anything I can do to help. If for some reason it won't work, I'll refund your purchase.

#5 Bought, was one of my wishlist items, couldn't resist at the lower pricetag.

I'm also interested in using this with Oculus Rift, so will have a look at that when I get time.. time, curse my weak body needing sleep!

#6 Sleep is definatly an issue David! :)

Thanks for the purchase! I'd love to hear (or see, hehe) what you do with it and the Oculus Rift.

#7 Hello Stefan,

We recently purchased your pack and are excited about getting it running.

We are running AFX2.0 for T3D MIT 3.0.

Successfully made all the engine changes, and after recompiling am able to run the demo and see all the browser windows in-game.

However, when I try to add the support into my own game, when I try to create a new AwShape in the game editor it comes up blank, and converting my existing QT WebCube textures to AwShapes doesn't work - they likewise just come up blank and transparent now, with an error in the console:

Material - MainViewScreen_Mat(9648) - Failed to load diffuse map art/interiors/Bridge/MainViewSreen/#MainViewScreenName for stage 0

Here is the code in the mission file to create the object:
new AwShape(MainViewEarth) {
shapeName = "art/interiors/Bridge/MainViewSreen/MainViewEarth.dts";
playAmbient = "1";
meshCulling = "0";
originSort = "0";
collisionType = "Visible Mesh";
decalType = "Visible Mesh";
allowPlayerStep = "1";
renderNormals = "0";
forceDetail = "-1";
position = "-158.162 -0.184202 105.815";
rotation = "0 0 1 56.1313";
scale = "0.523782 1 0.449224";
isSTControl = "0";
canSave = "1";
canSaveDynamicFields = "1";
};


And here is my materials.cs code for the DTS in question:

singleton AwTextureTarget(MainViewScreen) {
//Unique name for the texture target.
TextureTargetName = "MainViewScreenName";
OnGainMouseInputSound = "WebShapeOnGainMouseInputSound";
OnLoseMouseInputSound = "WebShapeOnLoseMouseInputSound";
// URL to the website or file on disk.
StartURL = "art/interiors/bridge/mainviewsreen/MainViewScrn.html";
Resolution = "1024 768";
UseBitmapCache = true;
};



singleton Material(MainViewScreen_Mat)
{
mapTo = "MainViewScrn";
diffuseMap[0] = "#MainViewScreenName";
specular[0] = "0 0 0 1";
specularPower[0] = "2";
emissive [0] = true;
translucentBlendOp = "None";

};


The DTS has a part to it labeled "MainViewScrn" where we used to render the QT Webkit texture to, it used to display the web page we would tell it to in the materials file.

I thought just by editing the materials to follow what was in the demo, that my web pages should just come up. But they do not, and throw the console error above.

Anybody have any ideas?

The installation documentation was great, very easy to follow, however there seems to be a complete lack of implementation docs - in other words, once this is all compiled, how does one actually add a web-enabled object to the game?

There should be an additional set of steps at the end of the docs:

- specifics required when creating a new model
- how to set up the materials for the new model
- how to include the model in the mission file

Was able to figure most of this out because I had experience with the QT webkit which is similar in how you lay out the materials, etc, but for somebody with no experience they must be completely lost. Either way, even though I thought I did it correctly I get no web pages displaying, so am missing something.

Many thanks for the help.

P

#8 Hi Paul,

Just wanted to say I've seen your post and I'll reply as soon as I get home. Thanks! :-)

#9 Wow, fast reply Stefan!

Whenever you get time, no rush :)

Great kit by the way, can't wait to finish integrating it. I know I'm super close and must be missing something simple.

Cheers
P

#10 Update - I got it to work!

For some reason I had to name the materials/texture targets differently than you did in the demo...

Based on the demo code, I had tried this:

singleton AwTextureTarget(MainViewScreen) {
//Unique name for the texture target.
TextureTargetName = "MainViewScreenName";
};

singleton Material(MainViewScreen_Mat)
{
diffuseMap[0] = "#MainViewScreenName";
};


But, I had to actually label everything without the "Name" word in there, to match the awtexturetarget name:

singleton AwTextureTarget(MainViewScreen) {
//Unique name for the texture target.
TextureTargetName = "MainViewScreen";
};

singleton Material(MainViewScreen_Mat)
{
diffuseMap[0] = "#MainViewScreen";
};


Anyhow, I can see web pages now!!!!

However, no mouse input :(

I'm wondering if it has something to do with AFX, as AFX uses its own GUI overlay to trap mouse events.

I read another poster got this working in AFX, maybe I can pick his brain to see what he did.

Do you have any familiarity with AFX?

To get the QT webkit working with mouse events, I had to alter the way the AFX overlay passed events down through the chain... Perhaps this is the case here.

Thanks again
P

#11 Hi Paul,

Thanks for the feedback about the documentation. I'll see what I can do about it moving forward. My intention was originally to include a tutorial, but I figured a sample contained within its own directory (like with the Awesomium directory in FPS Example) would be better.

Quote:But, I had to actually label everything without the "Name" word in there, to match the awtexturetarget name:

That sounds like they changed something in T3D 3.0. The name specified within parenteses is a global name that each TorqueScript object has, while TextureTargetName is totally separate from that, at least in T3D 2.0.

Quote:
Anyhow, I can see web pages now!!!!

However, no mouse input :(

I'm wondering if it has something to do with AFX, as AFX uses its own GUI overlay to trap mouse events.

I read another poster got this working in AFX, maybe I can pick his brain to see what he did.

Do you have any familiarity with AFX?

Unfortunatly I don't have any experience with AFX. Are you attaching your Awesomium GUIs to shapes? In that case, AFX shouldn't be the problem because those GUI's are not "real" GUI's in the Torque sense.

I'll have to setup a T3D 3.0 installation and ask Matt as he's using it in 3.0 with success. To my knowledge he never had any issues with the naming.

#12 Thanks Stefan... Yes I am trying to use awshape().

I'm not sure about the naming issue or why I needed to do it that way, but it works so that's all good :)

With AFX, its own playgui overlay traps mouse commands so I have to alter it to pass through input to the lower playgui. I did this for QT webkit, and thought I had done it properly when putting your kit into the engine... But still no luck.

With QT webkit, it was the same setup for the shape - just code up a materials file with a mapping to a texture, although standard tsStatics were used instead of a new shape type.

Going to keep plugging away at it, I know I'm close.

Have to say though that performance with your kit is much better than the QT webkit... As I said, the kit is working at displaying all my web-enabled objects very well, it's just the mouse control that I need to figure out.

Will keep plugging away and will let you know how it works out.

Cheers
P

#13 OK, turns out the problem was just the raycast distance, nothing to do with AFX.

Had not correctly set the prefs value for the new prefs created for the awesomium raycast... I increased it to a larger value so the player now sees the Awshapes without having to be right up close. Now the mouse cursor comes up as it should and I can click.

Somehow I had missed that post about adding the new prefs to the client's prefs file. And also that the default was a close value of 2.

So woohoo! Off to the races.

Cheers
P

#14 Woohoo!

Yeah, I guess Awesomium itself is a little bit faster. And I spent a lot of time culling unused instances and trying to get them lighter if the Player isn't seeing them.

I've added that last bit about prefs.cs to the documentation. Sorry it wasn't demonstrated very well and glad you got it working now!

#15 What a great pack... I'm now playing with the Javascript to TorqueScript bridge, very exciting stuff.

Couple of questions for when you get a minute:

1) Is there an easier way to add AwShapes to the scene? Because as it stands I have my objects I use to put the web textures on, and I add them by going to Meshes and hunting through the directory tree and then selecting the object in question. This brings it in as a TSStatic though, and I have to save the mission file and quit out and then edit the mission file to change that TSSTatic to an AwShape. Then I can go back in and test... Is there a way to add AwShapes so they go in as AwShapes right out of the gate? Because with QT Webkit it used TSStatics - as long as we had the materials file correct, when we brought in a web object the web page popped up on it right away.

2) Also, I am curious as to the logic you are using to produce the mouse cursor and crosshair... We are exprimenting rith Oculus Rift support, and in your demo you have a standard crosshair that appears in both viewports in the Rift, whereas in our AFX version all the game crosshairs are planted firmly in the center of the screen between the two viewports... This may be the wrong place to ask, but I'm wondering how you assign cursor or crosshair to a specific GUI level? I'm thinking with AFX's own Playgui overlay that overrides the existing one, that it is taking over all this - I want to find a way to push the cursor and crosshair back down to a level where the engine will push them to both Rift viewports. Since your demo does this, I'm just trying to reconcile it with how AFX works, in order to hack a solution.

Thanks again!
P

#16 Glad you like it! :)

Quote:
1) Is there an easier way to add AwShapes to the scene? Because as it stands I have my objects I use to put the web textures on, and I add them by going to Meshes and hunting through the directory tree and then selecting the object in question. This brings it in as a TSStatic though, and I have to save the mission file and quit out and then edit the mission file to change that TSSTatic to an AwShape. Then I can go back in and test... Is there a way to add AwShapes so they go in as AwShapes right out of the gate? Because with QT Webkit it used TSStatics - as long as we had the materials file correct, when we brought in a web object the web page popped up on it right away.

You're right, and the Qt Webkit resource got away with it because it just tied materials and webkit render-targets together. It didn't manage those render-targets. Does it even handle any input? I'm not sure.

You can ignore AwShape if you don't require any input, and if you can live with there being no culling and load-balancing.

However, I'm going to see if I can make the editor create AwShapes directly. Thanks for the suggestion!

Quote:
2) Also, I am curious as to the logic you are using to produce the mouse cursor and crosshair... We are exprimenting rith Oculus Rift support, and in your demo you have a standard crosshair that appears in both viewports in the Rift, whereas in our AFX version all the game crosshairs are planted firmly in the center of the screen between the two viewports... This may be the wrong place to ask, but I'm wondering how you assign cursor or crosshair to a specific GUI level? I'm thinking with AFX's own Playgui overlay that overrides the existing one, that it is taking over all this - I want to find a way to push the cursor and crosshair back down to a level where the engine will push them to both Rift viewports. Since your demo does this, I'm just trying to reconcile it with how AFX works, in order to hack a solution.

The mouse cursor is rendered in software by blitting the cursor icon ontop of the render target after it has been rendered by Awesomium. Take a look in AwContext::blitCursorToTexture() where this all happens.

The crosshair is simply just being hidden when input is captured by the pack. It's just an if statement in GuiCrossHairHud.cpp. So I'm not sure why it's different in your AFX build as I haven't touched GuiCrossHairHud apart from that if statement, which is added in the implementation tutorial.

The cursor is different though as it's custom-rendered. I've talked to NiN (above) and he's been kind enough to supply me with a Rift build based on the pack and I'll take a look as soon as I get some free time.

#17 This is great, thanks!

And yes, QT webkit handled mouse input fine, but it did so in a completely different way - it created a new control called MyGameTSCtrl which piggybacked on top of GameTSCtrl (which is used for the playgui), and then managed input by trapping mouse inputs at the playgui level and passing them through to the webpage target.

This proved to be an issue with AFX, since it also uses a custom Playgui overlay - we had to alter the AFX gui system so that the chain worked properly and mouse input was passed correctly through all the layers down to the control. Once I figured out what was going on it was a relatively easy fix, just changed the inheritance order of all the controls and made sure everything was being passed from parent to child on all mouse inputs.

Never did manage to get keyboard control of the webpages working with QT webkit though, I would love to be able to do this with Awesomium if it's possible - in other words be able to sign in to Facebook or Gmail or something right in the game.

Thanks for offering to work with NiN on the Rift stuff - I know it's a real niche market and not many of us are using it, however it's a really exciting concept and I think it would be very cool to have a Rift version on our game where all the clickable elements, etc, are done using Awesomium right on in-game textures rather than using traditional popup guis (which do not stereo render in the Rift, at least I don't know how to do so).

What would be really beneficial as well, is knowing the additional steps to getting this to play nice with AFX... Because of AFX's customizations to the GUI system, the crosshair issue I mentioned occurs as well as other conflicts with mouse control (AFX has mouse control enabled by default at all times so you can select things like AI or objects to target for "spells", and you have to hold the right mouse button to pan around, as opposed to stock T3D where mouse cursor is not enabled and you pan around as soon as the mouse is moved).

AFX is very cheap to buy, and is a lot of fun to play with... Perhaps you could consider giving it a try and see if it's possible to make it more Awesomium friendly? I'm doing my best at figuring it out, but am more of a script programmer and working in the engine is always trial and error for me :)

Thanks again for the response, it's great to see how you support your product, cheers!

P

#18 Thanks for the kind words Paul, I really appreciate it!

Making the pack play well with keyboard input ingame isn't too difficult. I just wasn't sure how to approach it. Should I have captured input when you walk up to it? How do you walk away then? It's so game specific I didn't know where to start. I agree it would be a cool feature.

Yeah, the Rift is a cool device. It's on my list of things to buy, AFX is too. I just haven't had the time to sit down in a while.

Quote:
What would be really beneficial as well, is knowing the additional steps to getting this to play nice with AFX... Because of AFX's customizations to the GUI system, the crosshair issue I mentioned occurs as well as other conflicts with mouse control (AFX has mouse control enabled by default at all times so you can select things like AI or objects to target for "spells", and you have to hold the right mouse button to pan around, as opposed to stock T3D where mouse cursor is not enabled and you pan around as soon as the mouse is moved).

So there's no freelook in AFX? Right now the pack casts rays where the crosshair is located, and all AFX would need in that case is to change it so it casts rays from the cursor instead.

#19 Yes I see the issues around the keyboard input - in our case, as long as the Awshape has focus (ie. when you are within range and looking straight at it and the mouse cursor appears), it would be great to be able to click on a text field and enter data then still be able to click other links on the web page... Then when you lose focus on the Awshape the keyboard control would be returned to the player. Is that something very difficult to pull off do you think?

As for freelook, yes we have that as a toggle in AFX, it's just the default is to have a mouse cursor on-screen when you load up - then you can free-select objects in the environment as targets simply by left-clicking on them. To pan around, you hold right mouse button and move the mouse. To fire a weapon, you click left button while holding right button down. In freelook mode, it basically simulates holding the right button down, so you no longer have a mouse cursor and moving the mouse pans your view. A single left click will fire the weapon when in freelook mode.

The raycasting to enable the Awshape and its own internal mouse cursor is actually working fine wherever you are pointing whether in freelook mode or not, and also whether the Rift is being used or not... What is not working is the crosshair system - AFX is overriding it somehow and their crosshair is always center screen. Works great when in full screen mode, it just does not get mirrored in the viewports when using the Rift like it does in your demo, it remains center screen.

I like your idea of raycasting from the cursor though instead of from the player's view, and that may actually help in a number of ways, but my regular mouse cursor is also not getting mirrored in both viewports - it is based on the full screen.

If I can figure out how to get both the AFX crosshair and the AFX mouse control to work in the Rift in stereo, that would be awesome. As then I could adapt the raycast code to be wherever the mouse cursor is, and then we could preserve our existing functionality of being able to free mouse around a room while standing still and click on various objects. We would also no longer have to be facing an awesomium web object in order to gain control of it (not that this is a problem now, it works great, it's just with QT webkit we didn't have to be facing the object so it just changes the game play a bit).

Did I mention that our project is a complete build of the original starship Enterprise NCC1701? So there are a lot of clickable objects in the game with lots of functionality, and they continue to work fine as long as the Rift is not enabled. It's just this annoying mouse cursor and crosshair issue that is preventing me from clicking on those objects when the Rift is enabled... Think of trying to find a mouse area on the screen blindly, when the scene is being mirrored in effectively half the screen size but the mouse area coordinates are based on the full screen width.

Really this is a problem with the Rift integration and AFX, not with your kit... But I just thought I'd bring it up here for discussion, and hopefully if I find a solution you can add it to the docs for those users who want to integrate your kit with AFX and have it be fully Rift-compatible, resolving the issues with AFX cursor and crosshair.

So... It's a process :)

I will try to post a few screen caps that will maybe shed some light on all of this. Kind of hard to explain without visual aids lol

Cheers
P

#20 Here are some images to illustrate...

First, the bridge console as seen in normal game mode (no Rift). Note that the circled region has clickable buttons, each one is a standard TSStatic with an associated command - some custom code we put in the AFX object selection enables us to execute the command when a player clicks the object:



Now, the same scene in Rift mode, with the mirrored viewports. It's hard to see, but the crosshair is dead center screen when in fact there should be twin crosshairs, one in the center of each viewport. In your demo, that works correctly, being stock T3D which seems to handle it properly... However AFX is overriding that somehow with its own crosshair. Also, note the circled region is where the mouse control is, based on the full screen, rather than it being properly mirrored in both viewports. This makes it near impossible to click our objects when using the Rift:



Here you can see, again in non-Rift mode, the AwShape working correctly with its own cursor appearing when I get close enough to the object:



And now the same scene in the Rift. The mouse cursor in the AwShape is being mirrored correctly and the web page is usable in the Rift:



So, what I am trying to achieve is the same dual-cursor and dual-crosshair that is in the demo, and although I am halfway there by getting the AwShapes all working properly, I have this issue with the AFX crosshair and mouse control.

Anyhow, that gives you an idea. I will keep plugging away and will post any solutions I figure out, as they will help anyone else trying to use this in AFX.

Cheers
P