Two things I wish creators would STOP doing

VAMIC

Well-known member
Messages
307
Reactions
436
Points
63
1) Using Anti-Aliasing in MacGruber PostMagic without warning. I don't know the breakdown of VR vs. Desktop users, but I presume the majority skews slightly toward VR users. As such, it would be amazing if creators could have Anti-Aliasing and Depth of Field turned off by default in every scene to accommodate the most likely users of their scene or at least indicate in the scene description that MacGruber's PostMagic is enabled and which atom to find the plugins. It is incredibly grating to have to search through the Person plugins, the scene plugins and everywhere else desperately trying to disable this setting so you're not getting double vision. I suspect some creators who don't use VR maybe aren't aware of how destructive this is to enjoying your scenes and looks so I figured I'd mention this. It's also possible there's a way to keep the @MacGruber settings intact and still enjoy VR content, but I can't figure out how if so. When I first started using VAM, there were many scenes I deleted and never went back to because I just figured they were "broken" and it took quite awhile to figure out what was going on, mostly through reading random posts about others not sure why they were getting double vision or a blurry image. So PLEASE either identify that you're using anti-aliasing especially or have it disabled. Having a button to easily turn plugins on and off doesn't really help because when you're in a double vision image, it's almost impossible to click said button. Bottom line: It's easier for a Desktop user to enable/disable plugins than it is for a VR user to turn them off even if it delays your desired presentation.


2) Using basic clothing items that are 100 MB+ on looks. I know this is down to personal preference, but sometimes a creator will have a great scene that clocks in around 2 MB but then have dependency clothing items that are 100 or 200 MB and they're just a basic bikini or shorts that could easily be replaced by something similar that's smaller. Because VAM hogs a lot of resources on one's computer, after awhile, 100+ MB clothing items, scenes or assets in the dependencies can be enough of a reason to not download a look or scene. Obviously it would be great if everyone made slimmer files (@GMAN749 is a wizard at this somehow), but sometimes it's just not possible because of physics or textures on clothing. And large clothing files are often awesome! But when it's a pair of underwear or a swimsuit or a basic skirt and halter top combo, it just seems excessive when there are plenty of smaller alternatives. Spending drive space on Skin Textures is accepted because we know in order to get closer to realism, it requires a lot of detail. It's similar with special clothing like armor or a custom costume, but if you just have your model in something skimpy, it's easy to get skipped over because of size. Of course, a user can just download a scene without the clothing, but that requires knowing what's what in the dependency list which takes a bit of experience. Relatedly, when downloading from the in-game Hub, the size of scenes and dependencies is available, but not when downloading from here on the Hub website from Desktop, which is often just easier and faster. @meshedvr is there any way for the website to display file sizes when viewed through a browser or is that site breaking?

Feel free to ignore these wishes creators, but I just figure it may help more people engage with your work if there are as few barriers to enjoying it as possible. For new users who may be wondering why so many scenes seem broken, they're not! You just have to hunt for that one plugin and disable it.
 
Some notes on PostMagic vs. Anti-Alias:
  1. PostMagic Anti-Alias works just fine in VR for me. Just TAA doesn't work (as the documentation says), but it should automatically disable itself in VR and switch to FXAA.
  2. There should be no reason to even ship scenes with PostMagic Anti-Alias enabled. The reason this effect even exists as option is that on extremely low-end machines it might give you slightly better quality than having MSAA completely disabled or only running MSAA 2x. Most machines these days shouldn't have trouble running at MSAA 4x or 8x even in VR. All PostMagic's effect implementations are based on extremely old stuff that's hidden within VaM and can't be improved. I don't actually use PostMagic myself because the quality is so terrible :ROFLMAO::ROFLMAO:
  3. Different settings in VR and Desktop for anything, not just PostMagic, can be achieved via LogicBricks. Add two "EventSceneLoad" bricks to your scene and have one trigger in VR, the other in Desktop and just change the settings you need changed.

The most likely cause of "double vision" are assets imported incorrectly from Unity Editor. There are certain project settings that are needed to have them work in VR.
 
