Selections-plugin problem

[Pete]

Hi.

We discovered that the Selections-plugin does not save the selection sets (and hence not any of the settings either) with 3.0-series. -- I can't say if this has been the case with earlier generations.

Myself I have not used used Selections lately so I did not notice. This came up when another user began to wonder about it.

-P-

[Pete]

Another question about the Selections: Cameras and lights can be locked by the Selections plugin and, when locked they can not be moved by mouse. However, they can be moved by views. Would it be possible to extend the locking to cover camera- and light views too?

-P-

[Peter Eastman]

I just tried adding a selection set to a file, saving it, and then reloading it. Everything loaded properly. This is with the latest version of the code. Could you describe how to reproduce the problem you're seeing?

Would it be possible to extend the locking to cover camera- and light views too?

How would that work? Suppose you lock a camera. Should it refuse to let you view the scene through that camera? Should the whole view be locked, so you can't move it? Should it switch to "other" as soon as you move the viewpoint?

Peter

[YardStick]

AoI 3.0.2 and 3.0.1 in Win 7 with 32 bit Java.

I created a scene with few objects in it, made a selection of them. Saved the scene, Closed AoI, Reopened it and opened the scenefile. --> Selections are gone and locked objects are unlocked. :/
It doesn't seem to save them in the .aoi file.

Maybe it's a windows issue?
Tho I think it worked with 2.9 or some other previous version, but I'm not sure about that.

---

About locking a camera or a light:
I think you should be able to see the scene through the camera or a light, but not be able to move it i.e. by scrolling on the view.

I often do several render passes of the same scene and then merge them together with gimp. Locking the camera 'for real' would be a convenient feature in that sense, so I don't accidentally change it's position or rotation between renders. :) In my opinion If I lock it, it should stay put, except if I have animated it and I move it through the score.

