Tech Blog

I just updated Papervision3D to allow the CameraObject3D#unproject method to work when CameraObject3D#useProjectionMatrix = true.

Papervision3D has two methods of ‘projecting’ vectors onto the screen:

1. useProjectionMatrix = false, this is the default ‘fast’ method
2. useProjectionMatrix = true, this is the method where projection is done by a matrix

Note that Papervision3D switches to method #2 in ‘ortho mode’.

So what is the difference exactly between these two kinds of projection? First we need to define what projection is. Projection is what adds ‘perspective’ to a scene and makes sure your scene fits to the viewport. Its the last step in the so-called ‘render pipeline’.

We can derive the ‘fore shortening’ effect of perspective in several ways. Method #1 is simple, effective and fast. It uses the camera’s focus and zoom values. Method #2 uses a more classic way of projection : it uses a dedicated matrix. Tech buffs: very much like OpenGL’s gluPerspective.

Andy Zupko has a great post on unproject using method #1.

We will discuss unproject using method #2, which works slightly different.

The difference is that when #useProjectionMatrix is set to true, then CameraObject3D#unproject returns a point in world-space, rather then a ray. Let me explain with some code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// we want to use a projection matrix
camera.useProjectionMatrix = true;
 
// '0' indicates we want a point on the near plane
var pointOnNearPlane : Number3D = camera.unproject( screenX, screenY, 0 );
 
// '1' indicates we want a point on the far plane
var pointOnFarPlane : Number3D = camera.unproject( screenX, screenY, 1 );
 
// Construct the ray's direction
var dir : Number3D = Number3D.sub( pointOnFarPlane, pointOnNearPlane );
 
// Normalize
dir.normalize();
 
// So, now you have a ray with its origin at 'pointOnNearPlane',
// and direction 'dir'

Optimization: could save some cycles by doing (*not* in ortho mode!, see below):

1
2
3
4
5
6
7

var camPosition : Number3D = new Number3D( camera.x, camera.y, camera.z );
// Construct the ray's direction
var dir : Number3D = Number3D.sub( pointOnFarPlane, camPosition );
// Normalize
dir.normalize();
// So, now you have a ray with its origin at the camera's position
// and direction 'dir'

Why can’t we use above optimization in ortho mode?
In perspective mode all ‘rays’ originate from the camera’s position: the ‘view cone’ has shape of a pyramid. Hence we can assume ‘pointOnNearPlane’ to coincide with the camera’s position.
In ortho mode however the ‘view cone’ has the shape of a cube, all rays are parallel. Hence we need to unproject *two* points to construct our ray.

Now simply follow Andy Zupko ’s post to drag objects around.
Or perform ‘picking’, or…

Update:
Created a little demo to visualize what I’m ranting about, check it out here

This week, request-log-analyzer obtained its 100th watcher on GitHub!

Bart and I have worked hard to make r-l-a a useful product for many people in various situations. The fact that more than 100 people are following the project’s progress and that at this moment, the gem has been download almost 200 times, shows that we are somewhat successful in this regard. Numbers like these, in combination with the e-mail messages we have received, motivate us to keep spending time on the project and keep improving it, even if these improvements are not directly useful for our own projects. It has grown beyond scratching our own itch. 

On a related note, my Flickr photostream recently welcomed its 10,000th visitor.

What started as a convenient utility to backup and share my holiday photos with my family and friends, now has become somewhat of a showcase of what I am about and what I am up to. I would not consider myself a “professional” photographer and I am not an active member of the Flickr community, but still I get feedback on my photographs by visitors, because their visits increase the view counters of my photos.

These counters have really motivated me to make more of an effort when I put photos on Flickr. I started by adding titles, descriptions and tags, so that my photos are easier to find. I also became much more critical of the pictures I upload to Flickr: new uploads have to add something significant to my collection. Analyzing why some pictures got more attention than others made me a better photographer, although there still is a lot of room for improvement.  

Ignite the lazyweb, kick-start a quality improvement loop

