Jump to content
Hash, Inc. Forums

k_chaffin

Hash, Inc
  • Posts

    164
  • Joined

  • Last visited

Profile Information

  • Name
    Ken Chaffin
  • Location
    Texas

Previous Fields

  • Hardware Platform
    Windows
  • Programmer
    Yes

k_chaffin's Achievements

Journeyman

Journeyman (4/10)

0

Reputation

  1. The HAMR viewers source code contains some of A:M's source code as well as require a number of A:M "headers" which expose the data structure of A:M as of v14/15. Whether that contains any Hash proprietary trade secrets would be up to the Hash Inc. management. For someone to fully make use of HAMR requires a high level of programming expertise, including COM and ATL automation. I exposed the A:M SDK functionality via automation. The viewers themselves are fairly complex Windows graphical applications. I was and still am under a non-disclosure agreement regarding A:M source code and algorithms. Ken
  2. I've been looking into whether it is feasible to call the HAMR DLL from within Unity and I have to say that it is not very feasible. My work in Unity is all via C# under the MonoDevelop .NET framework. C# can link to DLL and call exported functions but to produce something useful, the C# script would have to include a lot of the HAMR header files which are designed for C++ and the MS MFC. It might be more feasible to write a C++ extension to Unity but that would be a major undertaking. What I was exploring was whether it might be simple to call the HAMR DLL via C# in Unity and although that would probably be possible, it would take an extremely large effort to fully implement an A:M file parser and convertor to Unity objects. So, I suggest that you use HAMRViewer as-is if it suits your needs, but don't count on new applications to be developed using HAMR. The full HAMR SDK was never published, so there is not enough info and required files out there that would enable a HAMR user to do such an application. The end-game for HAMR was the viewers, rather than a public SDK. The viewers themselves contained Hash Inc. proprietary information. Sorry I don't have better news. Ken Chaffin
  3. I developed MetaHAMR between January 2007 and April 2008. It was a Hash skunkworks development funded out of Martin's pocket. It was never made public. It worked great though as we tested it with several developers from worldwide locations. Well, amazingly it sounds like the 2008 HAMR API will still read A:M files! That is good. I do not think it would be feasible to recompile HAMR against the current A:M source code base. There would probably be a lot of missing 3rd party libraries. I am guessing that the use of most 3rd party libraries were eliminated when the 64-bit A:M version was developed. That is probably why the PRJB format was discontinued as that was reliant on a 32-bit zlib compression library. But, since HAMR will still read A:M files, there is no need to rebuilt it. It should work with any 32-bit Windows application calling the DLL functions. I'm going to explore a bit calling the HAMR DLL from a Unity C# script. It should work since Unity is still primarily a 32-bit application. I currently call my CUDA DLL from Unity with no problems. It may be possible to parse and load the A:M files from within Unity. I will have to see if I exposed enough functionality in HAMR to get to the patch or poly models and get them into Unity and create a Unity poly mesh model. If was still doing 3D web plugin development, I would work with WebGL as you all were discussing above. It might be possible to use WebGL programs to talk to the HAMR DLL, but that be quite a challenge to develop and would only work with Windows. By the way, at Texas Tech University I built a Remote Access 3D Lab where all manner of 3D animation programs run on 20 Windows rack-mounted workstation in our data center and then via Citrix XenDesktop HDX, the 3D applications can be used remotely on any device. So, A:M can run on an iPhone in this environment! I do not currently have A:M loaded on these systems though I have in the past. Ken Chaffin
  4. [Ken] Please excuse my quote formatting as I haven't used this forum in a while. What you mean is... even though anyone who doesn't own A:M can download the HA:MR viewer plugin and view HA:MR content, the HA:MR plugin itself incorporates proprietary Hash, Inc. A:M code and needs that code to do what it does, right? [Ken] What I meant is that HAMR cannot exist without A:M. At its heart, HAMR encapsulates A:M. HAMR cannot be rebuilt without access to the proprietary A:M source code. Wherever HAMR goes, much of A:M goes with it, even though that is invisible to the user. I'm not sure to what extent the 2008 build of HAMR API and tools can read current A:M data files. It depends on what has changed in the data file formats. If the files are still XML, then it may be that new files can still be read and just newer XML tagged objects will be ignored. When I first started parsing A:M files in 2004, this was prior to the XML format and was extremely easily broken. IF... that code were available, would it be feasible to use it to bridge the difference between what A:M assets are and what a game engine typically uses as assets? [Ken] Absolutely anything is possible. HAMR uses A:M code to read and parse A:M data files as well as render the objects. In a game engine you need to read the data files, but the game engine will probably render the objects. With that code, would it be possible to make some adaptation of the game engine so that it could use A:M created assets without needing to convert them to some other format (as is done now) and then the game author would create his game in the normal fashion of that game engine? [Ken] Well, yes, it is possible to read and parse the A:M data files and covert to the game engine native data format on the fly. A conversion still has to take place in memory, even though not neceessarily with an intermediate converted file. This is the part that confuses me. People are already using .X as an intermediate format to get A:M models and animation to a game engine (with some limitations), so I'm wondering why a game engine couldn't be modified to eliminate that .X step and be able to use A:M assets directly. [Ken] When I was doing game engine development work 9 years ago, my game engine could read ..X files as well as A:M files. So yes, a game engine importer could be written to read A:M data files and convert on the fly to the game engine native format. There are problems with this based on my own work of 9 years ago. It is very difficult to fully and reliably parse the A:M data files without the A:M code. You end up having to recreate major portions of the A:M code which already knows how to parse the files. There is also the problem that A:M is cubic spline patch based and game engines are almost universally polygon mesh based. The game engine does not natively have the data object representations needed to do cubic spline patches. Assuming you write an A:M model file parser, you would then have to write a patch splitter and renderer within the game engine. This is all feasible but very difficult to get all working correctly. I've always created procedural models, both in A:M/HAMR and in Unity. Procedural meshes are pretty easy to construct on the fly. What am I missing? [Ken] Nothing. It is a feasible task but extremely difficult. I would love to have cubic spline patch models inside of the Unity game engine. The low patch count containing high resolution information supporting extremely high density poly tesselation would be the big appeal to me. All of the Maya models I have are all relatively high poly counts to begin with. Only then can things like DX11 tesselation shaders be used to take the poly density even higher. The A:M patch based models were great for WebHAMR. The models were very small to send over the web, even though I went ahead and compressed them anyway, mostly so that I could package up a lot of text files in a single binary zip file.
  5. I'm not dead yet! Hey guys, I ran across this forum thread while doing a Google vanity search today:) . It was fun to read all of your comments and thoughs about HAMR and I was amazed that my work is still being talked about in the A:M community. I thought I might share my thoughts on this topic as otherwise, there may not be anyone who fully understands what I did with HAMR. I worked on the HAMR code from December 2004 until April of 2008. I went to work at Texas Tech University as the director of the 3D Animation Lab in February of 2008, so my last HAMR release was done after I had left Hash Inc. In addition to HAMR and WebHAMR, I also produced MetaHAMR which was a Second Life type of metaverse based on HAMR. This was all the pinnacle of my 10 year stretch of doing game engine development. What I did was essentially turn A:M into a scriptable game engine with an API. HAMR cannot be separated from A:M. Basically what I did as a first step was to encapsulate all of the A:M realtime code into a DLL and re-expose the A:M plugin API through the HAMR API. I would actually complle the bulk of HAMR directly from the A:M source code base. I did add a lot of game engine type capabilities as well as embedded Python and extended Python so that HAMR could be scripted. But, most of my work with the HAMRViewer, webHAMR and MetaHAMR was done in C++ using the HAMR API. WebHAMR typically made use of Javascript scripts, but it could have been any web based OO scripting language used. No signigicant amount of code was done in Javascript. The MetaHAMR system infrastructure was based on PHP and MySQL on a web server running UDP messaging between mataverse clients. I also added capabilities to the HAMR API that were separate from A:M for doing game world and character management. And I did a lot with dynamic adaptive patch subdivisions. So, could HAMR be resurrected? Anything is possible, but I think this is unlikely. It cannot be resurrected without being compiled with the current A:M code base. Some parts of the API were very tedious to produce and involved COM and ATL automation and horrible parsers and encapsulating reformatters for the plugin API port. Having not been involved in A:M development since early 2008, I have no idea if A:M would currently build against the A:M code base. I still bemoan the fact that there is no viable tool like HAMR out there. I have tried many things since 2008 but have never managed to come close to the ability I had with HAMR. My current work is all focused on the Unity game engine. Within the last year I did a HAMR-like character interaction event engine in Unity via C# scripting. I as able to approximate the quality of A:M smooth surfaces by using a DX11 tesselation sub-division shader. But, I am at the mercy of the character modeller as to what I can tie into for events. Typically my character models come from Maya or 3ds Max. I am not a modeller, so, my capabilities in realtime interactive systems suffer. I would love to be able to read in a A:M model file and do my thing in Unity, but that is not very feasible. It takes something like HAMR to be able to parse A:M files in a compatibility guaranteed manner. And it takes A:M code to do the patch splitting. When I first began working with A:M, I was doing game engine development and wanted to use A:M as my defacto modelling standard. I read A:M files directly and used the plugin API to do some things, but I had to do almost everything myself, including cubic spline patch splitting. I did it well enough that Martin Hash hired me to do WebHAMR, but I could not not come close to HAMR capabilities without directly invoking the A:M code. These days my focus in Unity is with CUDA and DirectCompute GPU parallel computing. Most of my work is involved in simulating the human hippocampus and displaying parametric results in the Unity 3D engine. I also am an Oculus Rift developer and virtual and augmented reality are my true passions. It is easy to output Unity games to most any platform. Unity has a nice browser plugin that is very similar to WebHAMR, but will not do DX11! Anyway, it was fun to see that the work I did 6-9 years ago is still relevant today. I'm glad you all liked what I did. I was proud of HAMR! Good to see all of your familiar names! Regards, Ken Chaffin- Director, Texas Tech University Media Lab
×
×
  • Create New...