Dealing with reference loops about artofillusion HOT 7 OPEN

Hmm... I remember that discussion. What I'd like to do is prevent circular references in the first place...

from artofillusion.

Well, technically this is not a circular reference. None of the objects or values have references back to themselves.

This is a bit of unorthodox thinking but actually it might sometimes make sense to model a set of things Ax in scene A and things Bx in scene B and have, lets say A3 vistit scene B while B5 is appearing in Scene A. Think the scenes as two neighboring towns. Friends visit friends. As long as the initial Java session is up there is no problem. The only problem here is the opening sequence that does not realize that it is trying to ropen an already opened a file.

In CAD systems a circular reference happens when a value would depend on itself:

d1 = 1.2;
d3 = d1 + 0.5;
d3 = d2 × 0.3;
d1 = d3 + 0.7; // Circular reference detedctor prevents the user form setting this value

Circular reference detection must be recursive and sometimes the chains can be very long traveling between objects. It's up to the user to keep the refernce hierarchy clear and as much top-down as possible, always favoring the original dimension, (preferebly set in a skeleton file) rather than having assembly parts depending on each others.

Usually there is a way to disable adaptivity, when assemblies are collectet from parts that have dependencies. (If you forget adaptivity on, some very disturbing things can happen, when you move the parts :D -- been there.)

So, basically I'd allow this, just making sure the user can get the files opened.

from artofillusion.

...and continuing...

In CAD-world there also is another possibility to (try to) create a circular reference.

There every part (3D object) is saved as a file of it's own. An assembly (like scene) contains references to parts or other assemblies. Now several assemblies may refer to the same part or assembly and a part or an assembly can appear as several instances in an assembly. So if assembly B contains assembly A and assembly C contains assembly B, that is OK, but if the owner of assembly A takes a short cut and adds assembly C instead of picking the parts he needs, circular reference detection prevents it. To get everything collected together it is possible to create assembly A2 that contains the original A and C that contains B that contains A.... (The last A may be a bit of a thorn in the buttock, but some times you just have to deal with it.)

In AoI the philosophy is entirely different. Objects do not exist outside scenes and it is not possible to add (a reference of ) a scene into another scene, which means that this kind of a circular reference is not possible.

from artofillusion.

But this is not a circular reference issue:

d1 = 1.2;
d2 = d1 + 0.5;
d3 = d2 × 0.3;
d1 = d3 + 0.7;

It's an immutable value issue. Much like final in java.

This:

d1 = 1.2;
d2 = d1 + 0.5;
d3 = d2 × 0.3;
d1 = 5.7;

Would be equally illegal, because d1 has already been initialized.

from artofillusion.

Actually no. This is not program code (the semicolons should not be there but that happens a kind of naturally.. :) ).

Those are dimensions or parameters that co-exist. When I change one of them all of them are refreshed (updated if necessary and the model is redrawn in it's new appearance). Typically the naming is based on numbering in chronological order of creation but in their logical structure they don't have to follow the order they were created in. I can give any of them a new value that also may be a formula containing references to other parameters, as long as the concatenated formula does not refer back to the parameter it defines.

A pretty typical way to proceed is that first you just give them rough numbers and then work out the dependencies. It may start like

d1 = 1
d2 = 2
d3 = 0.7

and after a while the list may look like:

d1 = d3*2
d2 = d3*3
d3 = 0.8
d4 = d3 * 0.5
d5 = d4
// d6 was deleted
d7 = d4

That was the idea.

from artofillusion.

Ahh... makes sense in that context.

I'm going to have to think about this a bit. I'm still skeptical of trying to support loops like this.

What if A includes an object from B that tries to include all of A? Somewhere, we'll have to draw a line on what kinds of loops are okay. Otherwise, there will always be the possibility of infinite-loading loops. I think that disallowing at the file level might be the simplest to implement.

from artofillusion.

What if A includes an object from B that tries to include all of A?

That still does not create a circular reference but obviously there would be other kinds of problems. The external object links find the original object in the end of the chain of links. What I got was the last saved version of the object through the external link to an external link. The chain stops when it finds the actual object. Things get jammed when you try to save and update things. The linked-linked-object naturally does not know about the changes that you do to the original object. When you save it, there is no way to read it again from the file without getting into the opening loop. At least I think it was the same open-open-loop -- there might be something else going on too.

CADs have an update button for this purpose (there are automated updates but only for the most obvious things). It's an issue separate from the file opening loop but I think we should add a "Refresh links" beside the external object link.

EDIT: One possible and IMO reasonable thing to do would be to prevent relinking of external objects. They could be appearing on the list but marked 'external' and/or filename + name or something like that. (If it's not available, let the user know where to find it.)

EDIT2: Or even better, link directly to the original object, not through chain... I don't remember how it works but all the necessary information is there already.

from artofillusion.