What interests me in these examples is that simple counters like watchers on GitHub or views on Flickr can be valuable feedback and can motivate people to put in effort. The end result is quality improvement: write better software, make better pictures, etc.. Even an inherently lazy person like me can get motivated to keep putting in effort and to keep improving myself, because of such a simple feedback loop!

Additionally, it creates a dependence on the website in question. I look at my Flickr stats page every day, and I am subscribed to my activity feed on GitHub to get notified when new people start watching my projects. I now simply have to publish tools I write on GitHub to boost its quality, immediately and in the long run. And I have to upload pictures to Flickr as it is vital for my photography learning curve.

I guess I finally figured out what Web 2.0 is all about! Can we use a similar technique on Floorplanner to boost the quality of the designs our visitors make?

We switched to Git this morning. Before making this switch Gert-Jan (CTO of Floorplanner) asked me: “what is the advantage of Git over Subversion?”. I answered him and thought I’ll make a post of the answer as it can be useful for other bosses like Gert-Jan.

Since we started using Subversion, which was a couple of years ago, using a code versioning tool helped us a lot. We could work on Floorplanner with the whole team together without storing the “repository” on our remote FTP location (early days) or emailing changes up and forth (ancient times ). But when working with Subversion for some time, little things started to bother, i’ll sum them up:

1. We needed tutorials for creating a branch in SVN every time again
2. When merging the branch back, SVN didn’t know where that branch started.
3. When merging the branch back, each change was recorded back as the user who did the merge.

The consequences of these disadvantages.

We avoided creating branches.

Why is not creating branches bad practice?

I’ll give you an example. Sometimes when we were working on some big feature, we didn’t create a branch (it was a lot of work), we just committed it into the trunk when it was “kinda” ready. Then a sudden exception in the software that was online occurred, we now had a problem! That bug had to be fixed NOW, but the changes we just committed into the trunk were not fully tested and couldn’t go online. You understand this was a tedious process and resulted in more downtime sometimes.

But why is Git better?

1. Creating branches in Git is a lot easier than doing this in SVN.
2. Git keeps track where branches come from. So when creating a branch, merging back is very simple.
3. It keeps commit messages intact, when merging.

Conclusion

The whole point, remember this post is called “Git vs SVN for bosses”, branching is a joy in Git and this results in better being able to have access to different versions of the same software at the same time, which again results in being able to fix that bug NOW.

Other resources

http://git.or.cz/gitwiki/GitSvnComparsion

I have been using git for a while now, and I believe I have the the basic workflow under control. Committing, reverting, using local branches for major refactoring work: been there, done that! However, I recently got some collaborators on my github-projects, I had to start working with other remote repositories and branches.

I found this blog post, which was really helpful. I am sharing some others things that helped me in the last couple of weeks. Hopefully, this saves other people some time Googling. If you know a better ways to accomplish these tasks, please let me know!

Things to remember about remote branches

Because I had some troubles discovering how to properly work with remote repositories, I am sharing what I found. The most important things to remember:

