Bullet SoC - From the trenches

I've spent most of yesterday trying to track down some of the various problems afflicting the simulation system to little avail (as mentioned in an earlier post).

What is becoming apparent is that navigating (and trying to understand) Bullet's API is becoming quite an exercise in itself at times. Through this process, I'm really starting to appreciate the extent that C++ can be used to obfuscate the meaning of or the ability to easily find code to understand it. Furthermore, I still don't think that doxygen/javadoc-like tools are totally up to the task of improving this situation a lot of the time, but serve to introduce their own layers of complexity into the situation (* details to come in a future post when I get around to it).

State of UI Toolkits - Part 1

I'm sure that many people who've attempted to ever set up small-scale and cross-platform UI app will have encountered the inevitable problem of choosing a suitable UI Toolkit to use. And it's not like we don't have many choices either with popular systems such as:

• QT
• wxWidgets
• GTK (and derivatives)
• Java AWT/Swing
• ...

to chose from, though there are many more that also work but which I have not listed here. But this is only the start of the troubles you'll face...

Bullet SoC - Thou (still) can't turn back time...

I've started working on and committing the new C-API for interfacing with Bullet into my branch at last. At the time of writing, I've finally replaced the old API calls with the ones from the new API.

Everything that worked before seems to work still. Also, all the hack to force resetting of simulations now seems to be working, while it didn't before. Yay! (Note: it's still really a hack still, since we should be able to do this by just stopping playback, or jumping back to the 'start frame' for the sim... but at least that should be easy to fix soon).

Unfortunately, despite now using MotionStates, I still can't seem to get reverse playback working (which is necessary for allowing normal 'scrubbing' of the timeline). There is some movement in the right direction, but it only happens once and then stops. This was not the case when I tried doing this in the "Hello World" demo in Bullet srcs. Is it to do with the sizes of the timesteps - i.e. do I need to specify max timesteps/substeps? Or am I screwing up the way the MotionStates update?

If anybody reading this is familiar with Bullet, some suggestions/help on fixing this would be appreciated :)

Bullet SoC - Work continues...

Just a quick note here that I'm currently busily hacking away on the next piece of core architecture necessary to get the Bullet integration more functional. While I haven't been able to work on this much this week, this should be ready in the next few days.

Among the functionality this should enable are:

• properly functioning playback - the extent to which it appeared to work in the videos is a bit of an illusion, but still tempting
• adjustable (and potentially animateable) gravity
• changeable settings (including mass and collision shapes)
• a better framework for dealing with more settings/controls as necessary
• ...

Plus, there will be a few more demo vids too, and maybe a few surprises... we'll see ;)

Anyways, enough talk for now, and more code... over and out.

Exams, Catastrophic Calculation Errors, and Assignments....

This week has been busily spent sitting exams (over halfway there now), studying for exams, and occasionally a short spot of coding.

Today I had another math exam, which I think went quite well... that is, if another bout of 'catastrophic calculation error' didn't plague my script, and (at the time) 'magnificent' answers turned out to be complete and utterly misguided efforts (like some of the attempts at goal in the Soccer World Cup). We can always dream...

Oh, and I finally got back my HCI Assignment - an essay evaluating the "Ribbon" GUI in MsWord - for which I got 100% for! Yeeeehaaarr!

GSoC 2010 Welcome Package

Today I've finally received my GSoC Welcome Package at last!

Quicky snapshot of contents from laptop webcam for convenience, with minor PP to look less crappy.

Photos...

Recently I was sifting through some photos on my computer, and finally decided to upload some of the better shots for the world to see.

These were taken with one of two cameras: a Canon camcorder (the bird photos and some of the lower-res shots) and an Olympus Point and Shoot. I should point out that at this point in time, I'm not particularly satisfied with this set of equipment...

Bullet SoC - Sneak Peek

Disclaimer: This is a very limited proof of concept implementation

With that out of the way, here are some demos that I'm sure you've all been waiting for...

Artifact 1 - Cube controlled by Bullet, and affected by gravity only
http://vimeo.com/12634717

Artifact 2 - Dynamically controlled object (Cube), affected by gravity, falling onto an animation system controlled object (Plane). The plane isn't moving in this instance, but that doesn't mean it can't move...
http://vimeo.com/12634604

Artifact 3 - Animation system controlled moving object affecting physics object. Not quite as impressive as I hoped it to be due to blotched settings, but it gives an idea.
http://vimeo.com/12634991

Bullet SoC - Delays...

Just thought I'd make a little note here about the current status, since I said I'd have an initial prototype "working" by about now ("+/- 1 day").

Well, firstly, the good news:
All the basic components of what I consider necessary to be able to set up a basic sim (as in single cube falling onto a plane, which is as basic as it gets) at least now are now in place! AND it compiles and Blender still starts/works without major issues in general.

