How to install the update ?
The installers do all the work for you, in Windows, double click the .exe file, for the Mac de-archive the hqx file then run the installer application. You will have to install into an existing US retail version 1.0 of Canoma (already previously installed).
What bugs have been fixed ?
Sometimes, when the user executed an Undo command, subsequent texturing would be wrong - only pixels from the currently edited source image would be used. The workaround was to go into edit mode, and page through all the available source images, then apply textures again. Thats no longer necessary.
Canoma 1.0 sometimes left empty folders named " Edits" and " Temp". No more.
In the rare case when an edge was glued to another edge which had the same direction, the glue would not work and the display would show "dancing lines" for the glue.
Sometimes in larger models, releasing the mouse when placing a pin did not place the pin at the right location (but instead whereever the mouse is currently) The pin is now always placed exactly where the mouse was when the button was released.
In very rare cases it was possible to rotate several primitives when a "Rotate by 90 degrees" command was issued. This is fixed.
What has changed ?
Exported Canoma models by default have arbitrary position, orientation and scale on export. To facilitate integration into other 3D applications and existing content, Canoma 1.0 already allowed scaling the model using line primitives to calibrate the scene to some "real-world" coordinates.
For example, you can create a line primitive, glue its endpoints between any two corners of primitives already in the scene (you may have to unfix Y or all orientations depending on where the line is supposed to go) Then, Get Info on the line and you will see its current length. Now, you can enter your desired length, for example you have measured the distance indicated by the line with a measuring tape, and found it to be N inches or feet or meters. Just enter that number and all other objects in the scene will be uniformly scaled so they are the correct size relative to your indicated line length. You could look at the line primitive with a user-defined length used for calibration as a "yardstick" or "measurement tape".
With 1.0.1 we added the ability to designate one primitive in a Canoma model as the "Origin primitive". Its centerpoint will become the origin of the exported model and the exported model will be aligned with the origin primitive. Typically primitives have their origin on the ground plane, in the horizontal center of the primitive (for example the horizontal rectangle, box, pyramid etc.) Polygons, Curtains and Translation sweep have completely user defined contours and so make less sense to designate as origin primitives.
In order to designate any primitive as "the origin primitive", prefix its name with "XYZ-". So for example "Box" becomes "XYZ-Box". Note: XYZ has to be in upper case. Only one primitive per scene should be designated as the origin, otherwise Canoma will just pick one.
The VRML2 output now defines a "Movable" PROTO and all objects are defined through it. This means common behaviours for Canoma objects can be defined or edited just once in that PROTO. The default allows a variable to be passed in that defines an object as movable or not.
Canoma objects are initially created as not movable. However, if you change the name of an object to end with the # character, it will be emitted as movable, for example "Box" is not movable, but "Box#" is. In a VRML browser, moving a mouse over a movable object will temporarily show a transparent, red bounding box. Dragging the box will slide the object horizontally. This capability makes it easy to "rearrange" furniture or move an existing building out of the way.
The second addition to VRML output is the ability to group any number of Canoma objects together so they can be moved all at once. Rename the objects belonging to a group to "groupname@objectname", for example, "house@Box", "house@BoxOnTop1", "house@Roof3#" all three belong to the group house. Making any object of a group movable in this case the last one makes the whole group movable. Again, this allows a greater degree of control for "remodeling" your Canoma environments in a VRML browser.
Tip: we recommend VRML2 export format for use with Canoma and 3D Studio Max. This will import geometry, textures and even a camera object corresponding witheach source image into 3D Studio Max. However, if objects are declared movable, it will also import a red bounding box for each of them (which can easily be deleted in 3D Studio Max) To avoid this, dont make your objects movable when exporting VRML2 for 3D Studio Max.
Some users have asked for better control of the material specifications in Wavefront OBJ and Caligari Truespace file formats. Both of these allow seperate specification of the diffuse (lit) component of the material and the ambient (unlit) component. In principle, Canoma models are already prelit, by the lighting present in the source photographs. So strictly speaking, they should not be lit again in a downstream 3D application, they are pure "light emitters" (i.e. fully ambient shading, or what Ray Dream calls "glow maps"). But that makes it impossible to shade the exported models in a 3D application with virtual light sources.
To alleviate this problem and
to allow differences in shading algorithms of various 3D target
applications to be overcome, Canoma 1.0.1 allows users to explicitly
specify the amount of ambient and diffuse shading that gets exported
in OBJ and SCN files. It is likely that only advanced users will
use this feature and typically will set the numbers up once for
their preferred 3D application, so they are stored in a preference
file in a simple text format. The file is named "obj.prf"
for the OBJ output preferences and "scn.prf" for the
SCN output preferences. If these files are not present, the default
values shown below will be used. If you change the content of
these files, make sure you leave a space between the Kd/Ka and
the actual value. The value must be a number between 0 and 1.
Anything that cannot be parsed will be ignored by Canoma, including
the comments starting with '#'
For OBJ files only, you can also specify the order and direction
in which coordinates are written out, using the "axisorder"
keyword. Usually you will not change these values.
Ray Dream Studio, Poser and Bryce users should use this OBJ.PRF file (these are also the defaults in case the file is not present)
# File: OBJ.PRF
# This is the Canoma OBJ export format preference file
# for Ray Dream Studio, Poser and Bryce OBJ export
Kd .8
Ka .2
axisorder -1 3 2
Electric Image users should use this OBJ.PRF file (only the axisorder statement is really necessary, adjust Ka, Kd as desired):
# File: OBJ.PRF
# This is the Canoma OBJ export format preference file
# for Electric Image Animation System OBJ export
Kd .8
Ka .2
axisorder 2 3 -1
Caligari Truespace users should use this SCN.PRF file (the values below are the defaults in case the file is not present)
# File: SCN.PRF
# This is the Canoma SCN export format preference file
# for Caligari Truespace SCN scene file format export
Kd 1.0
Ka 0.1
To make sure other products do
not have problems reading exported files, Canoma 1.0.1 converts
all non-character and non-numerals in object and camera/view names
(including spaces) to underscore characters: '_'
So "Roof 23+2.5" becomes "Roof_23_2_5". In
addition, leading numerals in object names in VRML files caused
the COSMO browser to choke, so Canoma 1.0.1 now prefixes such
names with an underscore character. I.e. "403.jpg" becomes
"_403_jpg"
As a general rule, you should only use letters, numbers, possibly spaces and the following special characters:
'-' (hyphen) used for designating
an origin primitive as in 'XYZ-name'
'@' used for specifying a group as in 'groupname@objectname'
'#' used for specifying an object or group as movable for VRML2
output, as in 'objectname#' or 'groupname@objectname#'
If you use other special characters in your object names, the objects may not be textured correctly.
Lines are sometimes used to glue to vertical edges. To do that, you have to create a (horizontal) line, then unfix its orientations and then start glueing. Problem is that one endpoint of the line is fixed at height=0. If you happen to try to glue that one to a top corner of the edge, Canoma will be unhappy and your model very stressed (You could always undo and then glue the other line endpoint which is free to move about vertically) To avoid this guessing game, we now draw the "base point" of the line, that is the one with height fixed to 0, with a little marker, an inverted T. That way you always know which line endpoint to avoid glueing to a high-up corner.
<End>