Re: Inlining, name scoping, defining

Linas Vepstas (
Mon, 17 Oct 1994 19:18:52 -0500

Hi again,
Sorry it takes so long to respond ... today, I got lost
exploring the sound clips on hyperreal.

>From: "Gavin Bell" <>
>Date: Wed, 12 Oct 1994 13:38:45 -0700
>Subject: Re: Inlining, name scoping, defining

[question about DEF/USE scoping deleted]
>DEF/USE (as currently implemented in Inventor) is restricted in scope
>to a single file. It is impossible to DEF an object in one file and
>USE it in another.

This may be a reasonable limitation, but I'm not sure I buy
the arguments below.

>If you allow objects to refer to objects in other files, it is possible
>for a user to:
> --- read in a scene
> --- interactively edit it in memory
> --- be unable to write the scene back out

I'm not sure I beleive this. I begin by noting:
(1) I can't edit other peoples html doc's and write them
back (unless they grant me authority).
(2) The problems of maintaining various parent/child,
tree/traversal relationships you touch on below
are not unique to 3D, but occur in any 2D hypertext
system. (In particular, look at multiple, linked
(financial) speardsheets.)

>For example, imagine that a user reads in this scene:
> Separator {
> File { name "CoolMaterials.vrml" } # Contains DEF Gold
> USE Gold
> Cube { }
> }
>The user interactively rearranges the scene so that the gold cube comes
>before the File { } node. That is no problem for an in-memory scene,
>since the USE Gold is really just a pointer to the gold Material. But
>Inventor will write out the scene as:
> Separator {
> DEF Gold Material { .... } # First use of gold material
> Cube { }
> File { name "CoolMaterials.vrml" } # hmm....
> }
>Either "CoolMaterials.vrml" has been rewritten with a USE Gold in it

You mean DEF Gold ? I agree writing USE Gold would be bad.

>(very bad), or the user has unknowingly stopped using the version of
>Gold in CoolMaterials (bad). There are several variations on this, the
>worst being when you construct an in-memory scene graph with two File
>nodes that share nodes.

I guess I don't understand why the scene editor couldn't have
written out the new definition of Gold to the "CoolMaterials.vrml" file.

A good user interface might inform you about the situation.
When you go to edit "Gold", it pops up

This color (Gold) is defined in another file.
Do you wish to continue?
[] No, don't continue
[] Yes, continue and replace the defniition of
Gold in CoolMaterials.vrml
[] Yes, continue, and create a local defnition of
Gold (the definition in CoolMaterials.vrml will no
longer be used.)

Or maybe it will check file permissions before starting
the edit:
You do not have authority to modify the file
"CoolMaterials" which contains the defnition for Gold.
Do you wish to continue?
[] No, don't continue
[] Yes, continue, and create a local defnition of
Gold (the definition in CoolMaterials.vrml will no
longer be used.)

You could allow the user to customize default repsonses
to these popup dialogues, so that the user wouldn't have
to be annoyed by having them pop up over & over.

So I guess I don't see what the problem is.

(As to implementation details -- internally, in the C++ code,
or whatever, you'd have a flag in each node, the flag pointing
at the file from which this node was fetched. The editor would
check this flag before editing, so that it could pop up