Friday, December 5, 2014

The Disruptions Get Disrupted: vA3C Hacker now contends with vA3C Hackette

The vA3C Viewer is meant to disrupt the classic closed-source, pay-for-service online 3D model viewers. And it does so quite nicely. But as I pointed out in my previous post, the code was becoming a bit gnarly, so I disrupted the disruption and started vA3C Hacker. It does ( or will one day ) everything vA3C Viewer does but just in a faster, cheaper smarter way.

Then this is week a funny thing happened. I was looking at the code, and I had the thought: well, I code use this stuff myself on a bunch of my projects but I just need a small subset of the hacker tools. And so this how the disruptor of the disruption itself became disrupted and "VA3C Hackette" was born

vA3C Hacker and Hackette are within a few days of being usable/playble. There are a bunch of fun things. The user interface is built using Markdown - with links that call JavaScript functions that are loaded dynamically and/or with tiny bits of HTML from time to time. Because it's so easy, the interface is very chatty. Think of newspaper columns to the left and right of a wide screen.

And tn since Hackette is just a tiny index.html file that you can drop into anywhere on GitHub, the the viewer is multi-cellular - a network or viewing stations.

And a main thing is that if I can't understand things within a few minutes then that thing has to be replaced by something shorter and simpler.

But the really main thing is that the app can begin to do its own marketing. The app really simplifies the process of doing screen captures is working well. Performances that include the camera tweening from location to location with text to speech voice over have been created. I am happy with the idea that vAeC will really help with bulding its own demos.

The thing I am not happy about is this. I can't seem to balance writing and coding. I look at the work of Jeremy Tammik at on The Building Coder and Kean Walmesley at Through The Interface and see two people who can mix coding and writing and a busy schedule all in the same day. Well, maybe one day when I grow up...



Sunday, November 23, 2014

vA3C Hacker R1: A Possible Solution To A Personal Dilemma?

I have been having a lot of fun with vA3C Viewer. It's now up to R7 and it now has a lot of cool features. But I have been having less and less fun with each release. As the script gets bigger and bigger, adding a new feature takes more and more time. Lately it has taken several days to get just to get a thing or two going.

Taking time to add features is normal but it has a dreadful unintended consequence. Coding features over multiple days just about completely annihilates the possibility of writing a post. Your brain is fixated on completing the task. Thinking about a post is a distraction that gets in the way of completing the feature. Most likely the next post will be about the feature you are working on, so it might be easy to just cobble together some thoughts about the current work and get the post out of the way. But you end up coding until bed time and so no post.

One idea would be to write small apps only - apps that get finished in under a day. But that prevents anything of any great power from being accomplished. Any app of any significance has a lot of code - tens of thousands of lines of code.

Well, for the last few days, I have been working on an app that may help solve some of these issues

vA3C Hacker is a breakaway from vA3C viewer in both thought process and coding style.

The HTML home page is 47 lines. All it does is load whatever script it is asked to load. If you don't tell it to load anything, then it just loads a page that informs you of scripts it could load for you.

What I have been doing is writing scripts that 'feed the beast'. Most are just a few dozen lines at most. Projects that were completed in a few hours. It sort of reminds me of the the early versions of WordPress. Then, if you went to login.php or page.php you came upon virtually everything to do with that particular function. You needed to go nowhere else to see or understand what that script did.

This made WordPress very easy to lean and to feel comfortable with. And it's the feeling I am getting with Hacker. Today I added two more features: the ability to drag and drop files into the app and the ability to drag 3D objects around in the 3D space. Both are totally standalone. You could quite easily look at the code of either and add one to your app without the other.

The process I am inventing for myself has probably been invented many times before. I just don't know its name and don't know how to search for it. But eventually I will find these out and, hopefully, report back with even greater understanding and more detail.

The other interesting aspect - and difference with vA3C Viewer - is the intent to stand on the shoulders of giants even more. The Viewer does a very nice job of giving access to a wide variety of content - from dozens of algebraic visualizations to dozens of models of aircraft, Hacker should continue doing this and as well begins to give access to a wide variety of code. Of course, the basis WebGL and Three.js - just like Viewer. But, for example, instead of trying to create a geometry editor, Hacker gives access to zz85's Three.js Inspector.