• Your local branches are not really connected to the remote branches. It is therefore possible to mix up branches, but this is usually not what you want
• Never forget to switch to the correct local branch (using git checkout local-branch.
• The names of the local and remote do not need to match.
• Before you can push changes from a local branch to a remote branch, all the commits of the remote branch have to be included in your local branch. This can be done using by executing git pull remote-name remote-branch in your local branch.

Checking out a newly created branch in a remote repository

Bart is implementing Merb log parsing for request-log-analyzer. He has put his progress in a separate branch of the github project. My local repository does not yet include this branch, but I want to check it out. Note that I am using a different name than the branch name on the github project.

$ git branch merb origin/generic_base
$ git checkout merb

When the new functionality is finished, the following commands will merge the changes in the merb branch to the master branch.

  # goto my local master branch and merge the merb-branch
$ git checkout master
$ git merge merb
 
  # push the changes to the master branch on github
$ git push origin master

Merging back a fork

Wes Hays is helping me out on the scoped_search plugin. He implemented OR in the query language in his own fork. I wanted to merge his changes back to master branch:

  # add a reference to the remote repository
$ git remote add gbdev git://github.com/gbdev/scoped_search.git
 
  # create a local branch for the fork to follow a remote branch
$ git branch gbdev-fork gbdev/master
$ git checkout gbdev-fork

Now, my local gbdev-fork branch contains Wes’s code. Because Wes’s repository was forked from my repository, git will know that most of the history of my master branch and gbdev-fork branch is the same.

After some testing, I was ready to include his changes by merging the gbdev-fork branch into my local master branch:

  # go back to my master branch, and merge the changes
$ git checkout master
$ git merge gbdev-fork
  # push the changes to the master branch at hithub
$ git push origin master

Pushing tags to a remote repository

You can create tags locally, but you probably want to send them to the remot repository as well:

  # create a local tag "tagname" with the given message.
$ git tag -a "tagname" -m "message" 
  # send your tags to the remote repository "origin"
$ git push origin --tags

I personally am a fan of the git version control system. The best part of git is its speed, and the simplicity of using local branches.

Local branches are very helpful if you are working on different features at the same time but want to keep them apart. An example: it happens all the time that I am working on some feature and than I have to put my current work aside to work on a high priority issue. Once this issue is solved, I need to commit the changes and usually do a deploy of the web application so that the problem is solved as soon as possible. With Subversion, I sometimes commit files that were part of the unfinished feature I was working on before I started on the high priority issue. If I am not careful and deploy those files, unfinished work will be put into production and this can go horribly wrong, like every page request returning a 500-error of our high traffic site .

Using git, I can put my current work aside easily by using git stash. When I am finished with the high priority issue, I can revert to my previous work with git stash apply.

Another option: branching the project (using git branch feature) if the feature I am working on is invasive and than switch branches for high priority issues using git checkout master. I can go back to the feature branch with git checkout feature, followed by git merge master to merge back the changes I just made in the master branch. Branching and merging is very fast in git and merging is not the PITA like it is in Subversion.

However, our main code repository will probably remain in SVN for now. Luckily for me, I can use git-svn locally to profit from these advantages. I found an informative page on installing and getting started with git-svn on OSX. If you know Subversion, this page is helpful to translate Subversion commandos to their git alternatives.

Today I setup the first version of a RAPIDoc, a Rest API Rails Documentation Generator and we decided to open source this thing, from now on let’s call it RAPIDoc. It is a API code generator for Rails, describing your Rest resources. We we’re looking for a way to fully integrate documentation of our API into the code base, like Rdoc does. Rdoc didn’t suit our needs, cause it has got nothing to do with Rest and resource stuff, so we decided to hack something together and gave it a name: RAPIDoc.

What does it do?
It generates a API controller containing documenation maked up in a special language. It parses controllers you specify, and generates a ApiController with appropriate views for it. This makes it very easy to document a Rest API. For methods you use, and according to ERB templates you specify it generates the views for you. It doesn’t parse your routes.rb, it was not needed for us, but may be a nice extension for it.

Well how is that RAPI doc looking? Put this in front of a Restful method.

1
2
3
4
5
6
7
8
9
10
11

=begin rapidoc
url:: /projects
method:: GET
access:: FREE
return:: [JSON|XML] - some project
param:: page:int - the page
param:: per_page:int - max items per page
 
Get a list of projects. This method uses pagination. If you want to retreive project 1-10 for example:
/projects?page=1&per_page=10.
=end

For each resource you specify, a view is created and it is put into the index.

Opensource
It is available from now on on:

http://code.google.com/p/rapidoc/

If you find it useful and you want to change some things, become a submitter. Ow yeah, just a note: really experimental code

As Facebook is probably the most viral socal application out there, we couldn’t stay behind. We developed for Tjoon a Facebook application, this weekend. This application is like the normal website, but with the extension that you can show your recorded videos to all of your Facebook friends and you can also see what your friends recorded.

As you maybe know, we developed Tjoon as a fun project. You can create split screen videos with it. We hope you will like the new addition to Tjoon, the Facebook Tjoon. Here your can install the Tjoon application.

Groove is an interesting platform to develop for. With 192-bit encryption, robust storage, and an architecture designed from the ground up for all types of networks, Groove does much of the heavy lifting for developers. Being a company with an inquisitive mind, Suite75 regularly works on various prototypes to explore the possibilities of the Groove platform. We are especcially interested the sweetspot that lies between Groove’s private collaboration model and powerful (personal) publishing tools like Weblogs and RSS.

Blogging tools like Radio Userland and Blogger, along with emerging peer-to-peer platforms like Groove, are evolving into relatively easy-to-use frontends – back-ended with sophisticated distributed computing technologies like SOAP interfaces, RSS engines, and P-to-P messaging infrastructures

Below you can find links to some of our Groovy experiments as posted on one of Suite75’s Weblogs :

Public Groovespace Experiment

The Groovelounge

Groove – Radio Interoptool

Groove Acces Point experiments

Groove HTTP Server

Web to Groove

Groovespace Publisher

Groove POP – RSS – SMTP

OPML Export

Suite75 developed Groovetools and custom solutions for the Groove Platform from 2001 to 2005 and played an active role in the global Groove community. In april 2002 we hosted the first worldwide Groove Developer Conference and our Groove Weblog has been one of the best read Groove related websites around.

The Suite75 CADviewer is an useful tool for all Groove users who work with CAD-files. The tool lets you review 2D CAD-drawings alone or realtime with other space members.

When “navigate together” is on, a space-member will see the same drawing as you. When a member zooms or pans the drawing, all other joined members will zoom/pan along in real-time. Collaborative viewing is fast because Groove stores all files locally.
Existing layers can be switched on and off and Xref drawings are supported.

The tool works together with the Groove filestool. It scans all the filestools in that particular Groovespace for compatible visiofiles and displays them in a treeview in the Visioviewertool. By clicking on the files in the treeview you can display the files. By clicking on the navigate together in the tool you have realtime collaborative capabilities for multiple members in the space.

The CADViewer is based on the Suite75 Shared Viewing Framework and offers real-time shared viewing of DWG/DXF files within a Groove Shared Space. This Framework is designed for a variety of viewers to be used within Groove. Any viewer based on this framework will have functionality like:

-Fast and secure standalone or realtime shared file-viewing
-Auto discovery of all viewable files within a Groove Shared Space.
-Save comments to a Discussion Tool
-Print the current view to any printer

The CADViewer was a free tool for Groove 2.5 , promoting the use of Groove within a design process and showcasing the possibilities of solutions provided by Suite75 for the building industry.

UPDATE :The development of the CADviewer tool has stopped and the tool will NOT be updated in the future

Tim Knip’s FlashHyki is a collaborative Wiki based on Flash and Groove. It offers realtime decentralised collaboration without the need of a server. The Hyki doesn’t run in the GrooveClient but in a seperate application created using Flash and Flash Studio Pro. All “cards” are stored in a Groove filestool using Groove WebServices.

The term Hyki was introduced by Ray Ozzie in July 2003

Has anyone yet attempted to create what I guess I’d refer to as a “Hyki” – that is, a character-by-character real-time collaborative (Hydra-like, Groove Text Tool-like) editor with automatic creation of real-time linked sub-documents when CamelCase words are typed, etc. ??

Hugh Pyle immediatly took on the challenge and built a great proof-of-concept which inspired Tim Knip for these explorations on the possibilities of Rich Flashbased tools that can easily work within as well outside the Grooveclient.

Download the FlashHyki here (1.4 Mb).

DISCLAIMER:
- The FlashHyki should never be used in a production environment (ie. where you have any Groove spaces which are important or sensitive). It may have adverse effects. There are no warranties of any kind, and there is no support. Use at your own risk.

SYSTEM REQUIREMENTS:
- Groove 2.5 or higher
- Latest Flash

How does it work?
When you startup the FlashHyki you have to specify Account, Space and a Files Tool using the combo-boxes. On first run the HomePage and a temp-folder are created in the FilesTool you specified. Now just start typing whatever you want, the current page will be saved some seconds after you stop typing. Any words written in ‘CamelCase’ are automatically transformed into hyperlinks. After clicking such a hyperlink a new page is added to the FlashHyki and you will be redirected to this new page.