Spheriosity Alpha 3 Released!

January 13, 2009

Today I finally managed to release the next instalment of Spheriosity. For those who don’t know Spheriosity is the Java program I wrote to be an emulation of spherical geometry and it is geared toward students in higher geometry classes or anyone interested in learning about spherical geometry. The latest release has many new features. Here are a few of them:

  • Midpoint plotting
  • Ability to draw spherical circles
  • Improved line length measurement tools
  • Ability to rename points

To give it a try head on over to our SourceForge page and download away. Spheriosity requires Java3D >= 1.4 and Java >= 1.5 . For those interested in hearing more about the latest release then keep reading.

The reason that I decided to release it as alpha is because I think there are still too many features I would like to add to the next version. Also, I have been reading about XML lately and think I might change the file format over to use an XML based one for saving spheres. Changing to XML will probably not be terribly difficult, but it does involve my needing to actually do it and then write some acompanying tests. More importantly it will, yet again, break backwards compatibility with file reading.

Hopefully, the next version I release can be beta quality. Also, I am still looking for people who would be interested in helping with development. It would be great to have other people to bounce ideas off of and check the code out to make sure there are as few errors as possible. Additionally, I don’t always have time to work on the project and getting a few more people would help it have some more consistent development.

At any rate I hope everyone enjoys the latest release and if you have any feedback please let me know either via this blog or the Spheriosity SourceForge page. Thanks!

Advertisements

Spheriosity and Ant Build Files

August 18, 2008

While I was on vacation a few weeks ago I decided that I wanted all of the code in Spheriosity to look pretty inside an 80 character emacs buffer. I started out coding it in Eclipse (reluctantly) because it was the only way I could get the Java3D stuff to compile and I didn’t have time to play around with getting it to work command line. I planned to still use Eclipse even after the 80 character conversion, but alas the code does not like right in Eclipse anymore. So I decided to bite the bullet and start coding in emacs again.

This meant that I had to have a way to build the code from the command line so, naturally, I turned to ant since that seems to be the ‘Java way’ to compile projects larger than Hello World. I have very mixed feelings about Ant which is most of the reason for my post. The XML configuration does not do much for me. I don’t like the way XML config files (especially the way Ant does it) look. They all seem to be too syntax heavy for what they are trying to do. Prior to using Ant I had used make, which now that I have used Ant, I like even more than I did before. The simplicity of make is enough in itself to make (no pun intended) me want to use it. I want this project to be open source, and easy to build so I needed to use Ant. After messing around with things I was able to get Ant to do what I want well enough, but it seemed a lot harder than it needed to be. Maybe it is just because I am not used to it *shrugs*

Another thing about Ant which upset me is how long it takes to simply start running a target. I have had it take up to a second or two just to run a target that deletes the built source code. I could have typed in the remove command in that amount of time (with the aid of tab completion). This may sound like a trivial matter… a few second here or there, what’s the big deal? Well, when I am testing either the build script itself or parts of the code those few seconds for each recompile or clean or whatever start to take up a substantial amount of time.

Maybe I am judging it prematurely. Only time will tell. I will continue to use it and perhaps it will grow on me πŸ™‚ .


Is C++ an Elitist Language?

August 9, 2008

Recently I made a post about some things in Java that I find to be a bit of an issue. The artcle was reposted on Javalobby and it started an interesting discussion in the comments section. Among other things, one comment in particular struck me as disconcerting:

When you use a language you should ask yourself what is the feeling of it. C++ is an elitist language with strong roots in the procedural C (that should compile in C++), and a big focus on performance. JavaΒ  is a full Object Oriented langage inspired mainly by C++ and smalltalk, which was for a long time pretty slow, and focus on writing big maintainable programs via simplicity and strong typing. ( A comment by Raphael_Lemaire @ http://java.dzone.com/articles/sometimes-java-makes-me-sad )

Specifically the part about C++ being elitist. Now, I love C++, so of course I am biased. However, I never thought of it as being elitist. The funny thing is that the syntax of C++ is very close to that of Java, does that mean Java is elitist? As far as I see it the real difference is that Java: offers you loads of libraries, memory management, and it allows the coder to not have to think about pointers. Lets look at each of these issues.

The first issue, of libraries, I don’t really consider much of an issue. Especially if you use open source libraries there are hundreds of libraries which are readily available. Certainly the Java libraries are nice, and most, if not all, are guaranteed to be cross platform. However, many of the C++ ones are as well so I also consider that argument to be a moot point. The fact that you have to compile them for eachΒ  different platform can be a problem at times, but I consider it a minor problem especially given the speed of modern computers.

The second issue of memory management is something that goes to Java’s favor. I think, however, that it is a minor issue in the scheme of things. Once you understand the basic idea of memory management, and as long as you use a good programming style which favors allocating and freeing memory in the same place, this isn’t as big of a deal. I have written that you can leak memory in Java too, so Java is not free of this nuisance either! Therefore Java coders who think that are impervious to problems with memory are just kidding themselves.

Third is the fact that in Java you don’t deal with pointers. Or, rather, you don’t have to think about them even though you deal with them all the time. This is more personal opinion than anything, but I never found pointers to be that difficult of a thing to deal with. Once you get an understanding of them it’s really a trivial matter. I know that some people make a fuss because you have to always be thinking ‘is this a pointer to an object, or the object’, but that consideration has never slowed me down. You make note of it once and then it stays the same throughout.

So what is it about C++ that makes it elitist? Is it the people that write code so convoluted that only an experienced pro can read it? I think this could be a big part of it. No matter what language you use people can always write unnecessarily confusing code. Languages like Java try to help prevent this, but I’m sure it can still be done. Having access to pointers can lead to code that is difficult to read, but I think the problem there has more to do with the coders than the language. Programmers should be wise enough to write readable code, and not blame the language.

Do you blame English when you can’t spell a word? I mean… silent letters, what is up with that? No, you probably blame yourself for not having put in enough time to learn the proper spelling. So why should we blame C++ for people that write obfuscated code? At the end of the day it all comes down to the coder, and whether they want to write good code or not.

The bottom line is that I don’t consider C++ an elitist language,Β  but rather a language that with some extra consideration can be just as easy to code in as Java.


Sometimes Java Makes Me Sad

August 1, 2008

On any given day I go back and forth as to whether I truly like Java as a language or not. On one hand the automatic memory management is really quite nice. However it has it’s downsides. Normally I find little quirks of the language that I really wish it had. First off, Java does not have unsigned integers. Now, this is not a true tragedy, and one can work around this by using long integers and bit operations. However that is normally too much work when one is just looking for a safer type.

Another downfall of Java is the pointer hiding. There are times when I really really want to be able to see exactly what is going on. (Yes I know every object is technically a pointer) There is one place in particular this has come to annoy me. I was trying to have a function change the value of an int. This would be quite easy in C or C++, but in Java it is rather tricky. Since you can’t pass the int as reference (Java only has pass by value) and the Integer class is Immutable. One hack I found was to declare an int array with a single element and pass that to the function:

public class TesterClass
{
    public static void main(String args[])
    {
     int[] fooArray = new int[1];

     fooArray[0] = 42;

     System.out.println("My val == " + fooArray[0]);
     myFunc(fooArray);
     System.out.println("My val == " + fooArray[0]);
    }

    public static void myFunc(int[] changeMe)
    {
     changeMe[0] = 12345;
    }

}

Which brings me to my next topic… why is the Integer class immutable!? Say I have the Integer class inside an ArrayList. Well I can’t simply change the value of that Integer. Why? Well because the creators of Java feel the Integer class should be immutable. To me, this makes no sense at all. Yes, I could simply make my own Integer class which allows for changing the underlying value, but why should I? Isn’t this a basic feature that it should have?! It could just have a .setValue() function. Simple! In my mind this makes using the primitive wrappers inside an ArrayList rather useless because you’d have to remove and insert them all the time if you have to change their values. Now, perhaps this is how the creators of Java wanted it. I suppose I will never know.

Overall I do like Java as a language, but sometimes I get discouraged by the potential issues of speed loss, and by some of the things I mentioned above. The control C++ gives the coder is hard to give up, and for now C++ will remain my favorite language πŸ™‚


Java and Memory — Yes, it Can Leak

July 29, 2008

Note: I had previously posted this on my SourceForge Diary on 6-18-08 , but after two posts to the diary I decided the blog was a better place :).

I have been keeping up work on Spheriosity lately as I have devoted my summer to it. Normally I spent around 7 or 8 hours a day writing code for it. Then on the weekend I try to give myself a bit of a break from staring at the computer screen πŸ˜‰

Before I get in to the main point of this entry I will just list a few things I have done with Spheriosity recently:

  • Added the ability to place a point on a line
  • Moved the move point button to the draw section
  • Wrote unit tests for the new code (putting a point on a line)
  • Added a little information section to the bottom of the window which displays area, radius, etc.Β  so the user has some idea what is going on

There are other small changes and if you really want you can investigate the CVS logs. When I release the next version (hopefully the end of the month) I will introduce a changelog file where I will try to sum up all the new features! As a simple FYI the next feature I plan to work on is parallel transport πŸ™‚Β  I can’t wait to get this implemented, but I do not think this will be any trivial task so please be patient with me as I work on this.