Actually just noticed that some admin secretly put this note on PostMagic's Hub resource page. Had not looked at that in 3 years ?
Admin Note: This plugin is specifically made for desktop use and as stated in the description only partially works in VR. If you wish to not have this plugin loaded at all you can permanently disable it from within the "Package Manager".
 
Some notes on PostMagic vs. Anti-Alias:
  1. PostMagic Anti-Alias works just fine in VR for me. Just TAA doesn't work (as the documentation says), but it should automatically disable itself in VR and switch to FXAA.
  2. There should be no reason to even ship scenes with PostMagic Anti-Alias enabled. The reason this effect even exists as option is that on extremely low-end machines it might give you slightly better quality than having MSAA completely disabled or only running MSAA 2x. Most machines these days shouldn't have trouble running at MSAA 4x or 8x even in VR. All PostMagic's effect implementations are based on extremely old stuff that's hidden within VaM and can't be improved. I don't actually use PostMagic myself because the quality is so terrible :ROFLMAO::ROFLMAO:
  3. Different settings in VR and Desktop for anything, not just PostMagic, can be achieved via LogicBricks. Add two "EventSceneLoad" bricks to your scene and have one trigger in VR, the other in Desktop and just change the settings you need changed.

The most likely cause of "double vision" are assets imported incorrectly from Unity Editor. There are certain project settings that are needed to have them work in VR.
Thanks for the reply. Due to using LUT a lot, I can't ever permanently disable it, but it's good to know it's solvable.
 
Different settings in VR and Desktop for anything, not just PostMagic, can be achieved via LogicBricks. Add two "EventSceneLoad" bricks to your scene and have one trigger in VR, the other in Desktop and just change the settings you need changed.
can you share your VR settings, please?
 
100% agree on not wanting 100MB+ clothing items just for a simple demo or model showcase scene. I would put the spaceboxes in that category too. Yes, if you're creating an environment for a detailed scene, they're great, but for a simple showcase, they are just dead weight, IMO. Better to use an image panel with a link to a nasa.gov image for a background.
 
I'm glad to hear i'm not the only one that gets infuriated by the double vision thing. Chasing down where the heck is the plugin to disable AA and DOF ruins my day.
 
As a clothing creator you have to balance fidelity, customization, size, ease of use, and not flooding the hub with thematically similar items. One of my recent releases is a 171mb var file, probably closer to 300mb when extracted because it is 4 peices and each has multiple presets.

So I could separate them into three separate releases but if I did that I would have release days where I am releasing so much that the front page of clothing would be mostly me. And if everyone did that the hub would become a bit of a mess. So we all sorta have an agreement to try and group things that are thematically similar or part of the same outfit so all of our stuff can be seen.

The file size of a custom clothing item is high as a base. This releases top alone clocks in at 20 something MB and only has 2 presets one of which is simply a base color change. A single map at 4k clocks in at about 3.5mb.

We could lower the image size but the quality takes an absolute dive of a cliff below 4k. When you start changing materials like from fabric to plastic you start adding 5 new maps and its very easy to start pushing up into the 200-400mb range.

Something that could be done is adding something to VaM to optimize images. Any plugin developers that want to take a crack at that monster would be heros. But even then, running the fire top through the optimizer only shaved off about 25% of the files size. So that would take some of the larger releases from 400 to 300mb. Getting any clothing item below 100mb would require a severe decrease in quality.

Original:
RGB.png
Optimized:
Optimized-RGB.jpg

I agree that VaM can get very big on the hard drive but I think that is just the nature of the beast. My releases alone (including un released stuff but still) is over 8.5 GB of images and vam files.
 
As a clothing creator you have to balance fidelity, customization, size, ease of use, and not flooding the hub with thematically similar items. One of my recent releases is a 171mb var file, probably closer to 300mb when extracted because it is 4 peices and each has multiple presets.

So I could separate them into three separate releases but if I did that I would have release days where I am releasing so much that the front page of clothing would be mostly me. And if everyone did that the hub would become a bit of a mess. So we all sorta have an agreement to try and group things that are thematically similar or part of the same outfit so all of our stuff can be seen.

The file size of a custom clothing item is high as a base. This releases top alone clocks in at 20 something MB and only has 2 presets one of which is simply a base color change. A single map at 4k clocks in at about 3.5mb.

