I spent the first half of the semester working on GumBeat so I am a recent addition to the Game Engine Team and have spent the last few weeks getting up to speed on Unity and failing to get anywhere with Visual3D.
Lets get the bad news over with first.
Visual3D is great software if you want to drag-and-drop premade skies and dinosaurs onto a scene. Other than that, I don't think it's worth using. The interface is very unintuitive. You can drag and drop premade primitives (and skies and dinosaurs) into a default scene very easily, but it's unclear where to go from there.
I tried simple things like putting a cube and a spotlight in my scene. The cube was super shiny and the spotlight wouldn't cast shadows. Both of them have oodles of options in a handy panel on the right but when I tried to change the default values for say, the range of the light, it snapped back to the default value. Unless I could figure out how to edit it graphically in the scene view, nothing happened.
The documentation for Visual3D is outdated and spotty. They have an old wiki and a few video tutorials but no obvious API or reference documentation.
In sum
Pros: Dinosaurs, premade 3D environments and some particle systems.
Also you can drag objects connected to the ground and they follow the topography of the surface, which is handy for object placement.
Cons: little useful documentation, unintuitive interface, confusing controls.
Unity was much easier to use. They have extensive reference and scripting documentation (although it is not always quite as useful as it appears) and useful tutorials that walk you through the basics of using Unity and scripting.
Since Naomi had been working on making physics work, I decided to try making physics-less collisions. Using only scripting, I wanted to detect when two objects collided and push one of them back so they were no longer intersecting.
The Unity interface is easy to use, especially after reading the introductory tutorials. You can create primitive objects and drag-and-drop within a menu to set objects as children, add scripts, etc. You can even expose variables in scripts and then assign an object to that variable by dragging in the GUI.
The Unity scripting reference was easy to use and click through, although sometimes it did not give quite as much information as I wanted. I never saw a clear diagram of object hierarchy, which would have been useful, but I figured most of it out in the end.
Unity provides the concept of "triggers", which I used instead of collision detection since turning off physics also turned off collisions. When an object enters a trigger (any object with the trigger attribute enabled) they both call the "onTriggerEnter" function. I used this to detect collisions and did some simple vector math to transform the moving "character" back outside the bounding box.
Unity wasn't all fun and games though, it too has a few annoying quirks. Most obvious was it's arbitrary placement of created objects in the 3D space. Making a cube involved hunting down where Unity had placed it and dragging it back to where it was supposed to be. Also when testing it gives you the option to click "play" to see what your game behaves like. You can change variables and scripts while in this mode, but no changes are saved. Sometimes this is useful for testing purposes, more often it was annoying when changes you thought you made didn't get saved.
in sum
Pros: interface was well explained by tutorials, although not always intuitive. Drag-and-drop controls make scene building and simple scripting easy
Cons: arbitrary placement of new objects, not saving during testing