3DPI - Known Issues:
Changes will not be saved? (fixed with Director 11)
NEW (MX 2004): minimum
size of window
NEW (MX 2004): Mac
- F4 closes 3DPI
About Speed
Dark fields - Properties cannot be set?
Problem with editable fields
Problem with rotation
Problem with cloned lights
Problem with modifier #toon and #inker
Error after deleting a texture, which is
used for a Shader or Overlay
About Havok´s member function "initialize"
Error with TextureCoordinateList of a mesh
(fixed in version 4.1)
MX & OSX: Mac shortcut command-M stops
working (fixed with Director MX 2004)
Script error: Handler not defined #clearCache
(fixed in version 3.9.3)
Tip how to stop endless errors (fixed
in version 3.9)
Error with scaling (fixed
in version 3.7)
Havok: Mass of RigidBodies (fixed
in version 3.7)
| Changes will not be saved? (fixed with Director 11) |
top |
All properties (except member properties) that are
changed by Lingo will not be saved into the w3d file. This is
how Director 8.5 works.
Because the 3DPI communicates with your movie also with simple
lingo, the changes done with the 3DPI will not be saved too.
To keep changes one has to write scripts. Thats the fun and
the strength of Director. The 3DPI only can help you writing
the correct script lines:
|
 |
With the help of the Trace Button, which is placed
in the right upper corner of the window, you can get several
scriptlines, which will appear in the message window.
Also see: Trace Button and
Creating Scripts with the 3DPI. |
Please note that Director 11 - and in connection the version 5.0 of the 3DPI - offer new ways to save the shockwave3d world. |
| NEW
(MX 2004): minimum size of window |
top |
Since version 4.0 you can resize the 3DPI window.
(If you work with a Director version previous than MX 2004,
the window is only resizable, if you switch 'floating' in the
Preferences off.)
Resizable Miaws are great, the only thing is, Director does
not yet offer a possibility to define a minimum size. All Miaws
can be shrinked down to 70 x 70 Pixels.
But because the minimum size of the 3DPI should be 320 x 300
Pixels, I try the following workaround: if the user has finished
resizing the window, which I recognize because the resizeWindow
handler is called, I resize once again if necessary by changing
the window.rect.
The real problem now is, that resizing a window by Lingo is
not at all possible, if the windowType dockingEnabled is switched
On.
|
 |
If you work with Director MX 2004
and you have 'dockable' switched ON, you can
resize the window smaller than it should be.
You have to enlarge the window by hand to see all elements
completely. |
| NEW
(MX 2004): Mac - F4 closes 3DPI |
top |
If you are working with the 3DPI.
+ on a Mac,
+ with Director MX 2004,
+ the window Property 'floating' (3DPI Preferences) switched
ON,
+ the window Property 'dockable' (3DPI Preferences) switched
OFF,
and you select the commands 'Hide Panels' (key F4), the 3DPI
will disappear like all other floating windows do. If you then
select the command 'Show Panels' (key F4) the 3DPI sadly does
not appear again.
Bug is submitted (handler 'closeWindow' should not be called
in this situation). |
Because the 3DPI is checking the properties of your #shockwave
3D-member constantly to offer live informations, it slows down
the performance.
Especially when doing speed-tests, switch the "Pause when
deactive" option in the 3DPI Preferences on, or simply close
the 3DPI. |
| Dark fields - Properties cannot be
set? |
top |
| Editable fields within the 3DPI are always displayed white, |
 |
| and fields that are not editable have a darker background. |
 |
