This should help out some poor b**tard like me... I installed Parallels today to give it a spin because I heard that you can now run a virtual machine directly off your Boot Camp partition (ergo I can run pure Windows like I need to in order to properly test software, and I can run the very same partition as a virtual machine in OSX.)
Well, as usual, I ran into some hiccups; however, this time the hiccups were from something I'd done (but still shouldn't have been hiccups really.
For some reason, when I tried to get Parallels to use my Boot Camp partition, I was getting a 'cannot configure the boot camp partition' error and when I looked at the details I received a very mysterious PRL_ERR_DISK_GPT_MBR_NOT_EQUAL error.
Looking at this error suggests there some sort of problem with the GPT and the MBR (if you don't know what these are you aren't ready for this post, wikipedia is your friend) where something was not what someone expected.
Well, I know that after creating my Boot Camp partition in OSX that I'd messed around with that partition space in Windows 7 to create and extended partition by shrinking the Boot Camp partition. OSX didn't seem to care about this and was quite happy to mount the partitions for read only access. Well, it turns out that Parallels cares about this a lot and when it looks at the GPT to see what the MBR should be it throws up because the GPT states that the end of the Boot Camp partition is something it is not.
Sooooo... Long story short, it turns out I'm lucky that I'm using reFIT to handle my multi-boot system because when reFIT starts up you can run a little utility called gptsync (choose 'run partition tool' from the reFIT boot menu) which apparently will square up what is stated in the GPT with what is stated in the MBR (technically it modifies the MBR so be careful.)
BTW, gptsync doesn't handle extended partitions so I had to move all of that data onto the main Boot Camp partition and delete the partition then re-extend the Boot Camp partition over that space so it resembled what OSX remembered from earlier - then I could run gptsync.
Booting OSX and running Parallels at this point worked fine. As an aside, I was wondering if this was a Parallels limitation but it turned out to be a problem (again with virtually no intelligent description) for VMWare's Fusion 3.1 as well.
Hope this helps somebody! :)
UPDATE: Don't forget, both in VMWare Fusion and Parallels, to delete any previous virtual machine you had tried to make using that Boot Camp partition because it has erroneous GPT data - start with a fresh virtual machine.
Thursday, February 24, 2011
Parallels and PRL_ERR_DISK_GPT_MBR_NOT_EQUAL
Posted by
Hans
3
comments
Labels: Boot Camp, gptsync, OSX, Parallels, reFIT, VMWare Fusion
Saturday, February 19, 2011
Home and End keys in most editors for OSX
http://www.starryhope.com/tech/apple/2006/keyfixer/
God bless that guy, I really didn't want to create a custom keybinding dictionary. Works for my Ergonomic 7000. 'Nuff said.
Posted by
Hans
0
comments
Labels: Apple, key bindings, keyboard, OSX
Wednesday, February 16, 2011
If your non-Apple keyboard won't eject using F12...
...make sure that if your keyboard preferences (either in Apple's preferences or a preference list created by keyboard install software on your machine) offer a keyboard type of 'Generic', try setting it to this value.
My new Microsoft Ergonomic 7000 Wireless was set to ANSI for some reason after installation of the software on OSX and F12 would bring up dashboard (like it should) but would not trigger the open/close tray command when depressed longer (as it was supposed to.)
Switching the setting from 'Ansi' to 'Generic' solved this for me (for this keyboard the value was under 'Options' in the system preferences->Microsoft Keyboard.)
Hope this helps someone someday :).
Posted by
Hans
0
comments
Monday, February 7, 2011
Bought a new crApple Mac Pro for work...
...the other day.
Un-freaking-beleivable how ridiculously stupidly overpriced the thing is. Oh, don't get me wrong, it's sexy, sleek, and oh so very shiny with 12 cores, and multiple terabytes of drives (et cetera); but, how on earth are there people so stupid that they actually buy memory from crApple? 24GB of memory (you start with 6GB) from Apple is more than $2100. You can buy 24GB from Crucial for about $420 and then you get to keep 2 of the 1GB sticks that crApple gives you by default for a total of 26GB, plus you get save $1700 (think of all the iPads, iPhones, iPods, iTouches, iWhatevers you could buy with that.)
I love the Woz, hate the Jobs...
Posted by
Hans
0
comments
Monday, November 29, 2010
COLLADA rant
Ok, having added OgreXML support, and our own personal skeletal animation file format support, I decided to add COLLADA support to our skeletal animation system because art puke types are always talking about how great it is.
Now, COLLADA is a good idea that has been horribly HORRIBLY implemented. It is the very definition of needlessly complex and convoluted, the documentation is absolutely terrible, and to top it off, none of the exporters actually support the spec - only parts of it AND THEY SUPPORT IT DIFFERENTLY DEPENDING UPON THE TOOL USED. WTF? LOL.
Anyhow, I stumbled upon a real doozy this past week when supporting the 'library_animations' element. I came across a sample file with baked matrices (meaning that the rotations/translations/scales/et al. were all baked down into representation by a single matrix) that did something so bizarre I couldn't understand it for about 4 hours even though it was staring me in the face and even then I said "it can't be... It just can't be." Oh, but I was wrong, it was.
Apparently, COLLADA allows (and some exporters do this) animation data for a given set of keyframes to be exported not just as a giant clump of keyframes (all animations globbed together) but stored on an individual matrix element basis. I know, sound confusing/bizarre and you probably don't know what I mean by that so I will try to explain since I don't know a very concise way of explaining something that strikes me as so batsh*t crazy that I cannot fathom how some ultramaroon implemented this or though it was a good idea (maybe someone can enlighten me on this...)
What I mean is that even though COLLADA can already bizarrely store all animations lumped together as disassociated keyframes on a per bone basis (strange but I can understand why they might want to do this) storing a set of 16 floats per keyframe (representing a 4x4 matrix) - there is another format to the storage of this data that creates a child XML node FOR EVERY ELEMENT OF THAT 4X4 MATRIX AND STORES EACH KEYFRAMES VALUE FOR THAT PARTICULAR ELEMENT IN A FLOAT ARRAY.
If that still isn't clear (and probably wouldn't be for me because I'd be thinking - "no way, I'm not reading that correctly..." - I mean there's an actual XML element under:
<library_animations>
<animation id="MySkeleton_Root">
<source id="MySkeleton_transform_0__0_-output">
If the file has, say, 600 keyframes of animation in it, there will be (no sh*t) 600 floats in a float array under that source ID that are meant to be stuff in 600 different 4x4 matrices in the position MyMatrix[0][0]...
It strikes me as absolutely crazy as a loon to see 16 entries under a given bone with each entry holding a huge float array representing an individual element of a 4x4 matrix. WTF?
Why, for the love of all things holy and good, would you not simply store the damn thing as a float array of 16 * 600 floats under a single element? The matrix is baked - you can't extrapolate the original DCC toolset translations and orientations (although you can pull translations and orientations out you have no idea whether they're the exact ones used by the tool to generate the matrix) so WTF?
Sorry, that was just the cherry on the cake of my dealings with COLLADA, the amazing file format that seems to be dying a slow death at the hands of Khronos (who I like, but man is this a weird thing they've got here.)
*** END OF RANT ***
Posted by
Hans
0
comments
Thursday, September 30, 2010
It is ridiculous that there seem to be no reasonable explanations of skeletal animation
...and that includes in books (there's a book devoted to it but it's a little horky [props to Nathan for the word], and the only other book I've seen on the topic depends on DirectX code to handle many things.)
I'm going to put one up on this blog shortly as I ran into someone looking for this information and I was shocked to find that Googling was not very helpful as there are bits and pieces of the information all over the place. It would be very helpful, I presume, for someone to post everything you really need to do from importing file formats (I'll probably explain OgreXML and maybe Collada as well), to blending vertex and skeletal animation, to skinning.
I know I wish someone had done that for me back in 1999. Hopefully I'll get it up this year. Probably a short series of posts starting with the background, the terminology (lots of terms for the same things [i.e. Bind Pose/Reference Pose, Palette Matrix/Inverse Model Space Matrix, et cetera...]
It will all be CPU based skinning so that it applies potentially to any language. Hmmm... I wonder if anyone has ever put a skeletal animation system in Flash before (I hate ActionScript/Flash programming, but that might be interesting.)
Posted by
Hans
0
comments
Labels: 3D, animation, bones, skeletal animation, skinning
Wednesday, March 10, 2010
Nerd score...
It's certainly obvious how to game this thing but an honest evaluation led to:
I'm nerdier than I thought...
Posted by
Hans
0
comments
Labels: nerdilicous