Anyway the reason I started this journal entry was because I just found a huge memory leak today in Spheriosity. A memory leak!? In Java!? YES! You CAN have memory leaks in Java. This realization hit me pretty hard today when I found out that I was wasting a lot of memory. Before today I had let the lore of Java convince me it was impossible to have memory leaks, but it’s true… you CAN have them.

How is this possible you ask? Well it has to do with how garbage collection works. Yes, in the traditional sense of C/C++ you can not have a memory leak where you personally forget to deallocate a chuck of memory. This still does not explain what I mean by memory leak though. I am talking about what happens when you hold on to a reference of an object long after it is needed. This happens very easily with private class variables and static variables. Lets talk a bit about garbage collection:

(This is simplified and I am sure the Java garbage collector is far from trivial, but I will simply explain what I know) In a nut shell the garbage collector knows it’s time to get rid of an object when there are no more references to it in code. So if you are storing an object in a private class variable and no longer need it you should set that variable to null. Especially if the class is going to be around for most of the life of the program. This is quite plausible with things such as user interfaces. It is also worth mentioning that you can think of this as a tree like structure. If you stop referencing a class at the top of the tree the entire branch will be collected as long as the only references to the sub objects occur within that branch.

In Spheriosity the problem I had was that after a user selected ‘New’ to clear the sphere I simply removed the highest node in the scene graph from the scene graph and did not clear all of the objects out of it. This caused everything in the frontend and backend to be kept around! All it took was a single line to clear out the scene graph. There were issues where I would get rid of some frontend objects but it was still an observer to something in the backend. As such the garbage collector would never collect it.

Now that I have learned all of this I will be extremely careful to avoid any future memory leaks. I am also going to be more careful when I explain memory management in java to people. I hear people say all the time that it is so amazing and they make it sound completely fail proof, but that is NOT the truth. You still need to be careful with how you manage memory. There is an entirely separate issue here known as heap smashing and in short it is caused by calling ‘new’ too much and forcing the garbage collector to work overtime! This is a conversation for another day, however.

I hope that I have enlightened at least one person about some of the pitfalls of Java. I still like the language and the library support is awesome. However I will never again say the memory management is easier than C++. The reality is that you have to be just as careful! Why do I care so much about memory usage? Well, I don’t like programs that are memory hogs so I try to create ones that don’t hog memory in their own right.

Sometimes I start to think Java itself is a memory hog by default because of the virtual machine and I do get concerned about that. However, without Java3D Spheriosity wouldn’t be anything that amazing so for now I will be sticking with Java πŸ™‚

PS: The cross platform support is nice too πŸ˜€


Java3D, the PickRay, and the PickCylinderRay

July 14, 2008

Today I was struggling to figure out why I could not highlight a line segment in Spheriosity. After much fiddling around I discovered that the problem only occurred when I was using a PickRay to select objects instead of my normal PickCanvas. For those that don’t know a PickCanvas is made to pick objects based on the x and y coordinates of the cursor and a PickRay has to be defined with a starting point and vector indicating its direction. I was a bit disappointed because I thought I had already solved this problem. The general problem here is: ‘How do I take the cursor location and select something in a Java3D BranchGroup?’

My final solution to this problem was to use a PickCylinderRay, which defines an infinite cylinder going in a defined direction from a defined starting point and with a defined radius. Switching to the PickCylinderRay actually solved more than one of my problems. Previously when I was using the PickCanvas I found it very difficult to select objects at times. Especially the line segments (LineStripArrays) . I know that you can set different tolerances to the PickCanvas but I was having a heck of a time getting that happy. The only problem I ran in to with the PickCylinderRay was that if the radius was too large it would pick objects that weren’t even close to the cursor. However, this makes sense πŸ™‚ Here is what the code looks like to define the vector from the camera to the cursor:

public void getCameraToMouseVec(Canvas3D myCanvas, Point clickPos,
                                Point3d cameraPoint, Vector3d dir)
{
     Point3d mousePos = new Point3d();

     //Getting current mouse and camera locations
     myCanvas.getPixelLocationInImagePlate(clickPos.x, clickPos.y, mousePos);
     myCanvas.getCenterEyeInImagePlate(cameraPoint);

     //This block of code converts our image plate coordinates out to virtual world coordinates because
     //that's ultimately what we care about.
     Transform3D motion = new Transform3D();
     myCanvas.getImagePlateToVworld(motion);

     //We do this convertion for both the camera and for the mouse position.
     motion.transform(mousePos);
     motion.transform(cameraPoint);

     //Get the three components of the vector going from the camera location to the eye
     dir.x = (mousePos.x - cameraPoint.x);
     dir.y = (mousePos.y - cameraPoint.y);
     dir.z = (mousePos.z - cameraPoint.z);
}

