T3D Awesomium Integration Pack - Released

#41 Hey, while we're on the subject, would it be possible to make the audio smarter about going out of scope? It seems to go on playing no matter how far away you are from the source, or whether or not you have it in view.

Thanks again for the great work though! You've already _vastly_ improved my project and I feel like I haven't even scratched the surface here.


EDIT: one more thing, while I'm on a roll... in Player::processAwesomiumTick you do a raycast to find the AwShapes, but you might want to make the length of the end vector scale by a user-controlled range variable. If you make large awesomium textures the default two meters feels awfully close.

#42

Quote:
Hey, while we're on the subject, would it be possible to make the audio smarter about going out of scope? It seems to go on playing no matter how far away you are from the source, or whether or not you have it in view.

If you're using Flash sounds you'd have to expose a JavaScript function that you can set the volume with, or let your game set the volume with based on range to the animation. Or you could use sounds in T3D and play them (that's what I do) there instead of in Flash.

There's no way for me to automatically manipulate the volume for all flash animations but it's a very common feature request on the Awesomium forums. It's because of the nature of WebKit and how plugins work, and Berkelium/Qt works in the same way unfortunatly.

Quote:
EDIT: one more thing, while I'm on a roll... in Player::processAwesomiumTick you do a raycast to find the AwShapes, but you might want to make the length of the end vector scale by a user-controlled range variable. If you make large awesomium textures the default two meters feels awfully close.

Fair enough, it's in. :)

$pref::Awesomium::RayLengthScale
Scales the distance of the ray used to pick the input target. (Default: 2.0)
$pref::Awesomium::ImageDropSpeed
The speed at which the Players' ShapeImages are dropped when an AwShape receives focus. (Default: 2.0)
$pref::Awesomium::LoadBalancingDistance
The distance for Load Balancing. A higher value sacrifices performance for quality. (Default: 50.0)

#43 Hey Stefan,

It occurred to me that quite a lot of my usage of Awesomium is ending up as non-interactive output drawn to TSStatics... and for those, there's really no reason to be running a 4M awesomium process at all. The win from awesomium in this case is all about the easy layout and options available in html, not the live interactivity.

So, I added a function to your AwTextureTarget class called "writeToBitmap", with an attached engine method, so now I can save out to an image whenever I want and use that in the release build, instead of interpreting live html for all the billboards.

Here's the code... in AwTextureTarget.h:

void writeToBitmap( const String &path);

And in AwTextureTarget.cpp:

void AwTextureTarget::writeToBitmap (const String &filename)
{

	FileStream fs;
	if (!fs.open( filename, Torque::FS::File::Write )) {
		Con::printf("awTextureTarget can't open bitmap path: %s!",filename.c_str()); 
	} else {
		Con::printf("awTextureTarget saving bitmap to path: %s!",filename.c_str()); 	
		if (mContext) {
			GFXTexHandle texHandle = mContext->getTexture();
			GBitmap *bmp = new GBitmap(texHandle->getBitmapWidth(),texHandle->getBitmapHeight());
			String bmpType = "jpg";
			//bmp->fill(ColorI(0,128,0));
			texHandle->copyToBmp(bmp);
			bmp->writeBitmap(bmpType,fs);
			delete bmp;
		}
	}
}

DefineEngineMethod (AwTextureTarget, writeToBitmap, void, (const char *path),, "writeToBitmap(String path)")
{
	object->writeToBitmap (path);
}

For now, to take it to "release mode" I'm just commenting out the affected AwTextureTargets and swapping the diffuseMap from the AwTextureTarget to the static image in my materials... what would be really cool is if there was an AwTextureTarget property that, if set, could cause it to automatically write its texture to an image at load time, and then switch the material over to use that image, and then turn off the Awesomium process. That way it would get the desired behavior but still load up the current html file every time. Just a thought...

#44 Are all those shapes using the same webpage? If they are, then you'd just use one AwTextureTarget and map all the AwShapes to it, creating only a single Awesomium process.

In any case, I think your feature suggestion is fair. :) I'll let you know when it's completed.

#45 Nope, all different web pages, most of them very simple.

Awesome, thanks!

Any idea what could be causing my crash with your new code? I haven't tried it again but let me know if you put up more updates, maybe whatever the problem is will just disappear...

#46 The pack has been updated with the above mentioned feature suggestion. You set the AwTextureTarget property IsSingleFrame to "true" and you're good to go.

It's really lightweight and there's no Awesomium process idling in the background. If you keep changing your webpage and you want to see the changes right away, call AwTextureTarget::reload() from the console and it'll update even if it's SingleFramed.

Quote:
Any idea what could be causing my crash with your new code?

Can you reproduce the crash? I haven't been notified of any crashes but if you can show me where it crashes, or the steps you take to make it crash - that would be much appreciated.

Thanks Chris!

#47 So, okay, grabbed your latest update, and my crash went away! Don't know what that was about.

I did have some trouble with the majority of my AwTextureTargets going black screen of death when I plugged in your new code, however. I never did figure out what the difference was between some few that worked and the majority that didn't, because I figured out that it was only affecting TSStatics, and when I changed them all to AwShapes everything worked. Thought you might want to know about that, though. Everything was working fine with them before, the only change was the new engine code.