Please note that a non-editable field does NOT always mean,
that the Property itself cannot be changed by Lingo! Sometimes
I had to simplify the situation within the 3DPI, because sometimes
the restrictions to change a property are complicated. |
| Problem with editable fields |
top |
Sometimes (mainly on PC) the keys are not working within editable
fields. So the TAB-key does not switch to next field, the arrow-keys
are not working to move the pointer within the text, and so
on.
Well, I dont know yet what´s going on, but I will find
it out. Hopefully ;-) |
| Problem with rotation |
top |
| The main problem with the Wheel (endless Slider) at the transform.rotation.y
Property is fixed in version 3.7.
Nevertheless it might appear strange, how the rotation values
- especially the y-rotation value - behave in general. The reason
is that different rotations can result in the same orientation,
and there isn´t a position, rotation, or scale property
within Director, but a 4x4 matrix, which is responsible for
all transform sequences.
Generally it is highly recommended to use the rotate() function
instead of working with the rotation vector.
|
| Problem with cloned lights |
top |
Cloned lights are not really new lights, than a reference to
the original light. After deleting the original light, one should
never go on working with the cloned light, otherwise errors can
happen.
For the 3DPI it´s the same: don´t select a light that
was created by the "clone" function, after the original one is
deleted. |
| Problem with modifier #toon and #inker |
top |
When adding the #toon or #inker modifier to a model, all other
models, which are using the same ModelResource, will list
the modifier as well. I believe this is an incorrect behavior
of Director. (Bug already submitted.) The correct result should
be that all other models, which are using the same shader
should list this modifier.
Because of this circumstance it can happen, that the 3DPI runs
into errors. The only chance to avoid these errors is, not to
navigate to the #toon or #inker modifier part within the 3DPI,
as long as one is not absolutely sure, if the modifier really
exists at this model. |
| Error after deleting
a texture, which is used for a Shader or Overlay |
top |
|
After deleting a texture that was used for a Shader or for
an Overlay, Director can react with a Script error.
When the texture was used for a Shader and asking for the shader.textureList:
"Operation Disabled".
When the texture was used for an Overlay and asking for the
overlay´s source: "Value out of range".
Within the 3DPI the shader.textureList will be checked all
the time while a Shader of type #standard is selected, and an
overlay´s source will be checked all the time while a
camera is selected which has at least one overlay.
So after the texture was deleted, the 3DPI can run into an
error.
|
| About Havok´s member function
"initialize" |
top |
|
The lingo function for initializing a Havok cast member depends
on the way the member was created: either if it is an imported
.hke file, or if it is a blank member, created by using the
Insert > Media Element > Havok Physic Scene menu. (As
far as I understand.)
To initialize a member with the 3DPI and its "initialze"
button (Havok-Tab), it is necessary to specify this type. It
can be defined within the dialog, which opens after clicking
on the "initialize" button. (included in version 3.8)

If selecting the wrong specification, nothing will happen
after clicking on the "OK" button. The dialog
will stay open until the correct type is choosen or the "Cancel"
button is pressed.
|
FIXED
| Error with TextureCoordinateList
of a mesh (fixed in version 4.1) |
top |
If one asks for any information about the TextureCoordinateList
of a mesh ModelResource, but no TextureCoordinateList was defined,
Director reacts with a Script error.
If no TextureCoordinateList exists, clicking on the "PUT" Button
within the 3DPI results in an error as well.
I don´t know how to avoid this error, because I cannot
check the existence of the TextureCoordinateList, as long
as I am not allowed to ask for it. (But a change request was
sent to Macromedia.) |
| MX
& OSX: Mac shortcut command-M stops working (fixed
with Director MX 2004) |
top |
| Among other known issues the Director
MX Release Notes list for Mac OSX the following:
'The shortcut CMD+M stops working on the Macintosh if a Miaw
of windowType 49 is open (i.e. a floating window).'
Sadly this also happens if the 3DPI is open, but in the 3DPI
preferences you can switch the 3DPI window type to a standard
window instead of a floating palette.
|
| Script error: Handler not defined
#clearCache (fixed in version
3.9.3) |
top |
|
A few users reported an error "Script error: Handler
not defined #clearCache" after starting the 3DPI. The
real problem seems to be the new NetLingo Xtra update, that
can be downloaded at Macromedia to adress security issues
(technote
16636). It looks like, Macromedias technote is missing
one important step: you also need to copy both the IML and
DP/Dirapi libraries into your Director folder (varies depending
upon auth, projectors and Shockwave).
However, because the 3DPI does not need the line 'clearcache'
anymore since a long time, in version 3.9.3 this line is now
finally deleted, and you can continue to work with the 3DPI,
even if netLingo does not work correctly.
|
| Tip how to stop endless errors
(fixed in version 3.9) |
top |
|
Since version 3.9 it should not happen anymore that the 3DPI
runs into endless errors.
In older versions it can happen under certain circumstances,
that the 3DPI causes one error after the other, but there
is still a chance to stop it:
- Move the mouse exactly above the Close Box of the 3DPI
window
- Close the alert with a Keyboard shortcut (e.g. escape)
- then very quickly click to close the window before the next
error appears.
|
| Error with scaling (fixed
in version 3.7) |
top |
| If a transform.scale value is set to 0.0001, errors can happen
when trying to change the transform again. (Director Bug)
Workaround 1: Click on the Scale-Button and scale by
vector(2, 2, 2) or bigger.
Workaround 2: Select another object, click on the "Copy
Transform" Button, select the object with the scale problems
again, and click on "Paste Transform".
|
| Havok: Mass of RigidBodies
(fixed in version 3.7) |
top |
| Within the Havok-Tab at the part "RigidBody" the Property #mass
produces an error when trying to change it while a FixedRigidBody
is selected. (There is no problem when changing the mass of a
MoveableRigidBody.)
Additional it is not visible yet, if a RigidBody was defined
as Fixed or Moveable. But one can recognize the difference on
the #mass Property: if it is 0, the RigidBody is fixed, and
if it is bigger than 0, it is a moveable RigidBody.
So after all, please don´t change the mass of a RigidBody
when it is 0.
|
|