Summary
A quick play around with the Java3D library and Groovy to see how much easier we can make the library to use.

Advertisement

Java 3D Fun with Groovy

If you are anything like me, you were fascinated and enthralled by the great 3D graphics in "Avatar" (and disappointed by the story). Occasionally, when I see graphical achievements like that, I am inspired to download the latest version of Blender, and see if I can render something superb myself. I had a similar moment after watching "Monsters Inc."

I always discover that I can't, because as well as the obvious need to learn the finer details of a very complex world (of translations, textures and shading etc.) it also means being right-brained or creative. Not my speciality.

This time, though, I found myself browsing for 3D images, libraries and tools, and I came across a link on instructables.com explaining how to export data from Blender to Java3D. This sparked my interest and made me wonder how Groovy would work with Java3D, and whether we could get any leverage from it.

I thought I would play with Java3D a bit first, and see if I could create something fun. I was disappointed to find it horrendously complex. Sure, there are an enormous number of parameters that have to be added to a 3D scene, but shouldn't an API help a bit? It really felt like everything had to be done from first principals.

Here is the minimum code you need to show something in Java 3D. I have translated it into Groovy, which in this case, amounted to removing the semi-colons and replacing the types in front of every initialisation with a def statement. Neater than the Java, but no fewer lines.

I ran this quite easily in Eclipse on my Windows 7 machine, after downloading and installing Java3D. I had to add a project reference to the jar files j3dcore.jar, j3dutils.jar and vecmath.jar and under the Java build path in the project properties, I had to choose the library tab, JRE System Library and then add a Native Library Location which pointed to the bin directory of the Java3D install.

I got this:

The results are somewhat underwhelming, mostly because the front face of the cube is coplanar with the viewing plane, and so it just looks like a square.

A lot of work

This also looked like a lot of work for a not very pretty result, and it struck me that creating a new universe and adding a new branchgroup and a new shape and a new transform etc. must be a sequence of operations that is performed again and again, and it should probably much simpler. We could even come up with a simple DSL that would let us do it. Groovy's Builders are perfect for this, and in my next blog, I will talk about how we can make a simple builder that allows us to create graphical graphs with simple, clear, structured syntax. For now, though, I am still on a mission to have some fun with Java3D and Groovy. So how to do this?

More Fun

The little tutorial at http://www.instructables.com/id/Using-Blender-To-Create-Java3D-Models/ described how to download some Blender data, and export it to a Java3D readable data source, using a Python Script. If you don't know Blender, you won't know that its scripting language is Python. This allows immense power and flexibility when creating animations. (Any chance of a Groovy plugin anyone?).

Now I am a real ignoramus when it comes to Blender, but the point was to follow the tutorial and just export the data into Java3D readable format. This wasn't too hard. The tutorial directed me to a sourceforge project at http://sourceforge.net/projects/blend2java/ which allows you to do the conversion. I found it easy enough to work out how to run a Python script in Blender (you need to show the script panel and open a text file) and the result was
two xml files, Skull_Head.000.Skull.Shape3D.xml and Skull_Head.000.Mandible.Shape3D.xml.
get them in a zip file here.

Loading Up the Data

The Java example in the tutorial was somewhat confused, and certainly not minimal. The author, by his own admission was new to Java (and anyway, I wanted it in Groovy) so I rewrote the code, in a somewhat hacky, skull specific way as follows:

Definitely hacky, loading up the two files separately, but the loading of the shapes is very simple using the XMLDecoder class.

It took some experimenting to get the position of the skull in the viewing platform right, but it proved the concept and with the addition of a nice, blue light, it produced another pleasing image, this time in the Java3D window:

By adding the jaw to its own TransformGroup, I was able to move it independently of the head (which is obviously why it was rendered in two parts). The two loops at the end of the code above make the jaw go up and down in a comical "yuk yuk" fashion. Perhaps with work I could render the entire scene from Shakespeare's Hamlet, where Hamlet holds up the skull of Yorick and talks to it.

Nice Result, but..

So, it was certainly fun, and I learnt a lot about transform groups and viewing planes etc. but it seems extraordinarily difficult to create a 3D scene in code. As I said earlier, Groovy has just the mechanism to help, in its "Builders".

org.xml.sax.SAXParseException: XML document structures must start and end within the same entity.Continuing ...Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'float' with class 'java.lang.Class' to class 'javax.media.j3d.Shape3D'

at simple.LoadedShape.loadShape(LoadedShape.groovy:20) at simple.LoadedShape.main(LoadedShape.groovy:26)

"I always discover that I can't, because as well as the obvious need to learn the finer details of a very complex world (of translations, textures and shading etc.)" - I understand it like "Yeah, I don't know a lot about programming within 3D, but the J3D API is overly complicated so let's use Groovy sugar, maybe it will become easier". That's so wrong. The API seems to be complex, but just because the domain itself is complex. Believe it or not. To your "A lot of work" section - I recommend you to construct the universe without utility classes, just to appreciate what has been done for you. Also, you could simply add animation with alpha interpolation if you would just read 1st chapter of J3D tutorial. Byt the way, the whole tutorial - 7 chapters has only about 400 pages.Otherwise, good work. Wish you good luck.

