I started to dig the parallel mode of SceneCamera, which so far can not be handled by the view very easily (zoom not working, size has no dedicated inputs but is "controlled" by Fiels of View... ) and not much easier with the SceneCamera dialog.

Some may recall, that I called it another project, when doing the view manipulation refurbish and that seems to have been the right choice: Basically there seem to have been too few parameters to handle it when it was made and I found some pretty surprising couplings there, which make it somewhat tricky to set up exactly the way you might want to.

Mostly it looks like a couple of lines of code into an handful of files each and a partial rethink of the dialog.

As a potential further development I'd like to see better connections between the SceneCamera, the interactive view and the rendering, for example so that you could see the final framing with the correct aspect ratio already on the view and not only after you render it... and so on. But again: The current problem first.

running OSSpecific plugin with JDK9+ gives an exception in app log:
java.lang.NoSuchMethodException: com.apple.eawt.Application.setEnabledAboutMenu(boolean)

Such methods are no more available.
Oracle recommends to use instead java.awt.Desktop class but this affects backward compatibility with older java versions

When you select Tray or Drive modes the view is rotated to y=up orientation. From that on the views behave like in the corresponding 3D-Rotate modes. The mode selction is correct and the code in the tool file looks correct though.

There are several files, that pass the (mouse) input information through: ViewerCanvas and it's sub-classes, ViewerNavigationControl and RotateViewTool. Also ViewAnimation is used, when the mode is selected.

The sympthoms seem to indicate, that the RotateViewTool gets a wrong value during mouse drag in spite of the mode selection being correct. There also are cases, when the focus point of the view changes suddenly, when the navigation mode is changed. These issues could be related.

I was wondering if adding new translations could be made easier?

Currently the new translations (=recognized locales) are coded intoTranslate class. This seems a bit too rigid for the purpose to me. Couldn't the software just read the translation files and add to the list anything it finds?

I can see, that some locales are coded into Java as field constants and some are created by language and country information. I wonder if there should be something in the beginning of each file to tell the software what it contains of if it could be in the filename? I guess opening each file would slow the startup down.

What I was thinking was, that at simplest a new translation could be added to ArtOfIllusion.jar by a zip tool.

Some time ago I discovered a minor bug in the animation engine:

If you press one of the number pad keys while the previous animated move is still unfinished, the move to the new position does not start from the current position but again from the beginning of the unfinished move.

This originally appeared somewhere during the big UI update and I'm pretty sure I had fixed it already at some point ... I remember that the fix was pretty simple but I probably don't have that version around any more.

I'll try to get it for 3.1.1 but if not, let's not wait. There is a fair amount of checked in bug fixes already waiting to be released.

In the Polygon tool holding Ctrl draws the polygon filled.

To have consistency with #128 and #141 I'd suggest to put 'Expand from center' under the Ctrl in Polygon too and move the choice for filled drawing into the dialog.

The dialog of the polygon tool is probably opened most of the times anyway, when the user wants to draw a polygon, so I'd say the choice would be in an obvious place there. And personally I have recently become to appreciate it very highly that tools that do somehow similar things are handled exactly the same way. (One of the things whose value you notice, when it's missing.)

I have had this in my mind for a while now, but I did not hurry to bring it up, thinking that the next release would be mainly a bug fix without format changes. Now that it seems like it's going to be 3.2 with the new GL, I think this should be fixed at the same.

So, I had a look a the code and locked is never mentioned in the write/read methods of Scene. I'd expect to look like how visible is handled.