With a bit of luck, the next few days should see Hacker providing easy access to even more 'shoulders of giants'. But the real proof of the potential of the Hacker way of doing things will be the production of blog posts. The more posts you you see the more the efficacy of the system will be demonstrated.



Sunday, August 3, 2014

vAEC Viewer R4: Permalinks Provide Fast Easy Free Ways To Source and Save Data Online

vA3C Viewer HTML5 R4

An interesting phenomena of the architecture/engineering/construction (AEC) industry is the very low labor productivity.

And, yet, we all know that in the future buildings will grow, edit and repair at will with the help of robots using 3D printers to generate Lego-like re-definable construction elements and humans to sculpt, paint and decorate the beautiful hand-crafted elements.

So how do we get from that future back to the here and now as quickly as possible?

What Do We Have Now? 

  • Building is not easy. There are codes and laws to follow. Construction techniques and design tools are difficult
  • Building is not cheap. Land, design professionals, developers all take their toll
  • Building is not fast. It takes eleven days to build a Boeing 737 and months to build a house. 

What Do We Want? 

We want every building on the planet under perpetual construction, repair and embellishment - with lots of jobs for everybody. We want to replace the National Registry of Historical Buildings with a registry of hysterical buildings.

More seriously, we want design and management tools where:
  • Stuff happens. Windows open, doors close and stuff happens just like living in the building. You can see every step of the construction. You can see the building aging and see what needs work or replacing. The digital model and the real-world model complement each other. It everything in Sim City, Second Life, WoW and CandC.
  • It just works. Nothing to download. Nothing to install. Nothing to learn.
  • It happens now. Click and it's here. On your computer. On your phone. Whenever, wherever.
Yes, the expensive, specialist apps still need to exist too. Good engineering and good design require professionals with professional tools.

But that should not stop the cheap, fast easy sharing, the give and take of data between everybody in real-time.

And when you think of design that future way, it turns out you can do a lot of what is wanted right now.

So Show Me!

For a whimsical recreation of that desired design future click here: AutoCrapdoodle

Just do it.

Each time you reload, the future changes.

Want more hyperlinks to the future? Here are five of them:

link 1- - Suzanne and Monster Visit the Revit House
link 2 - - Monster and A6 Visit Ms Windy Cloth
link 3 - - Monster Visits Stemkoski Land
link 4 - - Mr Wright and Mr Jeep Visit Mme Tranguloid Trefoil
link 5- - Walt and Lee, Sitting in a Tree

OK. OK. For many of you the above hyperlinks will not work. ( We are looking at you, iPhone users. ) For many more there will be issues. But nonetheless the demos will work for some people somewhere.

Somewhere the future is working today.

Let's describe the technical aspects of what you are ( or could be ) seeing:

Very large data files are sent to you with no effort. Many of the screens are over twenty megabytes in size - way beyond the size you can attach to an email. All arrive within seconds.

There's no server dude or web site manager between you and the data. Nothing to load or download. No sending files into walled gardens.

The files you see are sourced from Three.js, Stemkoski, FGx, Jaanga and vA3C repositories. Five groups with no connection to each other besides their presence on GitHub. GitHub is a place where you can keep data and code at no charge as long as its open source.

The app, the data, the learning curve - all cost cost zilch.

Use your mouse or fingers and you are panning, rotating and zooming. Learning is minimal

All the designs that arrive at your computer are editable. Change materials, move stuff about, throw things out. All doable.

If you like what you see, and you are an old-timey sort of person, you may save your work as a file ( probably huge ) to you local hard disk.

The New New Thing in vA3C Viewer R4

On the other hand you can now save your new creations and edits as permalinks. The permalinks are small and tidy yet they they actually contain all the information required to recreate your design.

For example, the five short links provided above *are* the design. These designs have no other existence or presence outside of those links. The links are the designs.

Of course, once on your screen you could download the design to your hard disk

But also you could create and save and publish your own design. The Permalinks tab even provides you with a link to the Google URL Shortener.