We could lower the image size but the quality takes an absolute dive of a cliff below 4k. When you start changing materials like from fabric to plastic you start adding 5 new maps and its very easy to start pushing up into the 200-400mb range.

Something that could be done is adding something to VaM to optimize images. Any plugin developers that want to take a crack at that monster would be heros. But even then, running the fire top through the optimizer only shaved off about 25% of the files size. So that would take some of the larger releases from 400 to 300mb. Getting any clothing item below 100mb would require a severe decrease in quality.

Original:
View attachment 221107
Optimized:
View attachment 221108

I agree that VaM can get very big on the hard drive but I think that is just the nature of the beast. My releases alone (including un released stuff but still) is over 8.5 GB of images and vam files.
Just to be clear, I think large file sizes on clothing is absolutely acceptable and totally needed. What I'm talking about is creators who make scenes where their creation is simply wearing a set of underwear or a simple skirt and top and the creator is not attentive to the fact that the file size on that clothing is so large. You make the kind of clothes that are specialized and if a character is wearing them I expect that it says something about the character. Some others make clothing that is just pretty to look at and matches a character who is beautifully rendered. But sometimes people opt for something huge just to show off a look when the clothing doesn't really add much to the character and just looks nice. My contention is that if someone isn't presenting a whole character backstory where the clothing is saying something particular, it would be nice if people just went for smaller clothing items.
 
I understand your concern/frustration. I just don't think smaller clothing items are viable. Clothing creators want to cast a large net so will create high quality multiple preset clothing then look creators want a good thumbnail and reaction so will add clothes that help sell their look. Even in the free section creators want attention and will do everything we can to maximize the attention we get.

I agree that file size is a problem, but I think it is probably more of a technical issue to be tackled than an issue of which clothing creators use. I'll experiment with what I can find to lower the overall wieght of clothing. If I find anything ill be sure to share it on the forums.
 
I think was is missed in this discussion is that a "Look" should not include clothing in the first place. Anything that's an "Asset" and not a "Scene" should only include that asset (i.e. the morphs and textures you made for the Look), nothing else. As a second VAR package you could then have a demo scene what you can go all crazy and have any dependencies to show off your work. For a resource here on the Hub you can upload multiple files for the same resource, so use that!

Example from popular LogicBricks:
  1. The main package is only 82kB. There are no scenes or anything that would clutter up your various asset browsers in VaM. No dependencies either. Just the plugins.
  2. As a separate package there is a demo VAR where you have 4 scenes with various dependencies. If you don't want them to clutter up VaM, just don't install the demo. That's >90% of all VaM users who are just consumers and not creators, they only have LogicBricks because some other scene uses it, not because they use it themselves.
  3. Again, the dependencies in this case (Life, IdlePoser and Essentials) each have their own demo scenes, again with their own dependencies. Because they are also in separate VAR packages you don't need them and their dependencies just to run the LogicBricksDemo scenes.
  4. Another benefit is also that I can actually use LogicBricks in the demo for Life...without having everything in the same package.
=> While its also important to not split your stuff into too many small packages, it's also important to split assets from demo scenes. That's how you break the endless chains of dependencies you don't actually need!

1678429570917.png
 
I think was is missed in this discussion is that a "Look" should not include clothing in the first place. Anything that's an "Asset" and not a "Scene" should only include that asset (i.e. the morphs and textures you made for the Look), nothing else. As a second VAR package you could then have a demo scene what you can go all crazy and have any dependencies to show off your work. For a resource here on the Hub you can upload multiple files for the same resource, so use that!

Example from popular LogicBricks:
  1. The main package is only 82kB. There are no scenes or anything that would clutter up your various asset browsers in VaM. No dependencies either. Just the plugins.
  2. As a separate package there is a demo VAR where you have 4 scenes with various dependencies. If you don't want them to clutter up VaM, just don't install the demo. That's >90% of all VaM users who are just consumers and not creators, they only have LogicBricks because some other scene uses it, not because they use it themselves.
  3. Again, the dependencies in this case (Life, IdlePoser and Essentials) each have their own demo scenes, again with their own dependencies. Because they are also in separate VAR packages you don't need them and their dependencies just to run the LogicBricksDemo scenes.
  4. Another benefit is also that I can actually use LogicBricks in the demo for Life...without having everything in the same package.