I don't know how this should be fixed as there is no built in version numbering for ObjectInfo, but from user's point of view I'd expect to reopen my scenes in the state I last saved them in. I don't (and I'm not alone with this) see the locked parameter as a per session thing.

This is not the only thing that is wrong with object locking but this would the one that makes the greatest difference for the feature to be in any way useful.

See code lines from 96 to 101
We iterate over clickPoint array but at line 98 pos value always evaluates from clickPoint.lastElement()

While testing #150, I finally figured out why using the 3d-manipulator seems "fussy" to me.

If a "selected thing" happens to be right behind the "handle" that you are targeting, the 3d manipulator does not seem to get the mouse event. Instead, the selection is moved around in screen space, as if you are using the move tool. (Possibly because this is the default tool in my - and most - AOI installations)

• "selected thing" is a face, edge, or vertices that is part of the current selection (depending on the selection mode). It's easiest to spot in face mode, but with an edge or vertice in the wrong location it will happen in those modes, too.
• "handle" is any of the manipulator targets, including move-along-axis, scale axis, and the rotation control disks

This issue is present in existing releases.

Just realized that running optimize mesh on a TriangleMesh will completely trash existing UV mappings.

On one hand, I get it: It's not possible to maintain the UV maps through all edge re-orderings (If there is a seam in the mapping, laying an edge directly across the seam is... not representable)

On the other hand, this limits the utility of the tool, especially if working with imported meshes, which often have their texture mapping all set up ahead of time.

Questions:

• Should Optimize try to preserve UV mappings at all?
• What should it do if it cannot preserve the mapping?
  • Give up, and destroy the mapping?
  • Give up, and leave the mesh topology unchanged?
  • Take mesh seams as a hint that certain edges must remain in place, resulting in a Sub-optimal optimization?

Whichever we decide, we need to make sure that the behavior is documented.

Somewhere around java 8/9, a change was made in how OpenJDK/Oracle Java handles mouse modifiers.

Middle- and Right-Buttons no longer map directly into isMetaDown/isAltDown and similar. Also, Ctrl no longer maps to/is read as Meta on Windows or Linux.

This means that all code that handles mouse input, particularly anything that works with view control, needs to be reviewed, and modifier detection needs to be updated.

As discussed on SourceForge, root joints need a numerical position input. The numerical position input would be useful with other joint as well but the effects might reach rather deep.

Also it should be possible to lock the position at least during editing as it is now very easy grab the skeleton and drag changing both the pose and the root location without actually meaning to. The position coordinates and the locked status should make a similar pair as locked with any other degree of freedom. I don't know if this can be handled with the current set of parameters for a root joint, that does not have a parent and therefore length.

Hi.

Generally in the computer world point (period, dot, full-stop) is the decimal separator and basically text turns into a number correctly by default settings, when there is a point. However in the parts of the world I come from, the standard decimal separator is comma and naturally the number pad of the keyboard also types comma...

With AoI this is a bit of an annoyance as the user will have to get the decimal point from the typing keyboard, when otherwise typing numbers on the number pad.

The typical localization of course is, that the decimal separator is then comma and nothing else. For example Windows calculator does not "see" a point and if I copy and paste 124.76 to the number display, it becomes 12 476. (If I download lists like star maps, they usually come as text, with decimal points, and sometimes the software that I bring it into does localization right and sometimes not....)

I don't know, what would be available for keyboard localization, but at least Dassault Systems and AutoDesk use a system, that recognizes both . and , as a decimal separators and you can actually use both even inside the same calculation.

Now the profound difference is, that value fields in professional CADs are not number fields but equation fields, where there is an interpreter constantly reading, what the user is typing -- the text turns red if there is an error etc... The equations are stored as equations, with some standardizing happening when the content is reproduced from the data, but you can happily mix imperial and SI units if you like and use dimensions from what you have done before.

AoI does not have any dimension controlled features, so the equation engine would not be very useful but, what about the point vs. comma issue? Are there any "hidden" possibilities to have the input fields understand, that if I type comma from the number pad, I mean decimal and if I copy & paste numbers with a point to the fields, I still mean decimal? -- And all the other variations. IMO one clear solution would be to read and display a comma as a point instantly, but I don't know if something useful might already be available?

Just found out that a malformed extensions.xml from a third party plugin can cause the application to freeze on startup.

artofillusion.PluginRegistry.processJar does not catch errors thrown by the classloader code.

Such errors should be logged, but the application should continue to load, possibly with that particular plugin disabled.

For discussion: what is the proper behavior if a plugin declares several different plugin classes, and only one throws an error?

Hi!

This is something, that has been bothering me for a long time: AoI does not save the view settings, including camera positions, perspective, magnification... between sessions. All the other 3D-SW (that I have ever used) do. Always have.

I realized, that this could be now implemented by metadata. I'd suggest to save the last settings not only for the LayoutWindow but all mesh objects too.

I think this could be made a plugin, but IMO it is such a basic feature, that it should be built in. (@Sailsman63 said earlier that he would like to have some of the TroyTools-features coded in) The set I'm thinking about would be:

• Remember view orientations and positions, perspective, navigation etc. settings
  • for scene
  • for each object, that is handled in an object editor window
• Have the object editors fit the views to the object, the first time it is opened
• Have a start-up default for the 4th view if a "Camera 1" can not be found.
  • perspective on
  • orientation user preference (two angles expressed like 30° left, 15° up)
  • and use the same angle for the Camera 1 if one is present

Some of this was included in TroyTools but TroyTools is unfinished work and Troy himself had a replacement for it available. Just somehow the better tool never got into the repository.

What do you think?

A thought, that easily follows is, that the content of the default file could also be a user preference. (A template file maybe if the user chooses so. Making that happen should probably a different project though.)

Edit: The post ran off before a single typo review... some of those taken care of & some additions.

Spinning this off from the discussion in #172.

I sketched some ideas on the contents list of the hand written HTML version... May be not optimal, but basically things I'd expect to find would be:

• Art of Illusion in a nut shell (should fit on one printed page or less and that page should contain just that -- not continue to using).
• Installation (maybe an appendix or something, but adressed in the beginning)
• A crash course into using (about 4 pages sounds about right. The user should have results within 3 minutes.)
• Then the actual detailed structured manual ... like:
  • User interface and controls
  • Getting extensions
  • Object types
  • 3D Objects and their Editors
  • Textures, materials and their editors
  • Animation
  • and so on....

what about a manual structured as a fairly lightweight tutorial, with links to various appendices for advanced/detailed information?

That might work. What I miss is that the main (manual) structure would be packed into less than ten main topics (7'd be nice). Now it seems to be expanding to much more, which does not help learning or understanding. On the other hand a manual should also have the technical side that is detailed to the last bit. --> Putting everything into one long scroll just does not work.

Also I'd like to keep each html page in reasonable length. One page for one topic. Now it just slides from one topic to next never stopping -- The reader loses the structure of thought. I don't know if it depends on the theme or if it is the Sphinx itself but Peter said "it's inherent" that one src file becomes one 1. level topic.... If that really is the case, that limits quite a lot of what can be done.

And things like quick reference pages for controls (pdf?) would be useful.

The main problem:

I imported an STL model about 10 × 15 × 50 meters in size, that was exported in millimeter scale, so the largest dimesion would be about 50000 units in AoI space. It turns out that neither the GL-Drawer nor the SW-Dawer can handle it properly. What happens is slightly different in each case:

• GL-Drawer in parallel mode shows the object in all view modes
• GL-Drawer in perspective mode show it only in transparent mode
• SW-Drawer shows it in wire frame and transparent, but not in the other modes. The perspective selection does not have an effect.
• Ray tracer produces a rather grainy, messy image

The size range where objects start to reappear, as you zoom in is somewhere in the thousands of units. An object with curved surfaces, like a sphere, emerges gradually from "light speed" and simpler rendering mesh like a cube just appears.

A separate issue but related:

Generally speaking the number fields are mostly too narrow to show values in this scale. Values like this still come with three decimals... For example in the sphere editor a value like 28653.089 shows as 653.089.

And yet another one:

To handle something this big (well it is big in AoI terms but not really... far bigger things are handled in 3D) you need to set the Interactive Surface Error to about 200 or even higher.

That you have to change the setting manually every time you open a file in different scale and to remember to do it before you open the file, is definitely a usability flaw. The least thing to do would be to have the setting saved per scene file.

I'd suggest to keep the default setting for new files in Preferences but add a new one to Scene properties. By nature this seems like something to be saved as Metadata. To comply with that the STL-importer (and the others as well) should probably set the interactive error for an imported file automatically, like as 2% of the size of the largest dimension. -- Of course if the interactive rendering accuracy were to be automatized one day, this setting would change into a different form, relative instead of absolute.

So:

Any ideas where to look? I might start a branch to handle all or some of the above. Somehow I don't believe that the main issue here would even be very difficult to solve.

The preview window in the Texture Mapping dialog does not get updated when the mapping is edited, when the object is a Boolean object. The texture was a 3D-procedural in this case. I have not tested other combinations with booleans. However with other object types I have not noticed anything strange.

At least this translation, that is split into two parts is not working as it is supposed to. The ´{0}´ is supposed to be the name of the image, that is going to be processed.

This is in Scene / Images... / View Details... / Convert to local that is used on linked images. Can't say what is wrong yet but should probably double check the other similar cases too.

The problem has two parts:
First one: menu selection code expects that command is under Scene menu. It's easy to fix.

Second one: the proper visibility toggling depends on other panel under same dock. If we detach Properties panel from dock toggling begin to work. If we move score panel to right dock toggling for Objects panel fails and in this case toggling Score panel becomes invalid too

The 3.1.0 release contained a major re-work of how viewpoints in the various editors are managed. (Thanks, @peteihis!)

These changes are extensive enough that they really should be documented in the manual

I just noticed, that the mouse view tools (rotate, move, scroll) do not update the previews of Boolean, Extrude, Lathe.... The tools do work but there is a error in the call to view repaint and the effect of the move or rotate will be seen, when the view is updated by something else like a change to the parameters on the dialog.

All the viewtools come with the same basic structure and I copied the same mistake to all of them. Extremely unfortunate, that this got through the betas and all..... Earlier in the process I tried to remember to check all the little views too, but on the last steps I obviously forgot these.

I'll push a fix soon --> 3.1.1 or a "correction package" to 3.1.0?

Hi.

I realized that there is an obvious difficulty in using null objects as coordinate centers, when making animations: A drawn null object does not in any way indicate which axis is which or which way they are pointed. However this would be rather an essential information to get rotations done in a sensible an repeatable manner, without having to do a frustrating trial-error-round every time.

Any ideas how this could be implemented? Just drawing arrows and adding "X-Y-Z" would easily make the screen messy. Using colors would be an obvious addition but the color environment is not necessarily optimal for using colors and also there are users to whom colors are not very helpful as the only indicator of orientation.

Coordinates are changing size in camera views, when using center-click fit in 3.1.0-beta1.

This does not happen with the version in my repository nor does it happen with an entirely new clone of the ArtOfIllusion master.

You can find a screen capture video in https://sourceforge.net/p/aoi/discussion/47782/thread/eaea857da7/?page=1&limit=25#973f

Steps to reproduce:
Open AOI.
Click on Objects pane with RMB to invoke popup menu.
Click on pane again. The NPE is outputs in log:

java.lang.NullPointerException
at artofillusion.ui.AutoScroller.mouseReleased(AutoScroller.java:51)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at buoy.internal.EventLinkRecord.dispatchEvent(EventLinkRecord.java:81)
at buoy.event.EventSource.dispatchEvent(EventSource.java:140)
at buoy.widget.Widget.dispatchEvent(Widget.java:326)
at buoy.internal.EventLinkAdapter.dispatchEvent(EventLinkAdapter.java:212)
at buoy.internal.EventLinkAdapter.mouseReleased(EventLinkAdapter.java:108)
at java.desktop/java.awt.Component.processMouseEvent(Component.java:6578)
at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3343)

I see that mouseReleased method calls twice and on second call tries to interrrupt already released scrollThred.
Easy to fix but not very clear why this method calls twice...

There is transifex.com. It's free for open source projects. It support Java properties format.

It is possible to create primitive objects with at least one input dimension reduced to 0.0. This often happens, when you accidentally click on the view and a creation tool happens to be selected.

There are cases when updateImage of a view gets interrupted because of an object like that, which then leaves the view blank. Unfortunately the blank view will not recover even if the problem object is deleted.

As a correction I see two possibilities: Improve error handling in the view update process or prevent creating zero dimension primitives. I'd go with the latter one. Somehow setting a dimension of an already existing primitive to 0.0 is not a problem. That would seem to imply that a 0.0 dimension at creation actually leaves the primitive faulty in some other way as well.

artofillusion.procedural tests except ImageModule test now fails with NPE.

There are some cases where the modified-status of the scene appears wrong. There also is a case where there seems to be a mismatch between the actual value of the modified-flag and the status of the Save menu item.

What I found so far:

• Procedural material and texture editors: It doesn't matter if you change anything or how you exit the dialog the modified flag is always set true.
• Procedural position track (probably the rest of them too): Cancel does not change the modified flag, but the exit-button (the red-X) does.

In these cases the absolute correct way would be to add modified = true lines into the code everywhere that changes something and assume it false in any other case. Then also exiting with OK should leave the flag false if nothing was changed. The cheaper solution would be to have OK always set modified = true. The red-X should always be wired through, what ever Cancel does.

• When an object is selected and the scene saved, the Save-menu item stays active (in many cases at least) though window.isModified() may already return false. The status of the Save-item may change by deselecting the object.
• When the mismatch occurs Save may still stay disabled after the already selected object is moved.

I did not try to figure out the exact logic, how all that happens, but it should be easily repeatable. (AoI 3.0.3)

I did not check the code either, but one thing, not necessarily related to this but coming to my mind, that could in general level be responsible of occasional mismatches is the "toggle style" coding of some variables that I have seen:

toggeleFlipped()
{
    position.setState(! position.getState());
}

It seems handy as long as nothing else can ever access "position" or "toggle" but if something changed either the "toggle" or the "position" outside this bit of code, the mismatch will not be fixed at the next toggle flip. The waterproof way would be:

toggeleFlipped()
{
    position.setState(toggle.getState()); // or (! toggle.getState()) if that is the purpose.
}

I may report more as soon as I find some.

Hi.

Working on #161 I began to miss a new kind of a value field:

• It should have lower and upper limit values, that can be set by constructor or by method
• It should have include/exclude option for the limit values (meaning > or => and < or =<).
• It should have increment arrows to add reduce the value.
• The increment sholud be set by constructor or method
• It might have a choice whether the increment snaps to multiplies of the increment or if it just adds/reduces the current value by the increment.
• Things like NONNEGATIVE would be replaced by the limit values but the INTEGER / DOUBLE ... options should be available

A constructor could look like something like this.

public LimitedValueField(int value, int type, int lowerLimit, boolean includeLL, int upperLimit, boolean includeUL, boolean showArrows)

And simply a limit value 'null' would mean that the limit is not set and if the upper limit is lower than the lower limit, it could at simplest be just ignored.

I'm the first time trying ArtOfIllusion.
Cannot load scene from file download from http://www.artofillusion.org/artgallery .
It seems scene file is saved using Java Object serialization but over times many objects are just refactoried and package-changed, make it fail to load.
Maybe could use a more reliable format to save .aoi files?

Isin't it annoying, when you try to pick your own language from a list, that is written in a language, that you couldn't possibly know? That has happened to me.

Nowadays it seems common to have language selection present each available choice in that language. Definitely a user firendly approach. I don't know, what it would take but I suppose, substituting sometihng, that is now provided by the system with something else? -- And a fall back system, if the language does not exist in that particular computer?

At startup System.out gets lines like:

klo 13.09.46 [main] in SearchlistClassLoader.findResource() (SearchlistClassLoader.java:442)
   findResource: looking in artofillusion.util.SearchlistClassLoader@6986852 for artofillusion/PluginRegistry.groovy

.....

klo 13.09.46 [main] in SearchlistClassLoader.findResource() (SearchlistClassLoader.java:442)
   findResource: looking in artofillusion.util.SearchlistClassLoader@3d121db3 for Script1$1Customizer.groovy

Lines 58 to 371in that case.

I'm not sure what is supposed to happen there, but it seems, that SriptRunner is looking for a set of groovy files in the code structure, that obviously aren't there. On top of that it is set to report the "looking for" but not if the file was found or not.

This is probably a minor issue from the user's point of view, but it doesn't seem right either. Can the line 442 in SearchlistClassLoader at least be commented out?

Hi.

As we happened to be in the neighborhood, this old pebble in my shoe caught my attention again. There are a number of things that seem to be a bit off with the DOF Graph.

The image is a scaled up blend of two screen captures. Believe it or not the value it displays is 90°, not e.g. 88,5°. The larger gray disc is the one that is displayed, when the DOF is locked. It is bigger than the active dial but it is slightly misplaced. Further more, in the beginning of the code I find:

    private static final int SIZE = 64;
    private static final int RADIUS1 = 64;

...ehhh... diameter equals radius?

I don't know what has been available at the time the DOF Graph was coded but for now I'd suggest:

• Make it a bit bigger.
• Use an odd value for the sizes, so the center point is in the middle of the middle pixel. The graphs look a lot sharper this way.
• Draw in Graphics2D (Use a transparent BufferedImage as canvas)
• Use anti aliased drawing.
• Use the options that draw in double values.
• Use AffineTransform to move the 0,0 to the center pixel. This simplifies the rest a lot.
• Consider revising colors, like red(dish) tone for restricting the total range, yellow(ish) for comfort range, green(ish) for the bend angle...(if any color at all, might be too much graphic information.)
• Try to have better separation between the handles of the zones.

Of course mouse event handling would be affected accordingly.

#7 pointed out that AOI does not really have a logging system. System.out.println() calls scattered just about anywhere.

A simple logging framework would seem to be in order, even if just a home-rolled class that handles driecting output to file or otherwise, and diferentiating between emergency messages and "Include the Kitchen Sink" debug level messages. Suggestions on exactly what to use are welcome.

Once I open and render scene the rendering settings are writes to Scene metadata but this is not mark Scene as modified. If after that do nothing more and close Scene this changes are missed.
Moreover some rendering options ex, frame width/height are not saves at all

artofillusion.procedural.Module conflicts with the new Java.lang.Module class.

Since Fully Qualified pathnames are resolved at compile time, existing binaries compiled with Java 1.8 or earlier will still run, but AOI currently refuses to compile under Java 9.

Since the Java.lang package is always imported, we have two choices:

• Use the Fully Qualified Name in every call to artofillusion.procedural.Module (messy and verbose, will tend to break as other code is added in the future.)
• Change the Classname for artofillusion.procedural.Module. This would be a fairly significant refactor, and an API breaker that affects existing plugins.

The new purge feature, added in #35, does not properly reset the image dialog buttons when the selected image is deleted. Buttons such as "See Details" are still active, which can lead to a Null Pointer Exception

I'd like to see the entire button panel streamlined, but will wait for user feedback on the new feature.

Hi!

As anyone who has had a look at, what I have done so far can see, I have made quite a mess with the formatting of the code, primarily using tabs for indentation and occasionally panicking with the format and dropping to 2- or 4-space indents and the coming back.... I have been thinking, that before anyone does anything else, I should perform a "grand white wash" to the files, that I have created or edited but before that I'd like to make a suggestion about the formatting.

Now the guideline says, that the indentation style is 2-spaces, but I'm wondering, what the reasoning behind this instruction is or if the reasons are really valid nowadays?

I've got a feeling, that this practice pretty much comes from the era of VGA displays or before, where you could realistically fit about 20 lines on an editor screen and max 80 characters on a line. Nowadays displays are a lot larger. You can easily fit 60 x 200+ characters on the screen and with the latest toys even more.

While the 2-space indent saves space on small resolution displays, on large ones the presentation begins lose clarity of structure. At least that is very strongly my own perception of it. To me writing in 4-space indents makes the code much easier to browse and to keep track of the 'big picture'. Also (though this is really no argument here) Java examples on Oracle are written with 4-space indents and as I might guess, for very similar reasons.

Sure, there would be no point in starting to modify all of the code base into a new style but I'd suggest, that I'd clean/edit the new files (of my writing) and the ones, that I have heavily edited to 4-space indents. This would be rather easy to do even with files of currently mixed styles, while converting tabs to spaces.

While I'm at it, I might (where I find it bothering me) do some other minor styling as well: In my experience for example this

    if(something)
      {
        doThis();
      }
    else
      {
        doThat();
      }

is somewhat confusing to read especially, when the blocks get longer or when there are more similar indents inside the blocks. To me this would be more logical to follow:

    if(something)
    {
      doThis();
    }
    else
    {
      doThat();
    }

Then especially in cases of if-without-else or a short(ish) for, I might go:

    for(something){
      doThis();
      doThat();
    }

What works better seems to depend on, what is inside the block. At least, if there are more blocks, I'd probably want to drop the first brace on it's own line. The examples above are in 2-space style and currently you can find all of the three in different parts of the code, depending on when each piece was written.

So, what do you think? Would you find modernization to 4-space intents, with some other minor flavors reasonable in the mentioned cases or should I strictly stick to the old rules?

Just recently I noticed, that when you use the Text tool in Surface mode, and put a layered texture on it, Front and Back are opposite to, what you'd expect.

In some recent runs of the unit tests (working on fixing the test suite) I just got the following errors:

[junit] expected:<1.125680191712794> but was:<1.1256157239630205>
on line 52 and, on a susequent run,
[junit] expected:<-0.07972279469479109> but was:<-0.07970200347745438>
on line 51.

This test randomly generates the radii for each test. This looks like rounding/overflow errors to me, but without knowing what the input numbers are, I cannot be sure. The test should at least print r1 & r2 values for the test sphere, and x, y & z values for that run of the test method.

Found this one while testing #157.

When creating a new Layered texture:

• Add first simple texture
• Edit Mapping
  • Adjust "Apply to: Faces"
• Add second simple texture
• Edit Mapping for second texture

Will result in

java.lang.ArrayIndexOutOfBoundsException: 1
at artofillusion.texture.LayeredMapping.getLayerParameters(LayeredMapping.java:154)

If you continue with editing the mapping, and select 'ok' for the layered texture as a whole, the mapping changes that you made will be applied to the first texture, and the second will not be saved into the layered texture.

• Does not happen if you do not edit the mapping of the first texture.
• Can be worked around by Saving the layered texture with just the first layer + edits, then come back in to add the second layer

Currently I take a look at some plugings and how them saves its configuration.
Base AOI app saves preferences under ${user.home}/.artofillusion folder in .aoiprefs file
SPManager plugin saves its config under ${user.home} in .spmanagerprefs file
HelpPlugin saves preferences under ${user.home}/.artofillusion in HelpPlugin.props file

Both plugins implements very similar to base AOI app code to create save and parse options.
I think we need common API for this
One more plugin - Polymesh stores options using java preferences api - this is platform specific implementation

Hi.

I noticed that the TexturesAndMaterialDialog fails to open if the assetsFolder is missing. Line 204 reports nullPointerExceptipn. As you can launch AoI without the Plugins folder I think it'd be rasonable to be able to open the dialog too without the folder present and use it to manage the textures and materials that are there.

One approach could be that the missing folder would be created at dialog launch or at least if the user chooses to export any materals or textures.

So that this would not be forgotten....

Currently the settings of the selected renderer are saved to metadata every time a renderer is used but, most annoyingly, the settings, that belong to the RendeSettingDialog are not. Wondering which camera, what resolution, what fps, what time span... Starts over every time you come back to the file.

If the setting were to be saved, it might be in place to create a safety trigger, that if the settings are read from file it would ask the user to check the settings before starting the rendering the first time at least if the image is very large or something else "big" is about happen.

The next idea waiting to pop up after the above would be to create a user controlled preset system of some kind. By default the preset could just be "Last used", and the user could name and save more presets per file or to export to disk for later use. Also "Reset to factory settings", could be useful. For this I'd suggest a combo box menu to select one of the available ones and preset manger dialog for save/export/import... functions. And as a learning from the past (Effects Renderer I think) it should not automatically save a new set of presets every time the user changes something...

I've been reading some parts of the manual closely for a bit now, and run into a little time capsule:

Both the Introduction and Scripting chapters mention custom Swing Theming, which was sort of a big deal back then.

Since then, Fashion has changed, and custom skins for individual applications are not nearly as big a thing as they were.

Also, javootoo.com (Which the manual mentions repeatedly) is defunct.

Do we want to be plugging this option as if it was a 'core feature'? Or should it hang back as an addendum to the Scripting information?

If we want to mention it at all, is there a decently safe current source for custom skins?

When a mesh object with a transparent and partially shiny surface and refractive material are shaded from at least one of the primitive lights in the scene by another mesh object, the refractive properties of the material are ignored.

Since 3.0.

This is to continue the discussion that was started at #62. I think the new navigation modes could use some changes. Let me go through some of the issues I encountered when working with them.

In Fly and Drive modes, there are cue graphics that appear every time you move the mouse, then disappear after a few seconds. I see several issues with this:

• It's really distracting having the overlay constantly appearing and disappearing! It gets in the way of trying to do other things.
• The constant redraws hurt performance.
• It's only relevant to a very specific function (moving the camera along the z axis), so having it appear when you're doing other things isn't useful.
• It's not obvious what the graphics mean. For example, in Fly mode you get inner and outer circles, connected by a line passing through the mouse position, and a third smaller circle around the mouse position. Apparently the inner circle is to indicate the central dead zone, but what about the rest of them?
• It's not even clear to me that the graphics are useful. Users should be able to just think of it as, "Use the scroll wheel to zoom in on whatever the cursor is pointing at." And mostly, that seems to work pretty well. Perhaps having a central dead zone makes the behavior feel a little more natural, but there's no need to draw a circle around it.

Another question is whether we can make it more intuitive to the user what these modes mean. When I first saw a menu with the word "Tray" above every view, I didn't know what it meant. It wasn't obvious that had anything to do with navigation.

When you go into Fly or Drive mode, it disables the parallel/perspective menu and forces it to perspective mode. Why? Is there a reason these modes can't be used in parallel view?

In any case, there's a bug in the implementation of forcing it to perspective mode. Try the following:

1. Start out looking at a front view, parallel, tray mode.
2. Switch to fly mode. It disables the parallel/perspective menu and shows a perspective view.
3. Use the scroll wheel to zoom in and out a few times at different places.
4. Switch back to tray mode. It reenables the menu and claims to be in parallel mode, front view, but the view is obviously not correct. For example, I can see the sides of an axis aligned box!
5. Reselecting either parallel mode or front view doesn't fix it. But if I first select a different view direction (back view, for example) then select front again, that does fix it.

In current implementation the window layout saves in preferences on widget moving. This will save only the last moved scene window and not saves window layout for every scene separately

Just noticed something:

When editing a triangle mesh, you can hide parts of the mesh so they don't get in your way. If you do so, the center-click to adjust rotation center still triggers on the nearest part of the total mesh, even if that part is hidden.

For some reason, polymesh behaves better (triggers only on the visible parts of the mesh)