Using these short links you can easily share your designs via email, posts, tweets or texts. Or, with a bit more work, even share live. And if the data is on GitHub all data changes can become part of the design history.

All of the code is open source and written in JavaScript - a very nice language for people who are not and do not want to be computer science professionals but who do want to drive and navigate their own knowledge domain programmatically. In other words, it's written in code you could edit yourself.

All of the 3D work is happening in an iframe, thus it is easy to append to existing code and web pages while still giving you the ability to edit objects and embed custom animations inside the iframe.


Sure there are many issues and bugs in this current revision. And there's a ton more future stuff to be added.

But remember this: George Santayana said "Those who do not learn from history are doomed to repeat it." 

Now you can also say to those AEC laggards:

"It seems that those who do learn from history are also doomed to repeat it. So let's have a go at learning from the future..."

Links to vA3C Viewer R4
vA3C Viewer R4 Live Demo
Read Me with Feature List
Source Code on GitHub

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

Friday, July 25, 2014

vA3C Viewer R3 Update: Now with Save and Open

Three.js Examples - FGx Aircraft - vA3C Grasshopper
The glorious thing about a computer is that it enables you to process data, save that data, and then - later and elsewhere - open that data for re-processing. This saving and opening thing - being such a sacred holy grail of computing - is normally programmed by the very high-priests in the various cults of data-crunchers. Moving that array of pixels on your screen down to very tiny magnetic blips onto the platter that's spinning very fast and from there to a server-farm in, say, Brea, California and from there to an array of pixels on your friend's screen in Poznan, Poland is not self-evident. It's a job best left to people with PhDs, distinguished resumes and first class brain cells.

The vA3C Viewer app that's being worked on is for viewing data files. So saving is not really a thing that viewers need to do. Unfortunately, the ability to move things about and change materials started creeping into the viewer. So now there are different states: Do you want to see that pretty pony in blue? Or in pink?

AlgeSurf PE - Jurgen Meier Equations
Thus a way of registering those states for reuse would be nice. The previous release of the viewer has the ability to create permalinks - text added onto the end of a URL. In turn these were hand--massaged into text files that restores selected states.

The plan was and still is to automate that process for R3. The idea is to provide a 'save' button that would collect all the links to all the models in the display along with their position, rotation and scale and save these into a script file that you can load that recreates what you had on your display when you saved.

vA3C Revit - Three.js Examples

This is a simple and light weight method and very doable. It is not the same thing as going through every item of geometry, finding every face, vertex and the associated materials and shuffling these all into a tidy bundle on your hard disk. This latter activity is for the pros. The former is OK for script kiddies such as your vA3C Viewer team.

Well, upon the morning that had been appropriated to the permalink coding task, it was decided that reviewing Mr.doob's Three.js Editor would be a good thing.

The Editor does *not* have a save feature. It does, however, have a command that reads the data in memory and sends that data as text to a new window where you can review the data.

vA3C Grasshopper - Three.js Examples

And, then, it turns out the HTML5 has the new ability to enable you to save text that's in a window to a file on your hard disk.

Somehow these two thoughts became co-mingled. Code was copied, pasted and cobbled together. A 'Save' button was added to the vA3C Viewer.

FGx Aircraft - Three.js Examples - AlgeSurf PE Jurgen Meier Equations  
And then, the Save button was clicked.

The mental lollipops nearly fell on the floor.

It worked.

vA3C Viewer R3 is now enabled to take all the data that is in the display and write it out to a brand new JSON file. And these files, in turn can be used to create further JSON files.

Of course, it's not perfect. Files with shaders and other exotics don't work. Somethings come in and can be edited and others can't.  But many fun things do work.

The images on this page show assemblies of files from the FGx Aircraft libray, the Jaanga AlgeSurf parametric equations library, the Three.js Examples library and the vA3C JSON files prepared for the AEC Hackathon. It's an assembly of arbitrary colorful fantasies.

So, yes, the computer has the wonderful ability to process data and to save it and reuse it. Unfortunately this does not stop the peeps with loose wing nuts from producing hyper-whimsical images.

