Too many textures slow down the refresh on some sytems
The following restrictions currently apply (as of Version 1.25):
(I'm pretty sure I'll fix some of them, but maybe not all...)
Currently I have seen it running sucessfully ONLY on W2K and NT4. This seems to be an OpenGl implementation issue.....
Any help on this subject is appreciated.
There is no general Undo function, so save the project before you perform major changes.
Undo is not available for every function, and only for the used function.
Example: If vertices are Moved and then Scaled, clicking Move -> Undo restores the vertices how they were BEFORE THE MOVE, therefor Scale is lost.
Pan is very sensitive when zoomed in full, especially with small objects.
As a workaround, all vertices can be scaled by a certain value, let's say 100, then panning is OK.
Of course the vertices must be downscaled before writing the 3DO, in this case by 0.01, otherwise the 3DO would be way too big.
The same method can be used when vertices are too big to pick and are overlaying each other.
When copying a polygon, it may sometimes be necessary to use the Rotate/Mirror functions afterwards.
Although the "Collision Volumes" function is working good, is a little tricky to set up. Be careful.
Wrong volumes can be deleted anyway.
The path or filenames of any of the used files must NOT contain spaces.
In the background, the [Start GPL] and [Restart OneTwo3do] functions operate on regular
command line principles, where spaces seperate the commands on the command line, so a space in a path would divide one path into two.
When returning from GPL, the view window is distorted. Causes no headache, though, a click into the view window restores it.
The transparency is not displayed correctly within OneTwo3do. Again, help on this is appreciated.
In the main window, when moving the camera with the sliders, X is not X and Y is not Y, but Z is Z !
Hmmm.....I guess you can live that as I can ;-)
Although Lines can be drawn quite nicely, they are not yet written into the 3DO because of some Ase23do limitation. Hopefully Phil will provide (yet another) fix... ;-)
Well.....I could write my own 3DO-Tree output routine, but that's another story ;-)
It is generally not the cleanest piece of software out there (due to my humble programming "skills"), but I'm sure I will fix some of the minor issues from time to time.
No doubt that I have missed something here or there, but it seems to be quite usable by now (to us).