• Hello Guest!

    We have recently updated our Site Policies regarding the use of Non Commercial content within Paid Content posts. Please read the new policy here.

    An offical announcement about this new policy can be read on our Discord.

    ~The VaMHub Moderation Team
  • Hello Guest!

    We posted an announcment regarding upcoming changes to Paid Content submissions.

    Please see this thread for more information.

Look distribution in VARs

JayJayWon

Well-known member
Featured Contributor
Messages
554
Reactions
1,710
Points
93
Patreon
JayJayWon
Why are nearly all looks distributed as a VAR containing a scene?

I get that creators want to demo their looks in a nice environment with lighting, but with the majority of shared content being Looks you end up with loads of "Scene" VARs that only contain a character with a look and no easy way to apply that look in another scene. If you create an Appearance Preset it references that VAR with the scene in, so you can never delete the Scene without breaking the Appearance Preset.

It would seem to me, that it would make sense for Look creators to distribute two (or more) VARs per Look:
  1. Appearance VAR containing just:
    • Appearance Preset VAP file
    • Person Textures
    • Morphs
    • Hair
    • Clothing
  2. Demo scene VAR containing:
    • Person with the appearance preset applied from the first VAR
    • Lighting
    • Scene environment
    • Plugins
    • etc
The Textures, Morphs, Hair, Clothing in the Appearance VAR could (or even should) be broken out into separate VARs (either from this Creator or other Creators if available by VAR).

I dont create and distribute Looks - so I may be missing something?
 
IMO - a look VAR should contain both appearance presets and a demo scene. The scene file is small and is great to include to show off the look and match the preview images. I do agree the scene should not require any additional assets. It should just use built-in lights, environments, furniture, otherwise that is just creating unnecessary dependencies on the other VAR packages or additional packed-in assets adding to the size.
 
IMO - a look VAR should contain both appearance presets and a demo scene. The scene file is small and is great to include to show off the look and match the preview images. I do agree the scene should not require any additional assets. It should just use built-in lights, environments, furniture, otherwise that is just creating unnecessary dependencies on the other VAR packages or additional packed-in assets adding to the size.
Well at the moment almost no one is including Appearance Presets - we just have a lot of scenes containing a person with a customised look and often a bunch of other content.
Its not the size issue that bothers me so much, its the organisation of scenes from VARs. When I "Load a scene" the Shortcuts list is useless - it just lists every scene - which for me is now 90% these "Look preview scenes". Really I only ever want to load these "Look preview scenes" once and decide if the look is a keeper or not - I then want to delete or hide that scene somehow. I know we can organise our VARs in folders and then navigate by the "AddOnPackages Filter" but that folder navigation gets a bit messy because every folder is listed whether it includes a scene VAR or not. The main Shortcuts functionality is rendered pretty ineffectual.

I think the big win would be if look creators include Appearance Presets in their Look VARs. The rest is probably workable as is.
 
Last edited:
I have been wondering about that issue with the Looks , it Makes Sense to include Appearance Preset , so the user can use a character Look in their own scene , i Will make that standard when i upload any Looks , A demo image with scene just to show the character in an environment, but the file only includes the character Look not the scene , as that's the point of The Look .
 
I just save a new appearance preset if I like the look. But yes 100% they do crowd the scene folder up (already a PITA to sort through). pre packaged with appearance presets (Or looks i'm still confused as to the difference) would be very nice.
 
Last edited by a moderator:
All my look vars have included appearance presets and morph presets, and sometimes hair presets, in addition to the scene containing them. A few of the earlier ones even had look json files in addition to these but I haven’t bothered with them on the last few.

As far as environments I have only used built in stuff. Same for any where some clothing items were involved. Dropping the scene from the var and making it available separately isn’t a terrible idea, though it would require a few extra steps. It technically wouldn’t even have to be part of a var, You could just attach a separate json that references the var 🤔
 
Last edited:
So I built a feature into UIAssist v1.6, that helps a bit with this. Now my AddonPackages folder looks like this:
1594843981813.png

You can make UIAssist do a Load Scene where it will only show shortcuts from a specified subfolder in AddonPackages.
For example, this folder contains the following VARs:
1594844111462.png

And Scene shortcuts using a UIAssist Load Scene button are just from those VARs (filtering out all the "look preview" VARs in another folder):
1594844467015.png
 

Attachments

  • 1594844222251.png
    1594844222251.png
    67.3 KB · Views: 0
I have my addonspackages folder organized by creators. Would be nice if that organization showed up inside of VaM though.
 
The problem with organizing files is that in the future, if you download additional VARs, they generally just dump into \addonpackages - and you're right back where you started. The organization of VAM contents is really a mess. Hopefully 2.0 fixes that and gives an organization hierarchy a little more like DAZ3D's - which isn't *perfect* - but has a lot of advantage over VAM's approach.
 
When I unpacked all the var files, I had about 20 GB of duplicate files. I think the look var file should contain only unique content, otherwise dozens of files may contain the same hairstyles and clothes. I think all dependencies should be either in the form of links to the originals, or as a separate package. Moreover, demo scenes contain not only unnecessary content, but also unnecessary plugins.
 
Back
Top Bottom