Viewer Live Demo
Read Me
Source Code

Tuesday, July 22, 2014

vA3C Viewer: Work-in-progress Update: Digging Deep DOM into 3D Models

Lucy in the Sky with Birds

One of the many joys of JavaScript is its very close-binding to the HTML Document Object Model (DOM.), This enables little people like me to blast out code that is way above their given brain-grade. With very little training, you can quite quickly and easily see what is causing this hiccough or gripe in this code snippet you are cobbling together.The JavaScript console is your friend. Type in the word 'window' or 'document' and a dot or period, click on the pop-up menu items, repeat.

It's a reverse Hansel and Gretel. The dots are like little stones you follow. But instead of taking you home they encourage you to visit new worlds you never knew existed. Yes, debuggers in other languages have similar sorts of capabilities - but since they are not as closely linked to the DOM they mostly good at showing you the garbage you have created and not as good with curated, fun stuff that's out there.

But this is not a language comparison diatribe. This post about accessing 3D models in deep DOM-like fashion.

I have been looking at Mr.doob's 200+ Three.js coding examples for four years. Their display output and their lines of code are becoming etched in my mind. They become fixed pillars as I look back on my development process.

Until yesterday.

Mr.doob's lines of code - and any other code - is as mutable, as real-timable, as DOM-able, as fresh as we want it to be.

So I am bringing in Lucy into Voxel Painter and making her mesh reflect the square in the city of Pisa. I have put Suzanne in the NURBs demo and the Witch of Agnesi cylinder equation in the canvas birds demo.

For sure, I could do this in a CAD program: insert a 'block' into a drawing etc. The difference is that I am not just using the program. I am creating/editing/playing with the program itself at the same time as I use it.

It no longer takes teams of really smart compter science wizards many weeks to add a new feature. You can now bring in all that 3D data into the DOM. You can use the JavaScript Console to guide you into inventing new tricks for that data.  And you can do this before breakfast

Viewer Live Demo
Read Me
Source Code

Sunday, July 20, 2014

vA3C Viewer R3: Processes Data from Multiple GitHub Sources

vA3C Viewer HTML5 R3

The preview in today's post looks a lot like the preview in yesterday's post. But there is a huge difference. Or a tiny difference - depending on your point of view.

The issue is this: The Internet is about nice people sharing data - in a free and unencumbered manner - and about naughty people manipulating data in peculiar ways. And, yes there are other types of peeps as well.

In the early days of the Internet, everybody was nice and it was fun and easy to share. Nowadays it's different. Of note here, are the increasing restrictions on cross origin resource sharing and the increasing demand for a same origin policy. And, yes, apps on servers can bypass many of these restrictions.

The result is that most of the larger resource where you can keep things for free - such as Flickr, Imgur, DropBox, GitHub and many others disable cross origin resource sharing. This means that JavaScript apps running in your browser are stuck with obtaining data from one source at a time. And, yes, there are exceptions.

Thus the situation for a CAD file viewer such as the vA3C viewer has been fairly marginal. The only drawing the app could open were drawings from the same domain it was launched from.

Until today.

The new - still quite broken - R3 of the vAEC Viewer loads the file we built for it at the AEC Hackathon. And it also loads every example file and every 3D model from Mr.doob's Three.js example folders. And it is loading and displaying the 170+ HTML files of math equations from Jaanga Alegesurf.

Not only is the app loading the files but it's also enabling you to mash-up the data from the three sources any way you want. And, yes, it's doing this real-time sharing in a time-honored, secure manner.

What's the trick?

It's easy peasy. Fork the repo on the GitHub server. No need to download a single byte to a local machine. Publish the repo to the GitHub gh-pages branch. Presto now all of its data is available to apps running from your GitHub presence.

What happens when upstream changes? The official method is to create a pull request and merge. But that is bothersome to the upstream party. It's much easier to simply delete your fork and then re-fork.

Oh, but then - as GitHub warns - it can take quite a while for the pages to start appearing. Not to worry. Open for editing any file in the new fork, make any change, save. Presto! Your new gh-pages files appear instantly.