=> While its also important to not split your stuff into too many small packages, it's also important to split assets from demo scenes. That's how you break the endless chains of dependencies you don't actually need!

View attachment 221241

I agree in the theoretical. Looks should just be morphs, clothes should be clothes, and assets should be assets. But there is the social aspect of creation in VaM. Creators will use each others stuff both to increase the value of their release and as a nod or as support to another creator.

But your insight and explanation on how you do it is really interesting. I create for VaM but don't actually use it that much. I'd never have thought to include multiple packages in a single release like that. That would solve the problem. Thanks for bringing that up. I think if there was a way to set that up easily it would def solve the problem of VaM folders exploding in size.
 
I think was is missed in this discussion is that a "Look" should not include clothing in the first place. Anything that's an "Asset" and not a "Scene" should only include that asset (i.e. the morphs and textures you made for the Look), nothing else. As a second VAR package you could then have a demo scene what you can go all crazy and have any dependencies to show off your work. For a resource here on the Hub you can upload multiple files for the same resource, so use that!

Example from popular LogicBricks:
  1. The main package is only 82kB. There are no scenes or anything that would clutter up your various asset browsers in VaM. No dependencies either. Just the plugins.
  2. As a separate package there is a demo VAR where you have 4 scenes with various dependencies. If you don't want them to clutter up VaM, just don't install the demo. That's >90% of all VaM users who are just consumers and not creators, they only have LogicBricks because some other scene uses it, not because they use it themselves.
  3. Again, the dependencies in this case (Life, IdlePoser and Essentials) each have their own demo scenes, again with their own dependencies. Because they are also in separate VAR packages you don't need them and their dependencies just to run the LogicBricksDemo scenes.
  4. Another benefit is also that I can actually use LogicBricks in the demo for Life...without having everything in the same package.
=> While its also important to not split your stuff into too many small packages, it's also important to split assets from demo scenes. That's how you break the endless chains of dependencies you don't actually need!

View attachment 221241

This is a good point about separating assets and scenes and I've thought that as well recently regarding my resources.
One thing I realized is that on the hub UI it does not separate out the dependencies for multiple files like it does in the in-game hub browser.
So it is a bit confusing for some users, see LogicBricks has 4 dependencies according to hub:
1678517477149.png


I separated out a plugin preset and demo scene for this resource, and one user commented about the number of dependencies:
 
Some notes on PostMagic vs. Anti-Alias:
  1. PostMagic Anti-Alias works just fine in VR for me. Just TAA doesn't work (as the documentation says), but it should automatically disable itself in VR and switch to FXAA.
  2. There should be no reason to even ship scenes with PostMagic Anti-Alias enabled. The reason this effect even exists as option is that on extremely low-end machines it might give you slightly better quality than having MSAA completely disabled or only running MSAA 2x. Most machines these days shouldn't have trouble running at MSAA 4x or 8x even in VR. All PostMagic's effect implementations are based on extremely old stuff that's hidden within VaM and can't be improved. I don't actually use PostMagic myself because the quality is so terrible :ROFLMAO::ROFLMAO:
  3. Different settings in VR and Desktop for anything, not just PostMagic, can be achieved via LogicBricks. Add two "EventSceneLoad" bricks to your scene and have one trigger in VR, the other in Desktop and just change the settings you need changed.

The most likely cause of "double vision" are assets imported incorrectly from Unity Editor. There are certain project settings that are needed to have them work in VR.

I can confirm post magic was a problem in most VR scenes for me. However instead of double vision I was just unable to see the UI until it was disabled. Once re-enabled it was fine. I have actually not been using it specifically because of this :(
As VAMic Novelist mentioned it's often unclear what object the plugin is on, and I've found it easier to simply ensure it is never found than to have to find it. That said, it was pre-1.2x and I don't know if the issue persists as of the update.

I've been meaning to create a simple script that searches for it, reports the object in the plugin UI, and automatically turns it off and on again, so that I can enjoy such a brilliant plugin, but it's low on my todo list.
 
Back
Top Bottom