Also, you mentioned something about an exit crash, I'm getting that just about every time. Can't say for sure whether it's coming from your resource or not, but I don't think I was having this trouble before. Will be plugging your pack into a stock T3D build at some point to isolate anything local to my build.

Overall it's working great now though, the processes have shrunk down to just the ones that are not "single frame". Thanks for the quick response!

#48 BTW, you might consider throwing my writeToBitmap or some equivalent function in your resource even after your new update - I'm finding it useful to be able to save the output to an image file, if only so that I can load a texture faster than the awesomium textures load.

This matters a bit for the one billboard that is facing my player on level load, it can stay black for several seconds while the rest of the actors and scene objects load up, but if it's a static texture it pops right in.

#49

Quote:
So, okay, grabbed your latest update, and my crash went away! Don't know what that was about.

If you're still using TSStatics together with AwTextureTarget then that might be the reason you're crashing, they're not intended to work together. I wanted to support all objects in T3D initially, but there's no way to keep track of everything (to load balance and give input) without creating a new object class or heavily changing how materials work.

Quote:
Also, you mentioned something about an exit crash, I'm getting that just about every time.

It's mentioned in the documentation, with the required change to T3D for it to go away. It's in WinProcessControl.cpp I believe, but I'd check the documentation again to make sure.

But I do think the issues you're seeing is due to not using AwShape.

Quote:
This matters a bit for the one billboard that is facing my player on level load, it can stay black for several seconds while the rest of the actors and scene objects load up, but if it's a static texture it pops right in.

I've added a new property for AwTextureTarget to rectify this which is called UseBitmapCache. It's a boolean value telling the AwTextureTarget to save a cache which is used each time the target is loaded but the webpage itself hasn't finished loading yet. No more black screens. :)

#50 Aw, found it! I had already switched everything over to AwShapes, but the problem was I had then switched that one AwShape (the first billboard) over to a static texture instead of an AwTexture. This caused the following function to break:

void AwManager::removeShape (AwShape *shape)
{
	sShapes.remove (shape);
	shape->mTextureTarget->mNumShapesBound--;
	if (!shape->mTextureTarget->mNumShapesBound)
		sTargetsByMaterial.erase (shape->mMatInstance);
}

Since you've addressed the speed issue, I'm switching back to the AwTexture now, but for good measure I added a safety check in that function as well:

void AwManager::removeShape (AwShape *shape)
{
	sShapes.remove (shape);
	if (shape->mTextureTarget)
	{
		shape->mTextureTarget->mNumShapesBound--;
		if (!shape->mTextureTarget->mNumShapesBound)
			sTargetsByMaterial.erase (shape->mMatInstance);
	}
}

And, everything's happy now even if you do accidentally do that for some reason.

This pack has changed everything, can't wait to experiment with HUDs and other actual GUI applications of the tech. Thanks again for making it happen!

#51 Oh, one more thing, did you mean to make a change to player::processAwesomiumTick in your PDF? It seems to still have the hard coded 2.0 in the raycast. I fixed it locally like so, I assume this is what you did on your end:

//Point3F end = start + (dir * 2.0f);
	Point3F end = start + (dir * AwManager::getRayLengthScale());

However, I'm having a bit of trouble getting my prefs to register. I put a $pref::Awesomium::RayLengthScale variable in client/prefs.cs, and then server/prefs.cs, but neither of them registered, it just went back to the default 2.0. Any advice on the right way to define those?

#52 AwManager::removeShape() was fixed in the BitmapCache update. But it's the same as the fix you posted.

Quote:
Oh, one more thing, did you mean to make a change to player::processAwesomiumTick in your PDF?

Sorry, I didn't include the PDF in this update. It also concerns the ImageDropSpeed setting. Fixed, thanks!

Quote:
However, I'm having a bit of trouble getting my prefs to register. I put a $pref::Awesomium::RayLengthScale variable in client/prefs.cs, and then server/prefs.cs, but neither of them registered

You have to put it in the clients' prefs.cs file or it will be pruned by T3D. I did include a change in the pack though which makes it possible to change the value in realtime, incase you'd like to test different values without restarting T3D.

Let me know how that works out! I'm pleased that you like the pack. :)

#53 Sorry to dredge up an old thread but am wondering if there's a way to attach the sound coming from a video for example to a 3d sound emitter so it's distance can be controlled?

#54 I'm afraid there's no way to do that with how Awesomium is designed. I asked for a way to control the volume so I could create a distance-based fade for the volume, but they never replied to this request.

#55 I wouldn't think we'd use Awesomium to control the audio, I'd think we'd use the awShape and maybe tie it into a sound emitter?

#56 Awesomium produces the audio directly, so it's in charge of how it's going to sound and at what volume. The audio it produces isn't anything we have any control of. Sorry.

#57 Is there a way to turn off the audio completely?
Also, is there a way to trigger a running video screen to turn off or reset to it's initial state?

#58 There's no way to turn it off in the Awesomium versions used in the pack. I don't think they added such a feature later, but it's possible.

You can reload the instance or just load the same page again, to reset its state.