So this is a huge difference in terms of sharing. But what does this mean for GitHub? The GitHub peeps don't really want to go around replicating half-gig repos all over the place. And they don't have to. They use Git after all. A popular repo has many thousands of forks. So for GitHub your new fork - which they set up in a few seconds - is just a few new pointers and diffs. No big deal.

But for you and me this could be a nice big deal. Currently the site links to something like four hundred files. The current goal is to deliver access to, say, a thousand files of at least somewhat meaningful content.

The traditional on-line CAD viewer is closed-sourced, upload to a walled garden, do-what-they-allow-you-to-do place. Perhaps the time has come for an open-source, freely shared, highly programmable computer aided design enhancer.

The current rev is very incomplete and has many broken bits. It does, however, allow you to place Walt Disney's head inside a warped triaxial hexatorus textured with an image of a '53 Cadillac. Welcome to the Matrix.

Viewer Live Demo
Read Me
Source Code

Saturday, July 19, 2014

AlgeSurf Parametric Equations: Math in 3D - fast, pretty and easy

The Breather Surface. Use your pointing device to pan rotate and zoom

Some of of best friends are mathematicians. This does not mean I necessarily like what they do. On the contrary, I find the Euler-derived notation difficult to parse, not easy to remember and not really pretty to look at. And then, say you have equations printed on a piece of paper or even displayed in Wikipedia - such as the Frobenius Endomorphism. Now tap or swipe the equation with your fingers. Nothing happens! People spend hours formatting text that just so it ends up sitting still like this. How lame is that?

Thank goodness there are alternatives. One of may favorites is computerese. Just translate the equation into Java or Python or JavaScript and now the number of people that can read what is going on increases from thousands to millions.

And another really nice way of displaying math is via the computer display. The display above is generated by the latest update to AlgeSurf - called AlgeSurf PE. PE stands for parametric equations.

The code for the above can be see in breather-surface.html. A much refined and enhanced version is available via the new Equation Browser.

This new display technique represents a major shift in direction from the previously released AlgeSurf Marching Cubes Builder and Player, Both the the Marching Cubes and the Parametric equations apps serve the same purpose: to provide access a extensive libraries of well-known equations and allow you to display, edit and enhance these in 3D.

The Marching Cubes app enables you to do this by accepting and parsing text you enter into an input box - and the text being as close as possible to the standard mathematicians way of writing things. A lot of time and coding went into this effort - with the emphasis being on hiding the code from your view as much as possible.

In other word, the Marching Cube app aids and abets you trying to behave like an old-timey mathematician.

The Parametric Equations app, however, is all about *coding* math. There are 170+ equations - all derived from Jurgen Meier's wonderful web site full of math tutorials written in Java. Each equation is presented as a stand alone HTML file. The files are about 75 lines short and contain everything need to load and view the equation in real-time 3D.

You are very much encouraged to open up any of the files, change the equation and see what happens. It's a fast, fun and easy way to get going with exploring.

The thing is that math can hard and complex and very time-consuming as well. For this you have the Equation Browser. This app reads the the HTML files and adds many features to the display of the equations. Features include the following:

  • Reads, parses and displays remote Three.js HTML files
  • Support real-time 3D pan, rotate and zoom
  • Adds access and editing to full complement of materials, reflections, lights, shade and shadows
  • Update geometry parameters in real-time
  • Display wireframe, face & vertex normals
  • Select background colors or gradients
And the list of future wish list enhancements is even longer.

And as important as the new features might be for helping progress math and math apps, there is perhaps an even more important aspect. JavaScript and Three.js are not APIs or apps but they are languages - coming out of infancy and into broad application.  Both the Marching Cubes and Parametric Equations routines are demonstrations that these tools can have highly diverse and profound mathematical application. And when you click them, stuff happens.


AlgeSurf PE Equation Browser
AlgeSurf PE Read Me
AlgeSurf PE Source Code

Wednesday, April 30, 2014

Building Borges' Map, One Line of Three.js at a Time

It's been so long since there's been a post, I don't know where to start.

Well, let's look a the map, Good idea! unFlatLand R10 has been up for weeks:

Jaanga unFlatland