I think the whole thing with right-left-brain, creative or not creative is just annoying especially if it comes from programmers. Programmers are creative! Programming is a very creative activity: You have to find out a way to solve a given problem and you can do it in a thousand different ways.

> >> it also means being right-brained or creative. Not my> speciality. > > I think the whole thing with right-left-brain, creative or> not creative is just annoying especially if it comes from> programmers. Programmers are creative! Programming is a> very creative activity: You have to find out a way to> solve a given problem and you can do it in a thousand> different ways.

I think it is really annoying when people say it is really annoying.

You just frustrate people like me who know how to interpret cutting-edge brain research and genuinely keep uptodate on the latest research in human brain studies.

When you read real academic studies are conducted on the brain, such as fMRI studies that show blood oxygen levels in the brain over a time series, and you understand them, then you can be qualified to be annoyed. Otherwise you are getting worked up over nothing.

Fact: Study after study has shown some left cortical regions of the brain lights up considerably when given problem solving tasks. This indicates the left-brain plays a strong role in tasks associated with programming. There have even been tasks such as "How do you solve Towers of Hanoi" measured with fMRI, and the answer is approximately: the left-brain does the solving.

Not being "Creative" doesn't mean you are mouth-breathing inbred dolt with the IQ of 45, and it doesn't mean you can't do marvelously wonderful things. It means you are not the person I am about to hire to do some paintings for my apartment, when I have no idea what those paintings should even look like.

> I > understand it like "Yeah, I don't know a lot about> programming within 3D, but the J3D API is overly> complicated so let's use Groovy sugar, maybe it will> become easier". That's so wrong.

That sounds like a less than sympathetic response to the article. The theme of my last two blogs is Groovy's seamless integration with Java and how it can help. This blog is a pre-cursor to the use of builders in Groovy, which are by no means just "sugar". Actually I do know a little bit about 3D programming, having devoted my final year of university to it .. 16 years ago.

> The API seems to be> complex, but just because the domain itself is complex.> Believe it or not. To your "A lot of work" section - I> recommend you to construct the universe without utility> classes, just to appreciate what has been done for you.

I think you miss the point slightly. The domain is complicated, but it really shouldn't be hard to create a simple universe with simple shapes, particularly not as hard as it was 16 years ago. That is the point of a good API. Of course I looked at the tutorial. That is what gave me the idea that it was so hard to do something quite simple. I think one needs to distinguish between a good implementation (like Java 3D) and a good API, which I don't think it is.

> Also, you could simply add animation with alpha> interpolation if you would just read 1st chapter of J3D> tutorial.

Yes, but the example would start to become very complex then. Remember, I am not trying to teach anyone anything about Java3D, merely to point out that we are building a hierarchy of somethign complicated and that there is a really nice way of doing this in Groovy, which I post next. I felt the whole thing would be too long and rambling to post in one go. Also, I thought the translation of the 3D data from Blender to Java3D was pretty cool and worth mentioning in a blog.

> Byt the way, the whole tutorial - 7 chapters has> only about 400 pages.yes, it looked like a good tutorial. > Otherwise, good work. Wish you good luck.

> Not being "Creative" doesn't mean you are mouth-breathing> inbred dolt with the IQ of 45, and it doesn't mean you> can't do marvelously wonderful things. It means you are> not the person I am about to hire to do some paintings for> my apartment, when I have no idea what those paintings> should even look like.

I don't know much about the science you refer to but as the product of a seriously left-brained engineer and a seriously right-brained artist with cross-dominance (left-leaning) I feel I know a little about the general topic.

The thing about your argument that disagree with is that you assume that programming is always a problem-solving task. If you are primarily left-brained, this might be why you see it that way.

There is such a thing as 'creative' programmers. These are the programmers that most programmers can't stand. They are the ones can't just do things the 'normal' way and building things that do stuff no one asked for.

IMO, there's also a middle ground. You can be solving problems in completely novel ways. You can also find super-solutions that not only resolve the problem at hand but a whole class of problems.

Jeremy, I do have some feedback for you but I was hoping to wait for Part 2 of your series on your Groovy 3D coding (pun intended).

I've spent a lot of time thinking about good domain specific languages for graphics applications, and line of business applications.

Typically, graphics applications for usual applications try to provide a "page layout synthesis" model by *hiding* pixels from the control of the application developer and replacing it with an *abstraction* that provides *user-defined coordinates*. However, in addition to user-defined coordinates, these applications provide "widgets" that provide: Layout, Input, Focus, and Events (what Microsoft calls LIFE). Taking away one of these gives you an incomplete widget and you now have to write more application code in order to fulfill what was given to you by the widget.