Here is the bad news:
As is often to be expected, I ran into a crash trying to set up a sim for the first time. What's the problem then?

1. my usual debugging environment is buggered (as of time I checked a few days ago). That is, scons+mingw was having linking troubles, so no gdb debugs :(
2. it's now after midnight, and it's probably too late to start troubleshooting build problems now and/or debug crashes in an unfamiliar debugger
3. exams are coming up really imminently... as in 3 days time, and for a week ("an exam a day keeps the coding away", a sad variation of a famous saying)... so probably, unless I can fix the problems within 1-2 hours tomorrow morning, we won't be seeing the first prototype in action for another week and a bit at least :(

Oh, I should also mention that I've done a merge to latest stable Bullet (2.76) in my local tree. Had to delete the extern/Bullet2/src folder first to make it work, but other than that, it was just a case of copying over the new folder and compiling. Depending on whether Moguri gets clearance on adding his attempt at the merge to trunk, I might not have to commit this copy, but we'll see :)

Fingers crossed, I might still have a positive update tomorrow with some nice screenies and commits...
Laters!

The dangers of generality...

... and the greener pastures of practicality first

Over recent years, I've found myself often pondering over the ways in which subjects (or las materias) are taught or presented. Why is it that some lecturers can make a subject interesting and above all guide true understanding and insight, while others can make even potentially interesting subjects dull tedium? Though this may not hold for everyone, I'm starting to believe that presentation style has a lot to do with the effectiveness of teaching and learning.

Side rant on merging branches

Having performed merges on branches a few times (during last year's SoC, and also an earlier branch - "branches/animsys2") has not left me with a very favorable impression of this method of version control (in SVN at least. I'm not sure how well some of the distributed systems cope with this in practice, but perhaps it might be a bit better).

In my experience, performing a branch merge using TortoiseSVN + the Blender SVN server is a very dog-slow procedure. It takes upwards of 3 hours a pop, and often with no guarantees of success (either from choosing the wrong revisions, or connection failure halfway when computer goes on standby or otherwise). In contrast, simply updating from trunk or a branch and then saving out patches, gives nice 30 sec to 1 min updates to keep your sources up to date.

Keep in mind too, that these figures were from a year ago. It's now a year later, and the rate of commit activity on Blender's sources has increased (and so have the number of people accessing the server at any given time). Imagine what the merging times are now...


Given these circumstances, would you be wary of merging? ;)

Bullet SoC - Coding begins

Over the past few days, I've started implementing the plans described. So far, it's more as a proof of concept/fleshing out of the design in practice to get a better handle of some of unforeseen problems (i.e. "how can I get Bullet to do this?!"). Or in other words, laying out the framework...

Photo: complex scaffolding at a building site in Hong Kong (near the "Avenue of Stars"). Crop of photo taken during vacations there in April this year.

Bullet SoC - Design Docs (First Version)

Finally, getting into the swing of things after a bit of a slow start with uncooperative coursework requirements, and to meet my self-imposed deadline...

Introducing: Bullet Construction Toolkit Design (version 1.0)

Here are two documents I've prepared detailing various notes/plans...

1. Notes about Bullet and the way it is integrated in other apps
2. First version of design plans for our integration 

Firstly, these documents are still subject to change, as additional requirements are added/removed, and/or issues with the design rectified. 

Anyways, here we go... enjoy!

Google Summer of Code 2010

Firstly, thanks once again to the generous folks out at Google for running this program again this year. (My equipment wishlist and bank account thank you for it... hehehe)

This year I'll be be working on implementing a "simple and natural" (to take a page from Jacob Nielsen's Usability Heuristics) integration of the Bullet Physics Engine into Blender; a "Bullet Construction Toolkit". Some may know that Blender already has partial integration of Bullet, but this is restricted to being another one of the half-baked and clunky Game Engine features.

The main goals here will be to:

• make it quick and easy to set up simple setups
• make complicated setups not require too many additional hoops
• tighter integration into Blender allowing use in combination with Animation System
• visible (and editable) results in Blender, on par with other Physics systems
• visual manipulation of Bullet simulation parameters (potentially including a new API for defining manipulators)
  
• ... and hopefully kick the collective proverbial asses of Cinema4D-MoDynamics/Maya-Dynamica/Houdini in the process

Currently, when I'm not busy finishing off assignments (so much for doing a "Summer" of Code in "Winter") I've been working on getting a nice design for this sorted. More news on that later.

Hasta luego!

Hola!

Here I'll be posting about various topical issues, and also about my current projects in development. In particular: - Blender - dbcskit - Project Hosting on Google Code - physlabtools - Project Hosting on Google Code There may also be the occasional music snippets and rants...