Sunday, July 27, 2014

vA3C Viewer R3 Update ~ 2014-07-27 ~ No More Russian Dolls ( scenes inside scenes inside scenes )

A while ago I decided that the thing I like doing the most, most, most is coding. Yes, there are truthiness issues here, but let's not ruin a good start.

That does not mean, however happiness all the time 24/7. And yesterday was one of those times when the process became loathsome. It started with a equal sign in the wrong place, but not so wrong that it caused a message in the console. So: Look. Not find. Look. Not Find. Repeat. Repeat.

Then I wanted to add some sparkle to the project. A good way to add sparkle is to have a light that follows the camera.

The code in Three.js is easy:

var pointLight = new THREE.PointLight( 0xffffff, 0.5 );
pointLight.position = camera.position;

camera.add( light );

The trick is that you also must add the following:

scene.add( camera );

Normally you don't need to add the camera because scene adds the camera by itself, but in this instance it's necessary to do so because you need to inform the scene that the camera has a new passenger.

Again: Talk to light. It not budge. Plead with camera. It not budge. Finally found the answer on one of West Langley's posts on StackOverflow. And, of course, that brings back all the memories of all the previous times I have confronted the un-budging light. So even worse then the problem was the feeling of having been such a dummie again. 

The darkest moments, however, were brought on by the code itself. One issue about being a cowboy coder, is that you you can code yourself way out into the wilderness and then have trouble getting back.

One of the amazing things about Three.js is that it allows you to embed a scene, withing a scene, within a scene. It's like the Russian dolls that fit inside one another. In Three.js, however, the scenes can all be visible at once and everything co-mingled on stage all at once.

It's easy to do. All you need to say is:

scene1.add( scene2 );

This worked a treat in helping get the vA3C code up and running for the AEC Hackathon, but really started causing problems as in: "Hello, Object, What scene are you in?" "Duh, I dunno" is the usual reply.

Anyway, a lot of the file opening code has been cleaned up - and the Russian dolls have morphed into one doll. You can now open files from the web using links & Ajax or from local your local hard disk using your OS' File Open dialog. Hats off to Mr.doob for loader.js in the Three.js editor.

The only newish feature is that attributes are back in in a rudimentary fashion. When you click on any item that has userData, the attributes appear in the top right corner - as you can see in the image of Jeremy Tammik's Revit House Project above.


On a completely different note I am intrigued by Lawrence Kesteloot's post on Norris Numbers - which starts of with this quote:
My friend Clift Norris has identified a fundamental constant that I call Norris’ number, the average amount of code an untrained programmer can write before he or she hits a wall. Clift estimates this as 1,500 lines. Beyond that the code becomes so tangled that the author cannot debug or modify it without herculean effort.
The gist of the post is that the longer the program the greater the level of skills required to write the program. He closes by wondering aloud if he could achieve a two million line program. (Linux is currently around 15 million lines.) The implication is that it takes smart and clever people to write large programs while smaller programs can be written by less smart people,

Of course, I have full admiration for a person who has written several programs in the 100,000 to 200,000 line range. But on the other hand, I have just as much admiration - and perhaps more - for the programmer who makes magic happen in a 100 lines of code or 10 lines of code.

Similarly, the way I code as a designer differs greatly from the way a programmer codes. (For example, as a risk-taker, I deliberately leave out quotation marks in places most programmers add them.)

The importance is not the length or the shortness of the code, nor is it in the robustness or riskiness of the code but the true benefit derives from the diverse spirits and skills of the people writing the code and their desire and capabilities to share their code - and fully respect each other gifts and talents.

Viewer Live Demo
Read Me
Source Code