(That said, I can see how this could cause slight frustration in users unaware about this behaviour, so maybe it needs a popup message or some sorta notification, if one tries to move it through the view when it's locked. (?) Hard to say.)

[Pete]

Could you describe how to reproduce the problem you're seeing?

There is nothing special to it. Make selection sets. Save the file. Reopen, and the selection sets are gone.

It tried re-downloading the Selections.jar from http://aoisp.sourceforge.net/AoIRepository/Plugins/Selections/. It is from 2009-january_28, made for 2.7 and it is the latest I know about. That is where the SPManager is pointing too. No change.

Then I tried downloading the code from https://sourceforge.net/p/aoisp/code/HEAD/tree/Selections/ which seems to be the same version. I got it compiled, but that one won't even launch. The error message on SystemOut is.

java.lang.ExceptionInInitializerError
    at artofillusion.selections.SelectionsPlugin.processMessage(SelectionsPlugin.java:26)
    at artofillusion.ArtOfIllusion$1.run(ArtOfIllusion.java:289)
    at java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.awt.EventQueue.access$500(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.lang.NullPointerException
    at javax.swing.ImageIcon.<init>(Unknown Source)
    at artofillusion.selections.SelectionsPanel.<clinit>(SelectionsPanel.java:37)

I can't explain why yours is different than mine. Or should I be looking into some other location for the file?

---

Would it be possible to extend the locking to cover camera- and light views too?

How would that work?

When you lock an object on the scene, you do it, because you don't want to be able to accidentally move it by mouse. I'd follow the same logic with the camera views.

Should the whole view be locked, so you can't move it?

That's what I'd think. If there is a locked SceneCamera assigned with a view, then the rotate and move tools should recognize the locking. So basically you should be able to see and edit the scene through the camera view just normally, but not be able to turn or move the view (because that would change the position of the locked camera).

• The switching to other would be confusing. The user expects the camera view to be the camera view until he chooses to change it.
• The not viewing anything would just be -- ehhh -- impolite and unnecessary. Views are for viewing.

And as the locked objects can of course be moved by typing in new coordinates or by animation tracks, those operations should still be allowed. Just eliminating any mouse handling accidents is the idea.

One thing, that users might appreciate: If you repeatedly try to move a locked camera view, a warning that the camera position is locked, could pop up.

BR

-P-

EDIT: Ah -- while I was writing, the originator commented. :)
EDIT: ..call it linguistic...

[Pete]

Hi.

It seems that nothing has been done to this issue since it was brought up. I have been meaning to look into it but years just go by...

Well, what I found earlier is that the locked-parameter of ObjectInfo has never been saved in the scene, but that is not the problem with the selection sets.

I wrote a script that looks into metadata, where the sets are saved.:

• While the file is open and you create selection sets, the new sets appear into meta data.
• After opening a saved file the metadata key is there but there is no data. The list is empty.

The Selections plugin uses artofillusion.ObjectSet to create groups of objects, though the process looks pretty mysterious to me.... During session I can see a list of ObjectSets in metad ata and using getObjectIDs finds the ID-numbers in each set.

So it looks like either saving or reading the meta data fails. I have no idea where to look next.
--> @peastman?

[Luke S]

When saving a scene with a selection, I'm getting a couple of exceptions that seem to point to a missing persistance delegate for ObjectSet

So, as per current implementation, it simply discards the data.

[Luke S]

I'm also unsure as to why ObjectSet is part of the core package, as it's javadoc states that it is used when saving selections....

[Pete]

Could you post a build.xml that gets it compiled correctly. Mine compiles it but it won'd start and at least some of the probles seem to be related to incomplete compilation.

Found the build problem....

[Pete]

I'm also unsure as to why ObjectSet is part of the core package, as it's javadoc states that it is used when saving selections....

As I recall, the initial plan was that the capability would be built-in, but as Peter was not sure how the tool should work, he made it as a plugin that would be easier to replace with something else. -- True enough that, when I played with it bit now, some things could be improved.

But now the problem is entirely upside down. The plugin is working but the capability itself is broken.

The saving process gets to Scene, line 1682, encoder.writeObject(entry.getValue()); and then somehing goes wrong with the XMLEncorder. It actually reports a problem two different routes:

java.lang.InstantiationException: artofillusion.ObjectSet
Caused by: java.lang.NoSuchMethodException: artofillusion.ObjectSet.<init>()

and

java.lang.Exception: XMLEncoder: discarding statement ArrayList.add(ObjectSet);
Caused by: java.lang.RuntimeException: failed to evaluate: <unbound>=Class.new();

I don't understand, what is going on, but the PersistenceDelegate (what ever that is) and the XMLEncoder seem to be in an argument about who is to blame....

[Maksim Khramov]

Small code snippet to reproduce issue:
XMLEncoder hex = new XMLEncoder(new ByteArrayOutputStream(1000));
ObjectSet oss = new ObjectSet("oss", new ObjectInfo[0]);
` hex.writeObject(oss);
Deep inside XML EncoderPersistence delegate creates copy of writing object and expects that it has no-args constructor but ObjectSet has not such constructor... Simple adds no-args constructor to ObjectSet resolved this exception

[Luke S]

Those two exceptions are basically saying the same thing.

the XMLEncoder system requires that the encoded objects conform to the JavaBean conventions, so we need a no-argument constructor, even if we never use it for anything else. I suspect that that particular requirement is a retrofit, and that older versions of the Java libraries were a little more forgiving here.

This also means that we may need a setter for ObjectIds before it stops complaining.

Which puts me in a somewhat ambivalent state regarding this system. I've never been a fan of the JavaBeans thing, (Exactly because of this! It's API by convention, rather than by contract! There is no compile time checking to catch this!) but I'm not seeing any easy, convenient alternative.

[Pete]

A fix pushed. It also needed a set method for objectIDs. Without that the sets came back empty.

I'll have alook at the plugin too soon(ish). Currently, for one thing, it's a little too easy to destroy your carefully selected sets by accident ...

Which puts me in a somewhat ambivalent state regarding this system.

I actually had a look at this some time ago (thinking about saving physics data and sound tracks etc...). It seemed a bit tricky to use and I'm not sure if I like XML coding part either.... (that probably has seemed like a good idea at the time, but at least in written form I find XML to be a rather wasteful format, though I'd expect it to be more optimized in this context internally(??) )

Basically I'd miss an object type, that does not necessarily have to exisit as a 3D-object on the scene but could if needed, appear on the objects list, so you could access it easily. I don't remember all the detals but ther did not seem to be an obvious way of doing it with what is currently available. Some kind of a general DataWraper that could/should png (or zip or something) the data for saving but just simply save as is, without set/get methods ...

[Luke S]

XML can be verbose, but most "MetaData" type stuff is a fairly small amount of data. Also, the entire .aoi file is ZIP-compressed, which actually tends to compress XML fairly well.

I'd hesitate to use XML for big batches of numeric data, such as baked physics data. (though it might be okay for, say, per-joint mass data, etc)

(This concern was the reason for [c6349728ca] )

Deltor used the "Object that Isn't" for his physics/fluid solver - Each physics space had a basic wireframe, and generated a rendering mesh from fluid data, but only if there was actually fluid to render. The actual baked data he kept in an external file, very like the linked images that you were so kind as to implement.

Some kind of a general DataWraper that could/should png (or zip or something) the data for saving

So, kind of a reserved area where "Plugin Things that aren't Object3D" can dump their own binary serialization? Have to think about the ramifications here. As I currently am modeling it in my head, there are several types of data:

• MetaData: Lightweight status stuff, such as selections. (Basically anytihing that could be concieved as adding to the types of options that you would generally edit through Scene, View, etc. menus)
• Foreign Data: Anything that is only read in for reference or to drive an AOI process, but is not directly edited by AOI. (Video Streams as used by VideoMediaFrame, for example. I'd put audio streams in this category as well.)
  • These data should not be saved in the .aoi file, as they generally have their own, well specified, efficient data formats. Instead the plugin that handles them should keep a reference to an external file of appropriate type. Whether this reference should be saved as metadata, or a (non)object will depend on the plugin.
  • Possibly large batches of plugin-produced data should be handled this way as well, such as baked-in physics sims. Especially if the data will only ever make sense to the plugin that generated it.
• Wrapper Data: Data tied tightly to the structure of an existing AOI Object. Things like multi-joint bone mappings. These need to be edited any time the associated mesh changes topology, and directly influence things like skeleton pose tracks. Not sure the best way to go, see [c6349728ca] for a couple of the approaches that I've considered.

[Luke S]

Would also like to know what you needed to do to sort out the build issues. Was it something with the plugin code itself, or just configuration?

[Pete]

There is no build.xml in the plugin 'trunk', so I copied and modified one, that I had for somehing else. Took a moment to get it right. File structres of plugins tend to vary and some xmls tell to copy filesets to 'build' and some instruct to read them from wheer they are and so on...

[Luke S]

Yeah, I'd kind of like to settle on a standard "Best Practices" plugin structure, at least for plugins that are maintained by those of us who work on the core project.