Version Alpha 3 is now available.

Information and download info for the Web plugin can be found here: http://www.hash.com/hamr

You will need v13.0j or higher to create HAMR content. More info about creating content can be found in the above web link.

Standalone HAMR Viewer: HA:MR Viewer Installer[5m]

Have fun & please report any issues to A:M Reports (There is now a separate project for reporting WebHamr issues.)

Fixes since the previous version:

This section is for "Use Case #1" (walk through) support.
***************************************************************************

• "Walk Through" and "Fly Through" supported via arrow keys or mouse. (Ken H.)
• Chor constrained camera mode added. Can't vary from chor path. Can look
  around. Arrow keys etc. move the camera along the chor timeline.
  Settable via HAMR.hxt or see Template3.html for JS example.
• Eliminated right mouse click for About box. (HeyVern)
• Added right mouse control of camera position and orientation (Ken H.)
• Middle mouse button control supported same as A:M. (Ken H.)
• WASD and IJKL control keys correspond to the arrow keys. (Ken H.)
• PageUp/PageDown keys reassigned to move camera up and down.
• ,< and .> keys move camera left and right.
• Camera control keys with SHIFT=fast, with CTRL=slow.
• "Camera ground tracking" option added via HAMR.hxt or Javascript.
  See Template3.html example for how to call this from JS.
• "Camera world collision detection" option added via HAMR.hxt or Javascript.
  See Template3.html example for how to call this from JS.
• ALT key with arrow keys overrides collision detection. Walk through walls.
• Global moveability and turnability flags overrides camera controls.
• Global turnability flags overrides view controls.
• HAMRViewer opts for camera ground tracking,collision detection,chor constrained.
• First pass "smart patch splitting" option algorithm implemented. (HomeSlice)
  Splits based on system speed. See Template3.html for example
• HAMR now uses the projects A:M camera background color as default.(HomeSlice)
• CTRL-F now turns on statistics display in WebHAMR.
• CTRL-V now toggles adaptive patch splitting mode in WebHAMR.
• CTRL-B now toggles smart patch splitting mode in WebHAMR.
• Turned off the camera frame display
• Added +/- key support to go to next and prev frames.
• Relative file path function placed in template examples. HomeSlice, Noel

***************************************************************************

• Fixed binary load problem for Expression objects.
• Fixed problem with prev and next buttons not enabled if chor length < 1 sec.
• Fixed crash related to file not found dialog box not being locateable.
• User will see missing file messages now. Creator beware!
• Fixed fundamental binary load problem that sometimes caused crashes.
  This change alone makes this update worthwhile.
• Fixed Javascript color background setting problem. (HomeSlice)
• Fixed realtime Ground vertex shading problem.
• Fixed time not being reset to 0 after multiple file loads.

A:M Reports

• 0003601: [WebHAMR Plugin] more mouse navigation options (HomeSlice)
• 0003689: [WebHAMR Plugin] middle mouse drag = pan (HomeSlice)
• 0003708: [WebHAMR Plugin] Middle mouse button and wheel control! (KenH)
• 0003734: [WebHAMR Plugin] Get binary error with binary project load (KenH)
• 0003683: [WebHAMR Plugin] Support for relative paths from the .html file and the <BASE> tag would be handy (Noel)
• 0003747: [General] street scene from the cd crashes soon after drawing (Noel)

This is brilliant! This is how alien song was meant to be seen. (I found a finger going though her head too!)

I can't get Control B to do anything obvious. Also, a small point....the minus on the numpad doesn't go back frames but the plus goes forward. Both work on the main keyboard keys.

Wow. Great update!

I've been out of the loop on HAMR lately. I still haven't gotten my PC fixed yet... so I use it very... carefully...

This is AMAZING! The updates look fantastic and I can't wait to dig in as soon as I get my PC working properly.

Camera World Collision detection?!?!? Cool!

-vern

Camera world collision detection? Could that mean games?

C

Colin,

It sounds to me like... limited collision detection so the camera can't go through objects or "walls".

Good enough to start with for some of my ideas.

-vern

Just to whet your appetite, I thought I'd give an outline of the current direction that HAMR development is taking.

1) HAMR Alpha3, use case #1 primarily defined by KenH, HomeSlice and HeyVern is the "walk through" or "fly through" capabilities along with support features such as ground tracking, camera-world collision detection and choreography timeline constrained movement. Ground tracking keeps the camera a certain distance above the closest world object below the camera, so you can walk up stairs etc. if desired. Collision detection prevents the camera from moving through any world object geometry such as walls (unless the ALT key is pressed along with the arrow keys in which case the camera can pass through the collision object). The choreography constrained mode allows the the forward and back arrow keys to be used to move the camera along the choreography time line. Instead of moving the camera in space, it moves it in time. The camera cannot be moved off of the chor path but can be panned around and zoomed to look at things off of the chor camera timeline. The next time the arrow key is pressed, the view returns to the current chor timeline camera view.

