Organising art work into groups

[GoogleCodeExporter]

What would you like to see changed/added?
For example a wardrobe of clothes. Each art asset can be part of a group 
or wardrobe that can be identified in an editor instance more easily e.g. 
normal clothes group/wardrobe, superhero clothes group/wardrobe etc.

How will this help you accomplish your goals?
Make it easier to separate art assets into a more coherent structure

What version of the product are you using now?
Latest 5.5

Please provide any additional information below.
Working well so far - would just like to see if this is possible or can I 
implement this myself another way?

Original issue reported on code.google.com by mediamou...@gmail.com on 16 Feb 2010 at 3:55

[GoogleCodeExporter]

Have you looked into using the style property in Art and artStyle in Feature? It
seems they may help facilitate your need. Otherwise what you need is to change 
out
your library.  Having separate wardrobe libraries will let you swap out one 
clothing
group for another.  Given how many "groups" you have, it may require multiple
libraries and stitching those libraries together to make a final library.  
That, I
don't think, is exactly easy to do ATM, but maybe Collection.copyCollectionFrom
doesn't have to be destructive. This would allow you to create a new, empty 
library,
then call copyCollectionFrom on it with each library you need to stitch 
together to
make the current usable set.

Original comment by senocu...@gmail.com on 16 Feb 2010 at 5:54

[GoogleCodeExporter]

Original comment by senocu...@gmail.com on 16 Feb 2010 at 5:57

• Changed state: NeedsInfo

[GoogleCodeExporter]

Thanks for the quick feedback. I'll have a go at setting style and artStyle 
properties and see if it does the job and if not I'll get back to you.

Original comment by mediamou...@gmail.com on 17 Feb 2010 at 8:42

[GoogleCodeExporter]

MAELite in the examples utilizes styles. It may be useful as a reference.

In the mean time, I'm implementing the change to copyCollectionFrom so the 
library
approach would be easier.

Original comment by senocu...@gmail.com on 17 Feb 2010 at 3:45

[GoogleCodeExporter]

Another thought on having wardrobe-specific libraries. Instead of merging 
libraries
into one for a single avatar, you can also keep separate avatars - one for the
character models, and one for the clothing.  Then you simply change the library
linked to the clothing avatar (which only contains clothing) to change the 
wardrobe
used by the character.

Original comment by senocu...@gmail.com on 20 Feb 2010 at 5:59

[GoogleCodeExporter]

Thx for the suggestion however I'm letting my users take items of clothing from 
multiple wardrobes if they desire e.g. a Batman mask with a superman cape and a 
pair 
of Nike trainers so I'm not sure this approach will work.

I'm thinking the best approach is a 'super' library with all art objects in it 
divided into wardrobes and groups within the wardrobes so when a user sees 
their 
Avatar it actually pulls down this xml file as a reference of the art objects 
that 
make up their Avatar. Does this make sense or can you see an easier way of 
doing it?

I'm going to use the style property of each art object as a wardrobe id to 
divide it 
into wardrobes and groups that will tie in with another xml file as a reference 
for 
the Editor to display wardrobes names, groups and then each art group in each 
wardrobe.

Phew! Hope some of that makes sense ;)

Jonathan

Original comment by mediamou...@gmail.com on 21 Feb 2010 at 10:52

[GoogleCodeExporter]

Generally there would be one library. And your description sounds pretty 
typical,
like you only need one library - this assuming you only allow one mask and one 
cape
(etc.) at a time.  Then you'd have FeatureDefinitions set up for each. For 
example,
you'd have a mask feature and a mask definition. The definition would contain 
all
different types of masks (batman, the flash, green lantern, etc.) and users 
could
select from each of those to select which mask to wear.

I guess the problem you're having is organization.  The current design favors
variations of a feature being grouped together, not collections of features.  
If I'm
understanding correctly, you want to present to the user all of the options from
batmans wardrobe at once, or all of the options from superman's wardrobe at 
once,
etc.  These may or may not consist of the same features, or even relate to 
entirely
different features.

My idea for handling this revolved around naming schemes. If you want to 
display art
from a specific "group" such as all the art associated with batman, then you 
would
want to name all your art with a prefix or something, e.g. "batman:mask".  Then 
you
can go through all your art and pick out those with that prefix to find all of
batman's wardrobe.

Having said that, it's probably not the easiest approach, nor is it apparent as
solution to this problem.  So maybe a group or tag property in Features can be 
used
to help isolate those particular collections.  

Feature-based grouping, however, would not help you at the
FeatureDefinition.artSet.Art level, though.  As I was explaining before,
FeatureDefinitions contain variations for a particular feature, such as 
different
kinds of masks for the mask feature. This would, in your case, potentially 
include
every mask of every character.  And if you want to show what options are 
available
for a certain character, that would have to include knowing each art of each 
feature
definition.  So there, art groups would be appropriate. But with the 
combinations of
other variations, it could get messy... I'll have to think about this one a 
little bit.

Original comment by senocu...@gmail.com on 21 Feb 2010 at 5:36

• Changed state: Accepted