But it's what off the map where it has really been happening. The goal - the quest - keeps getting to be bigger, deeper, wider. Soon the map will be - like  Jorge Luis Borges' map -  even bigger than the territory it covers. And, unlike most computer games, the closer we get the easier it gets. Well, that's how it feels at the moment. Tomorrow may bring desolation and sorrow, but not if we can keep on the same course.

So what's the goal?

A little background first. There are many mapping apps out there. Some are more accurate. Some are prettier. Some are faster. But they are still all maps. Things that get you from point A to B and other old-timey mappish things. Map apps are crap apps.

The goal is to take something like a 3D programming language and make cartography simply part of the language. Want people dancing in the streets? You can have it. Blue whales swimming up the Gulf stream? Good to go. Adventures on Route 66? Be my guest. Let your imagination go free.

At the same time, how about a dose of reality? Google maps shows that the distance Union Square in San Francisco to the Fairmont Hotel is just four blocks. What Google Maps does not show you is the 500 foot height difference between the two places. Ditto the Spanish Steps in Rome. Or the Peak to the Star Ferry in Hong Kong. From space the world may be flat, but we cyclists know it isn't that flat

The goal therefore
  • Make 3D terrain data insanely free, quick and easy to obtain
  • Build code examples that even dummies can understand
  • Go places nobody has been to
But what do these things mean?

There are dozens of 2D map overlays available - all following the Tile Map Service standard. All these overlays are available at no charge as long as you are not greedy and you know the tricks. We need to de-trickify access. We need to show: "Here are the URLs that work."

3D data is also available at no charge. But it's imprisoned up in all manner of unusual places and strange ways. We need to unlock this data. We need to put the data up on GitHub and say "Come 'n get it!"

And we need take a popular beginner code page - Three.js - and show that instead of standing on a PlaneGeometry object you could be standing on New Jersey.

So future posts will talk about the 2D data with eighteen or more levels of zoom that is available from dozens of sources.

The 3D data that covers the entire world - land and water - to a reasonable level of accuracy will be described. For the moment that is '30 seconds' data - which is about a data point vey kilometer.

Wherever there is better data, us it. Currently that mean everywhere on the globe where there is land there is a data point every ninety meters.

And in same places such locations on Europe and the US, it is possible to get down to '1 Second data or a data point every 30 meters.

And as always, the coding examples will all be on GitHub. [And always with some broken links and stuff that got out of date before it was finished. ;-]

And, as always, the code will be the code of the designer. If you understand what 'if' and 'for' and '=' can do in JavaScript then you are good to go. No maps needed...

Friday, February 14, 2014

Very Simple Menu r1

The goal of the code and apps on Jaanga is to be a resource for people who know a lot about something and just a little about programming. A hero around here is Mr.doob. He states it bluntly on his Three.js site when he says:
The aim of the project is to create a lightweight 3D library with a very low level of complexity — in other words, for dummies.
We are at one with this mindset.

If you understand the equal sign, an 'if-then' statement and a 'for i = 0 to  i= 100', then reading the code on Jaanga should be quite straightforward.

Also, you do not need too know much about HTML and CSS.  The JavaScript Document Object Model or DOM is built into every browser and the DOM enables you to create and control every aspect of a web page from JavaScript alone. Thus all the Jaanga apps are 100% JavaScript for dummies.

Why try to simplify things?

It's not about simplifying things, it's about simplifying the programming part of things.

You are an architect or physicist or mathematician. Do you also need to be a wiz at jQuery or rule at Ruby?

No, you do not. And, more bluntly, the more time you spend on devising elegant programming code the less time you are spending on your own discipline.

Have a look at the Very Simple Menu demo and source code. Using just these few lines of code you could actually construct a Content Management System (CMS) that could access thousands of files. [And all of these files can even be hosted for you by GitHub free of charge, but that is another matter.]

As simple as this code is, it's worth remembering that this is just Very Simple Menu R1. Could the code be even simpler or the variables have better names? Could the commenting be more explicit?

R2 should be simpler and yet do more. Why not?

Very Simple Menu Demo
Very Simple Menu Source Code