2) Use case #2 primarily defined by HeyVern is the ability to move a character (figure or model) through the world with the arrow keys. At least 1 idle action and 1 moving reusable action will be defineable via the HAMR.hxt plugin and the character will transition from idle to moving when the arrow key is pressed, will move in the direction of the camera and when the arrow key is released will transition from moving to idle action. There will be character-world collision detection capabilities.

3) Use case #3 primarily defined by HeyVern will allow the content creator to use the HAMR.hxt plugin to map reuseable actions to keyboard key presses. So, press a key and the character jumps, or whatever the mapped action does. These actions will be blended with whatever actions are active from use case #2. There will be the ability to map several keys and actions. Hopefully even simultaneous multiple key presses and associated actions can be blended.

4) Use case #4 is similar to use case #3 but allows the content creator to use the HAMR.hxt plugin to map pose transitions to keyboard key presses. The basic idea here is that a "performance" could be done in realtime using these keys along with action keys of case #3. Although the keyboard will be the primary input device for this use case, I hope to also support a midi realtime control (so midi controller electronic sliders could be used for realtime performance control) and possibly alternative input devices such as a game controller. If a game controller interface is done, use cases #1 and #2 will be retrofitted with gamer controller support to move the camera and/or character around in the world.

Ken Chaffin- Hash, Inc.

My God... its full of stars ;-)

C

Does anyone else get slow fps on the gala model example? Also her right palm looks funny....like there are cps unassigned.

Ken,

You can just call me Vern..

Heyvern sounds so... formal.



I am thrilled to know my use cases were found helpful! I look forward to trying out the new features. I didn't expect it to happen this quickly...

... I forgot this is Hash... not Microsoft.

-vern

I think the Gala "sharding" is caused by something in the new multiprocessor code. At least it has been in other cases. I have submitted a report for this in the V14 section. That may be causing slowness also but I haven't observed the slowness myself.

Ken Chaffin








Vern!

Hopefully this third edit will put my reply relative to your message rather than KenH's, but if not, it is for you.

I hope I didn't raise premature expectations. Only "Case #1" is included in HAMR Alpha 3 release. I've begun work on case #2 but you won't see any of that and later until the next release.

Ken Chaffin- Hash, Inc.

Cool! Damn Cool!
Thank you very much for the overview of your next steps and thanks for the first step. That is a really great update.
It already is more, than I would have expected from HAMR when martin first mentioned it.

It sounds like a easy to use and set up small game engine in the browser-window...
Go on Ken, you are doing a great work there!
*Fuchur*

It made sense to me. I got the picture.

I just feel... a bit proud that the use case I did was useful at all. I learned a lot researching the concept and have been using it for other things as well. I have to thank Martin for pointing me in that direction.

p.s. My doctor gave me some pills for "premature expectations"... so I don't get those as much anymore.



-vern

Ah ! HA:MR is just GREAT stuff !

It give me lot of ideas...


I would like to see a mac and other browser version available, so we would be able to use it commercially.
Some potential clients I tought to about that technology ask me about those compatibility issue...I've said it would come soon ...I hope


thanks a bunch

Al

You know what to do AL. As soon as we get 12 people showing a HAMR project on their webpage then we get Firefox/mozilla support started. Currently, we have about 8 people.

This probably has nothing to do with HAMR. I worked out that the slowness is because I was opening it in the Firefox extention called IE Tab. It get's fps of about 5 while in the real IE, I get 16fps.

PS I think HAMR only lacks one major thing now.....real time shadows (even basic will do). I've submitted a report already, but I just can't wait till it gets this!

How is this distance defined? Is it a standard distance or does it depend on the size of the camera object? Thanks.

Ken,

This ground tracking distance is just regular distance as measured from the camera position straight down to the first (if any) object below it. So, anything can be a "ground" object. The collision detection is a bit more complex but not too much. Forward and turning camera collision detection is relative to the center point of the camera viewplane in the direction of camera motion. Backward detection is relative to the camera position in the direction of camera motion. Please note that in the Javascript function you can pass the ground tracking distance as an argument. Otherwise the default is 100 cm. (or A:M units).

Ken Chaffin- Hash, Inc.

LOTS of progress here! Looks like KenC has been working overtime! You send us all scrambling to experiment Ken, and for that I thank-you. I really like the direction you are taking this.

Okay. Now you've caught my interest.

Real-time user choreographied ballet sequences for a certain Tutu-Dancing Cowamina - Pirouettes, arabesques, & grand jetes ! Tra-la! Udderly dee-lightful.

Oh I quiver at the potential humilation to be inflicted.

But despite my evil inclinations, I also think - it could be used as a real-time tool for dance instructors (real & fake, all genres of dance) to work out performance routines, given a nice library of actions...

Holy Cow!

I keep thinking of this in terms of "games"...

You're right Nancy... I never thought of... blending... actions like that for instructional purposes.

Instead of creating content to rot the minds of impressionable youth... actual educational content could be produced.

Holy cow! As in your idea, a specific dance move could be viewed from any angle... and as I already have shown with the dancing bear... BVH motion from real dancers could also be incorporated...


This of course... spawns a new idea... with javascript access to those actions... in future versions of HAMR maybe... a simple JS could be written to create "plugin" dance sequences... stringing together many actions.

