Skip to main content

How do dynamic generation a Feature in GRIN.

3 replies [Last post]
Joined: 2010-03-03

Hello. guys.

I have a basic question.
I want to do dynamic generation a Feature in GRIN on BD-J.
So, has someone done it?
and, Please tell me if you know the thing which is useful for this case.

Thank you.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-11-08


Try looking at xlets/grin_samples/GrinBunny - it's Bill's example where the 8 saucers are dynamically generated during game initialization time. I followed this example recently for my scroll list need and it worked well.

In general, I found it much easier to have the features pre-defined and then modify certain values of a feature at runtime (like swapping image for fixed_image or changing the location of an feature via InterporatedModel) as opposed to trying to modify the show graph structure itself at runtime. The GrinBunny example isn't about random feature generation (I don't think we want to have all the show structure validation at runtime). But the example shows that one can clone certain subgraph of the show and then modifying cloned subgraph's values.


Joined: 2004-02-13


The idea behind only supporting "clone" well (and not arbitrary feature generation) was that we wanted to bias the system toward declarative constructs. A procedural view of graph construction would be to write code that generates the graph. A more declarative approach is to provide a declarative syntax to create an exemplar of the structure you want, and then use just a bit of procedural code to clone that structure, and to destroy the clones when you're done with them. That's what we did.

So, for example, in grinbunny_show.txt you'll see the feature F:TurtleTrooper. It's not just a feature, it's a graph of features, including an assembly (to model the visual states of one of the troopers), a translator (to move it around), and a collection of images (to show the different states). The code in the director doesn't need to care about the precise visual layout or internal structure of all this; all it needs is a naming connection to get the "handles" it needs, like "how do I move this?" and "what do I do to change the visual state?" So, with this style, you get a pretty nice decoupling between the visual elements and the logical elements.

For example, if we wanted a more extensive explosion animation, we could just swap in an image_sequence for the fixed_image used for the "blam" state, when the trooper is hit.

In the code, the F:TurtleTrooper feature has cloneSubgraph() called on it for each clone the director wants to manufacture. Thus, F:TurtleTrooper is an exemplar, that is, an arrangement of nodes that is used as a template by a factory to make clones of that graph structure. In essence, Feature.cloneSubgraph() is a factory method for creating graph structures specified by the Feature, which plays the role of exemplar.

One benefit of using cloning for feature generation is that, because the exemplar (the template) is still declarative, and evaluated at compile-time, you get to benefit from the compile-time validation of the structure. Systems that let you do arbitrary run-time generation of graph structures are usually either prone to programmer error leading to invalid graphs, or they contain expensive run-time error checking code to validate the graph structure at runtime. GRIN is heavily biased to maximal runtime efficiency, so avoiding that kind of validation code at runtime is a Very Good Thing.



Joined: 2010-03-03

Your useful advices made my issues settle.
Thank you very much!