For example, if you take away Layout, then you effectively lose page layout synthesis. However, automated Layout is really a sequencing trick, and whenever a developer uses a widget (an object with automated layout) they lose a degree of freedom in the rotation and transformation of the object's layout. The reason for this is that page layout synthesis object models use a Composite pattern where objects are nested, and the nesting determines a set of constraints that depict to the rendering thread where on the screen to draw the objects. See for example [1] [2]. [1] discusses the motivation for a Logical Tree in WPF [3], and [2] discusses how to ignore the edge cases discussed toward the end of [1], such as how to place a 2D element in 3D space (in Systems Theory, this is a variant of the "N Body Problem" in physics). In a nutshell, the WPF Panel system that provides the widget's API for automated page layout synthesis is based on a 2D coordinate system. The "logical tree" WPF uses is only 2D-logical. That's a conceptual problem that merely using a Builder pattern in Groovy cannot elide. The problem is very bad, because it disallows UX designers from utilizing *real* information visualization techniques like (three-dimensional) focus and perspective. Once you make the move to 3D UIs, things like the Builder pattern matter much less, because a syntactic DSL for the Builder pattern is generally used to indicate "containment-by-hierarchy", and in a 2D graphics app, that containment refers to x and y offsets for nested widgets. This is approximately how some people think of HTML and XAML, even though they shouldn't! In fact, I would argue the feature HTML and XAML offers more than anything else is a linear logic for specifying semantic elements (and viewing your semantic content as encoded in a linear logic means this makes it really easy to convert updating semantic elements into a dataflow graph editing problem); stuff like CSS and WPF styles, etc. should have the *role* of deciding where to put stuff. The problem is nobody tends to be faithful to semantic organization of information, because the complementary stylesheet language usually blows. As a consequence of this, people do things like encode jQuery commands to update the entire DOM at once, because their solution for laying things out and tidying up the picture devolves into spaghetti very quickly...

I think this speaks to the caution somebody else provided in this thread, stating Groovy sugar cannot replace thorough problem domain analysis. I am very curious to exactly why you would think a syntactic DSL for a Builder pattern would be good for a 3D app!

(On the other hand, it is pretty easy to see the allure behind a 2D layout model and never wanting to break out of it, enforcing the 2D layout with a Builder pattern that uses containment-by-hierarchy. It simplifies coordination among objects on a screen. It provides familiar UX metaphors that use 2D layout constraints heavily, such as data grids and business forms.)

Hope that was clear. Sorry for trolling in the earlier half of your blog - I bite on shiny bait, and would not make a good fish.

> I don't know much about the science you refer to but as> the product of a seriously left-brained engineer and a> seriously right-brained artist with cross-dominance> (left-leaning) I feel I know a little about the general> topic.> > The thing about your argument that disagree with is that> you assume that programming is always a problem-solving> task. If you are primarily left-brained, this might be> why you see it that way.> > There is such a thing as 'creative' programmers. These> are the programmers that most programmers can't stand.> They are the ones can't just do things the 'normal' way> y and building things that do stuff no one asked for.

Research in the field of "Design Thinking" actually supports you; there are really two extremes here, too. One if Herb Simon's "The Sciences of the Artificial", which is a classic in design. The other is Nigel Cross's Designerly Ways of Knowing. Cross uses some studies to show that truly great designers tend to actually perceive more constraints on a problem than there actually are, because that enables them to focus and tune various aspects of a model. This is quite different from Simon's view of how we should design systems, and effectively argues Simon's point of view is merely an idealogy and that a great mind like Simon is a shallow idealogue here... because real designers don't do it that way. Real designers don't like blank canvases, because that weakens their analytical abilities.

Marian Petre also has some interesting findings on how experts (literally, the one's with the best analytical abilities) solve problems. Dominantly, they are actually well-versed in many problem solving strategies and tactics, and through accumulating enormous knowledge of "paradigms" (ways of thinking), they can generally apply the best "paradigm" to a given solution.

> IMO, there's also a middle ground. You can be solving> problems in completely novel ways. You can also find> super-solutions that not only resolve the problem at hand> but a whole class of problems.

I think this depends on how you view generalization. If you mean purely mathematical, then I would expect it to be left-brain, analytical. You might think it is highly creative, though, and you might be right. I don't know of any studies that put Ron Rivest in an fMRI machine as he is creating a new cryptography algorithm. What does your brain look like at the moment of brilliance when an apple falls from a tree and you discover gravity, or the bathtub overflows with water and you discover the value of displacement? I don't know.

> I think this depends on how you view generalization. If> you mean purely mathematical, then I would expect it to be> left-brain, analytical.

This is very interesting stuff. I once had a physics professor tell me that my 'intuitive' understanding of physics was one the best he'd seen. I've puzzled over what that means ever since. Even in mathematics, people create new ideas. It doesn't happen very often but one day topology didn't exist and then one day it does. A lot of people think mathematics is inherent to the universe but it's just another invention of man. Art also has a logic to it. There are many artists that I don't consider to be creative. A lot of art is about technical ability. I guess maybe I'm doubting that creativity is really confined to the right side of the brain.

"A lot of art is about technical ability." I'd put it in a bit different way. To fully express yourself, you need to either learn certain techniques or you just use them without knowing about them. The second possibility is more interesting as it makes you think more about how brain's working. Then you start to think about how we learn stuff and that it has probably nothing to do with being left- or right-brained. Watch this http://www.youtube.com/watch?v=50L44hEtVos&feature=related So, is the woman left or right? :) I think it doesn't really matter as long as it doesn't interfere with the way you learn things.