So after this function completes the variables cameraPoint and dir will be set to the correct values to call .setShapeCylinderRay() of the PickTool class . Here is a sample of the code which takes the output of the previously displayed function and uses it to make a selection:

public void mousePressed(MouseEvent arg0) //Called be Java through MouseListener interface
{
     //In Spheriosity I actually declare these once for the class and reuse them
     Point3d tmpPoint = new Point3d();
     Vector3d tmpVec  = new Vector3d();

     //I assume that 'myMainBranchGroup' is a member of the class that this function is in
     //and is the BranchGrounp we want to be picking from.
     PickTool myPicker = new PickTool(myMainBranchGroup);

     //I also assume that 'myCanvas' is a member of this class
     getCameraToMouseVec(this.myCanvas, arg0.getPoint(), tmpPoint, tmpVec);

     //Use the data gathered from getCameraToMouseVec to make the PickCylinderRay
     myPicker.setShapeCylinderRay(tmpPoint, tmpVec, .1f);

     PickResult result = myPicker.pickClosest();

     ... code to handle what was selected ...
}

There you have it! That is how I solved my little problem with PickRays not working. I’m glad I stumbled upon the original problem because I truly think this solution works much better given the rest of the code base in Spheriosity.

There are a few things to note here. One is that the .1f in the .setShapeCylinderRay() function should be changed depending on your needs (it determines the radius of the cylinder). Lower values mean the cursor has to be closer to the object higher values mean the cursor can be further away. Also the output of the getCameraToMouseVec() function could also be used to define a PickRay if that is truly what you want.

Hopefully this was able to help one or two people trying to select things in Java3D. If not… well at least it serves as a bit of rationale for some of what I have done with Spheriosity πŸ˜€


Spheriosity and Efficiency

July 12, 2008

I spent some time today trying to add, what I think, would be a neat feature in Spheriosity. The feature would let you see the line or circle you are about to create when you are trying to make new lines and circles. Currently you just select the end points and then the program draws the line. With this feature, after you select the first point Spheriosity will show you were the line or circle will end up after you place the second point.

I figured this would be pretty simple and that I wouldn’t run into any of the efficiency issues I constantly worry about. Unfortunately I did… This took me completely by surprise because with the point moving feature everything seems to happen quite smoothly! So it was tough for me to believe that now this feature was slow.

I further inspected the code to find that the difference was in how point moving vs. how this feature was implemented. The way the code is currently structured is that all user related activities are fed through a state machine. The different states are like MovePointState , DrawPointState etc.. Each state extends a base class with 6 or 7 (can’t remember exact number) abstract functions. The class which receives all mouse related events then forwards the appropriate data to the functions of the current. Any given state can ignore functions it does not need by simply implementing them as an empty function block:

public void addPoint(Point3f newPt) {}

The function I currently use to get data from the mouse have the following function headers:

/*
 * @param mouseEvent - MouseEvent sent by Java
 * @param worldLoc   - Pointer location mapped to the surface of the sphere
 */
public void newMouseLoc(MouseEvent mouseEvent, Point3f worldLoc);

Java can give you the new location of the mouse in one of two different ways, but now both at once. By implementing the MouseMotionListener interface there are two functions. mouseDragged and mouseMoved. Even though the mouse is being moved while you are dragging in Java choose to implement it such that only one function or the other is called at once. So both mouseMoved and mouseDragged call my function [newMouseLoc]Β  . In mouseMoved I house the code which determines what lines or points get highlighted depending on the current state. In mouse dragged I simply pass right along the data to newMouseLoc.

So, the MovePointState gets the data from mouseDragged where the only overhead is the calculation I have to do in order to convert the mouse location to the surface of the sphere (quite a large calculation…) Where as in mouseMoved I did the same calculation as in mouseDragged and also did an intersection test with Java3D to see what, if anything, needed to be highlighted. Since part of that intersection test probably involved math that was already done to map the the user click to the sphere… Now… if this calculation was just happening once or twice I’m sure you would never notice. Unfortunately it happens every time the cursor moves. That in itself doesn’t make the the program lag though. Also added to the mix is that to draw each line we really make a bunch of small lines (100 to be exact) because a line on the sphere isn’t the same as the Euclidean version Java3D provides. So now we have that calculation coupled with the code that figures out the end points for the 100 lines and at the very least a for loop with 100 iterations … all each time the cursor moves!

This is why I worry about optimizing Spheriosity. I do my best to keep the code clean, but no one wants to use a slow program.

In terms of a solution to this problem… I moved some of the calculations around so I am doing less math to figure out what to highlight or not, and that seems to solve most of the issues. I still want to optimize it some more as I think I am approaching a dangerous threshold for minimum requirements πŸ™‚ to run the program.