Good grief! You could do the same thing with lip synching. Drop in an external JS file and a new lip synch JS action file and a new audio file... and you could use one project to do a whole bunch of stuff.

You could have one project with several characters... drop that project into a new HTML file and have a completely new scene.

I am getting carried away again...

EDIT:

Imagine virtual models of a group of dancers... each dancer has it's own set of commands for each dance "move".... you COULD choreograph a dance sequence using JS and play it in real time...

You could create a virtual "band"... and create plugin JS for "performances"... whoa... I'm getting dizzy...

This also plays right in to "reusable motion" that is a huge feature of AM.


-vern

It has been quite some time since I last looked at HA:MR but when I read Ken Chaffin's outline of where he hopes to take it in future releases I got quite excited.

I installed the latest standalone viewer and set about looking at some of my projects to see how things had progressed.

Some projects refuse to open and quite alot of them trigger a message that HA:MR is repairing a group with the same CP listed twice. Often a message is displayed that says that the model is not compatible but then it opens anyway.

I am experiencing great frame rates with some of the low patch game characters that I have produced. I have a little character going through a variety of actions and with Fixed Subdivision enabled I get rates of 63 fps when not interacting with the mouse and 53 fps while interacting with the mouse. This is a low patch model which produces a patch count of 3176 with 1 to 4 patch splits. I think that this allows enough room to add some simple scenery and maybe another character without dropping the frame rate below say 12 fps. It just needs a few things and Ken seems to have already identified many of them.

Some additions that would make HA:MR more appealing:

1) The ability to hide the HA:MR interface and provide instructions via a pop-up or simply on a webpage, with the HA:MR window embedded on the page.

2) The ability to restrict access to specific controls. For instance preventing the viewer from viewing in wireframe mode.

3) Improved decal definition.

4) Specifically for game-like experiences:

-Fast sequence switching.

-Camera commands. ( attach cam to object, set default position, avoid objects, location dependent camera actions.)

-Player commands. (key presses determine an action sequence).

-IF...THEN conditions to trigger events, including sequence switching, playing a sound, playing a video file, etc.

5) Reset location of camera to it's original position. (Not so much for games but useful for standard object viewing).


I haven't read all the threads on the development of HA:MR and it seems that most, or perhaps all, of these points are being addressed so excuse me if I am going over old ground.

It seems like only yesterday that we were talking about how cool it would be to develop a game that uses splines rather than polygons or sprites. It seemed a long way off at the time but, in true Hash style, someone lit a fuse and the rocket has launched! Okay, it may be some time before we can expect to be immersed into a game experience that rivals the poly world but the journey has started and I am sure that HA:MR is going to make some big waves.

Absolutely brilliant, Ken and Martin! Keep up the great work.

That's the same message I get when I open v12 projects in A:M v13. Are you opening projects created in v12?

Many of these are addressed in the Web Hamr but not in the stand alone viewer. It would be nice to be able to modify the stand alone interface.

in Web Hamr you can do that with:
CWebHAMRCtrl.SetToolbarVisibility(false)

in Web Hamr you can do that with:
CWebHAMRCtrl.SetMovementModeToolbarVisibility(true)
CWebHAMRCtrl.SetProjectionModeToolbarVisibility(true)
CWebHAMRCtrl.SetRenderModeToolbarVisibility(true)
CWebHAMRCtrl.SetPatchSplittingModeToolbarVisibility(true)
CWebHAMRCtrl.SetPlayControlToolbarVisibility(true)
CWebHAMRCtrl.SetTimeDisplayToolbarVisibility(true)
CWebHAMRCtrl.SetScrubToolbarVisibility(true)

In the web Hamr you can do that by pressing the "1" key on the keyboard - not the keypad

I have been opening projects created in A:M 11, 12 and 13 alpha so I guess that is why I am seeing this. Thanks.

Thanks also for all the additional information, Holmes!
I am looking forward to being able to create a small set that the user can walk through with a camera that follows the user controlled character.

Hm... sounds like a bug which I run into from time to time.
That has to do with your project and means, that it has a problem.
But you can fix that by activating the "repair"-function of A:M in the registery. I cant remember (and couldnt find it yet) but I think Hash can tell you something more about it.
I used it back in v11 or something like that.

But I would recommend to ask Hash about it, because the registery is very important for your computer and the installation of A:M and I would not recommend to play with it unless you know exactly what you are doing.

*Fuchur*

Umm....it's probably a stupid question, but how do I set the collision detection to on? I thought it was in the chor properties, but I can't find it. I want it so the camera will bump into things. Thanks.

Edit: Also, how can I make the HAMR project play as soon as it's loaded?

<script type="text/javascript" for="CWebHAMRCtrl" event="OnProjectLoaded(name)">

CWebHAMRCtrl.SetCameraCollisionDetection(true)
CWebHAMRCtrl.DoStartPlay()

</script>

It is at the chor-hamr-properties. Search again and I am sure you can find it. I cant look right know, but I am sure.

Play at start can be setted via java script:
DoStartPlay(); if I am not wrong will do that... look into the template3.html-file.

*Fuchur*

Thanks guys. I got it working....