Plugins + Scripts A simple state machine

[entitycs]

entitycs submitted a new resource:

A simple state machine - It's time

#soon

Read more about this resource...

 

[Omega]

Whilst I'm not entirely sure I understand what is happening in the example videos, I think I like the premise of this. Looking forward to seeing what it can do!

 

[entitycs]

Whilst I'm not entirely sure I understand what is happening in the example videos, I think I like the premise of this. Looking forward to seeing what it can do!

(edit: I'll come back and make this rambling more concise for those who may attempt to read it later, after I get some rest)

Thanks. w/ 26 resources under your belt, you can start playing w/ it now, if you want. Just DM me whenever you feel like it (provided I haven't released it yet). Thinking now, the way it works, I think I'll have a 'user' and 'creator' version - the only difference being that the creator version is the side keyed toward building the scene states, and can be customized w/ the release of the scene such that anything the scene author intends for the user to NOT be able to adjust with the state manager, can be limited.

Here's a peek at how one of the state collection sets is built in code. Out of 120+ state targets (all JSONStorable-derived types), the scene author can choose to limit which of those targets are part of the editable state, or single out just a few (like controller positions and character clothing).

collection.AddRestorables(new SubSceneComponentSetRestorable<DAZHairGroupControl>(ContainingAtom));
collection.AddRestorables(new SubSceneComponentSetRestorable<MaterialOptions>(ContainingAtom));
collection.AddRestorables(new SubSceneComponentSetRestorable<DAZCharacterMaterialOptions>(ContainingAtom));
collection.AddRestorables(new SubSceneComponentSetRestorable<PhysicsMaterialControl>(ContainingAtom));
collection.AddRestorables(new SubSceneComponentSetRestorable<MVRScript>(ContainingAtom));
collection.AddRestorables(new SubSceneComponentSetRestorable<PhysicsSimulatorJSONStorable>(ContainingAtom));
collection.AddRestorables(new AppearanceSetRestorable<DAZSkinWrapMaterialOptions>(ContainingAtom));
collection.AddRestorables(new SubSceneComponentSetRestorable<FreeControllerV3>(ContainingAtom));
collection.AddRestorables(new SubSceneComponentSetRestorable<HairSimControl>(ContainingAtom));
collection.AddRestorables(new SubSceneComponentSetRestorable<ScaleChangeReceiverJSONStorable>(ContainingAtom));
collection.AddRestorables(new SubSceneComponentSetRestorable<SetTransformScaleIndependent>(ContainingAtom));

If wanting to assure you only adjust/save/restore the non-physical, appearance-related components, you would use SubSceneAppearanceSetRestorable, or just the standard AppearanceRestorable class. This sort of design should also help me be able to pump out feature requests for specific components without worrying about having broken something else in the meantime.

This is the list of state-managable components I activated for the SubScene + SubScene/Person demo. Given how VaM was designed with pretty extensive use of Generic Classes, it doesn't take many of them, to fill the state machine with a lot of... state.

These are also essentially the lists that the creator might want to adjust, if I end up splitting it into the two creator/user versions. Actually, if I don't do this, I feel I will end up with so many varying, and conflicting requests for what should be included in the creator side, or not, that this is the best way forward.

I've made it as simple as possible, such that out of the entire framework of code, a creator would only need to adjust one section, meant for the type of adjustment they want to make.

One last example, to differentiate it from the normal types of edits people make when they receive a scene - and why..

If you just had a X-Mas scene, and you wanted the user to only be able to change the Person's appearance, you could remove all of those but the DAZ components you want to make aware of the state machine - or you could include 'everything' and let the user re-create and play with / "break" the experience as much as they want. Maybe they don't like your choice of surprise clothing, or maybe they have a piece of clothing they built and want to see used in your played out scenario. Maybe they have their own voice lines. To change any of those things, they only need know how to change those things.... and they can do it any time - not just at the beginning of a scene. And it can be a lot more than looks - they can decide the lights should be darker in your last scene sequence - and so they simply find the light and turn it down. Next time they enter that sequence, the light will adjust to match what they set -- again, without them needing to locate a keyframe or a trigger / logic brick or what have you.

To wrap up... the state machine will never have a robust menu. Maybe once it's free, someone will find a reason to convolute it, but the plan is a seamless builder / state sequencer / re-sequencer that "just works". It only has "Save/Edit/Undo" and "Next/Prev", for the UI, it only has 1 or 2 buttons in mind for the future - and most of that, I am planning on replacing w/ a widget for those working in VR, so they don't have to take their eyes off of their work or aim at any menus just so they can navigate back and forth from the plugin UI to whatever state they are testing changes for.

Lastly, could work as a tool for those who design characters in VaM. Boot it up. Add 10 state slots, and use/reuse them like insta-copy canvases while you decide on which alteration path is going to best suit your intents. It's like have 10 person items in the scene, all packed into one. Use 5 different base sins, and build a whole family of characters, all under the single Atom; swapping back and forth quickly to make sure you're capturing the resemblance in each, and again, w/out having to use a menu to save/load a preset, hope the position of the character is correct, that the bones won't snap, etc. ...and ofc, it doesn't stop you from making additional Preset saves as you work.

 

[kretos]

The biggest problem with all animation plugin is that all use fixed positions. If you want to hit sth and the position is not right it will be a miss. It would be nice to have a plugin that recalculates "routes" to get to dynamically changed position. Ie. slap high or smaller girl, enter high or smaller girl in doggy position.

 

[entitycs]

The biggest problem with all animation plugin is that all use fixed positions. If you want to hit sth and the position is not right it will be a miss. It would be nice to have a plugin that recalculates "routes" to get to dynamically changed position. Ie. slap high or smaller girl, enter high or smaller girl in doggy position.

I agree, that is a "sticky" point.


Let me see if I understand the idea. I'll put it in terms of walking.

If I turn the character controller 180%, I expect the walking animation to play in that direction.

But if I lower the player's hips, I expect the player to crab-walk the rest of the way, until lifted the hips back up again.
When I have pitched the ideas that Timeline and a StateMachine can be combined, I don't think everyone sees it the same way as you do, but I am one who does, if I understand your scenario.

I know Timeline has blending, and triggers, etc., but it sounds like you are saying, there should be components, such as "major key frames", such that when a major keyframe is reached, any changes made to particularly chosen aspects of its state will trigger a "re-blending" of that aspect, where it be main orientation, the target of an eye-gaze, the rigidity of a body part or clothing item... etc...?

 

[entitycs]

entitycs updated A simple state machine with a new update entry:

CollidersAsTriggers Plugin released

I've read while researching asset creation, that it is best to release smaller components of your plugins or scenes first, so I have started releasing components that improve usability for my state machine. The first is a simple plugin to turn basic shapes and atoms into passthrough collision triggers. The native spherical CollisionTrigger Atom is great, but I wanted non-spherical shapes, and to be able to track my collider visually, ie. with a mesh. This was the easiest way I saw to...

Read the rest of this update entry...

 

[IIEleven11]

can i test it please

 

[entitycs]

can i test it please

The state machine? Or the 'collision-less collider trigger' plugin? You can follow entityCX on patreon to start downloading that, and other things as I'm ready to release for "insider testing" before I release them on here. The point of throwing people to a patreon (free), for now, is to have beneficial feedback in exchange for beneficial guidance, tutorials, and early access. I could even do a live screen share session or two to share live usage examples - might be easier than trying to highlight in several videos "everything" it can b e used for / how to use it alongside specific plugins or scene types.

 

[Omega]

I agree, that is a "sticky" point.


Let me see if I understand the idea. I'll put it in terms of walking.

If I turn the character controller 180%, I expect the walking animation to play in that direction.

But if I lower the player's hips, I expect the player to crab-walk the rest of the way, until lifted the hips back up again.
When I have pitched the ideas that Timeline and a StateMachine can be combined, I don't think everyone sees it the same way as you do, but I am one who does, if I understand your scenario.

I know Timeline has blending, and triggers, etc., but it sounds like you are saying, there should be components, such as "major key frames", such that when a major keyframe is reached, any changes made to particularly chosen aspects of its state will trigger a "re-blending" of that aspect, where it be main orientation, the target of an eye-gaze, the rigidity of a body part or clothing item... etc...?

I understand completely what he is referring to. Basically, there is a very big issue in VirtAMate currently with animations and scenes. The problem being that they aren't very interchangeable. As a creator I get this question a lot. "Can I use my own looks in your scenes?" and whilst the answer is technically yes, there is a VERY big chance that using any look other than the one I designed the scene for will simply break the animations.

This is because the animations were designed specifically with that female look in mind, meaning her height, the length of her legs, arms, etc, are all predetermined. Therefore switching her out for another female look means there is an incredibly good chance that the new female look will have a different height, length of her legs, arms, etc, even if only by a small amount. That small seemingly insignificant amount can be enough to throw the animation off and break the scene entirely.

Some kind of plugin, or something, to just help kind of realign things in a way that automatically adjusts as required per the differences of limb lengths and such from the original look to the desired look would be ground breaking for creators and users alike.

 

[IIEleven11]

The state machine? Or the 'collision-less collider trigger' plugin? You can follow entityCX on patreon to start downloading that, and other things as I'm ready to release for "insider testing" before I release them on here. The point of throwing people to a patreon (free), for now, is to have beneficial feedback in exchange for beneficial guidance, tutorials, and early access. I could even do a live screen share session or two to share live usage examples - might be easier than trying to highlight in several videos "everything" it can b e used for / how to use it alongside specific plugins or scene types.

The state machine and there is no link anywhere to your patreon and when I google it, no results show up

 

[kretos]

I agree, that is a "sticky" point.


Let me see if I understand the idea. I'll put it in terms of walking.

If I turn the character controller 180%, I expect the walking animation to play in that direction.

But if I lower the player's hips, I expect the player to crab-walk the rest of the way, until lifted the hips back up again.
When I have pitched the ideas that Timeline and a StateMachine can be combined, I don't think everyone sees it the same way as you do, but I am one who does, if I understand your scenario.

I know Timeline has blending, and triggers, etc., but it sounds like you are saying, there should be components, such as "major key frames", such that when a major keyframe is reached, any changes made to particularly chosen aspects of its state will trigger a "re-blending" of that aspect, where it be main orientation, the target of an eye-gaze, the rigidity of a body part or clothing item... etc...?

Your example is rather extreme. I thought about rather simple scenario:
1. Let's assume that girl wants to slap a man
2. There are two minimum points - start of the hand and target cheek, but let's introduce 3rd point so the hand is not going in straight line (super strange for humans) but in arc trajectory - this is base animation
3. The hand can be in different position - the height of the girl is different, or there was different animation played before and the hand is not at hip but at shoulder already
4. The man's cheek can be on different height because man can be standing or kneeling
5. animation systems recalculate start and end positions and move all inbetween points so the overall trajectory remains arc

Having such system one could create a library of basic animations which could be combined to create complex moves. Because system would support small differences and take into account human moving system (minimize effort, muscles used for movement, natural trajectory of movement) we could get natural looking movement using closed number of animations. Currently each scene is done either using plugins which do single things (like thrusting, breathing) or using complex animation plugins like timeline where transferring animations between scenes is rather hard.

Some kind of plugin, or something, to just help kind of realign things in a way that automatically adjusts as required per the differences of limb lengths and such from the original look to the desired look would be ground breaking for creators and users alike.

I use appearance load plugin with scale change off. This looks quite ok and is simple. There's more advanced plugin (can't recall name) that recalculate the limbs but it's too slow for my play.

 

[entitycs]

Your example is rather extreme. I thought about rather simple scenario:
1. Let's assume that girl wants to slap a man
2. There are two minimum points - start of the hand and target cheek, but let's introduce 3rd point so the hand is not going in straight line (super strange for humans) but in arc trajectory - this is base animation
3. The hand can be in different position - the height of the girl is different, or there was different animation played before and the hand is not at hip but at shoulder already
4. The man's cheek can be on different height because man can be standing or kneeling
5. animation systems recalculate start and end positions and move all inbetween points so the overall trajectory remains arc

Having such system one could create a library of basic animations which could be combined to create complex moves. Because system would support small differences and take into account human moving system (minimize effort, muscles used for movement, natural trajectory of movement) we could get natural looking movement using closed number of animations. Currently each scene is done either using plugins which do single things (like thrusting, breathing) or using complex animation plugins like timeline where transferring animations between scenes is rather hard.


I use appearance load plugin with scale change off. This looks quite ok and is simple. There's more advanced plugin (can't recall name) that recalculate the limbs but it's too slow for my play.

Ah. I think I see now.

It feels like with some rigging, it wouldn't be "too" difficult, assuming you were allowed to at least limit the sequential states as categorical. For example, it wouldn't be possible to jump between two extremely different states (right-hand hair-pulling <-> right-hand cheek slap). Playing around with the physics, and comply settings for the rig set compatible with the position/action state, then yes.

When it comes to arks, I imagine many a novice would target the hand to make the slap hit its target, when they would make the hand a softer target, and focus on the rotation of the joints and position of the torso that would physically land the hand in the approximate location...

If the opportunity comes along, I'll contribute to such a solution.

 

[entitycs]

The state machine and there is no link anywhere to your patreon and when I google it, no results show up

Ah, sorry about that. It should be patreon.com/EntityCX. I was trying to avoid direct linking, but I guess it's okay?

 

[kretos]

it wouldn't be possible to jump between two extremely different states

The best would be if plugin automatically propose animations where start position is similar to end position of previous one - so they could be recalculated. In example: woman sits on a chair and next proposed animations would be stand up, put leg on leg, put legs aside, bend forward, lean on the chair backrest, put hands on knee etc. The calculation would be done during editing of the scene so it don't have to be super fast. Some animations would use just some part of the body (ie hand animations) - in that case only that part should match the existing end state. The best way would be to use single base library scene with all possible moves and predefined actors and add new animations to this base.
So the animation would consists of sequence of premade actions where user only define sequence and speed of animation. The woman walks toward chair, turn around, sits, put leg on leg and hands on knee. All you have to do is click five actions following each other with their speeds. So this plugin would be "high level" animation definition. Now imagine that made in timeline...
Users could add new animations to "library" and it would be available for all plugin's users immediately after library update. Another thing is constant improvement - because plugin recalculates the movement and don't need specific strict points, any changes in the existing library (ie. more natural walk) would improve each scene using this improved animation... First example I can think of - the thrust in VAM is almost always done using hip control. But hip in VAM is top position of hip bones and in reality the thust goes from place where femur (thight bone) is attached.... Animations using hip control sometimes look really stupid.

 

[entitycs]

entitycs updated A simple state machine with a new update entry:

SimpleStateMachine Plugin Demo is Live

Some rounds of testing revealed my first iteration of the in-game VR controller could explode on load, if a collider that is turned off via the helper plugin would collide with another object before VaM gives the plugin system a chance to choose which colliders to disable.

This has postponed the release of the in-game VR controller and the sample scene. Instructions for how to quickly set up the CyperPunkApt with Person item to create two "sane" states for getting to know the...

Read the rest of this update entry...

 

[entitycs]

entitycs updated A simple state machine with a new update entry:

Controller Teaser

This uses the free CollidersAsTriggers plugin, to enable the three collision triggers around the sphere. This lets you use swipe gestures on the controller. You can move the side colliders further, higher, etc. This would be much more difficult with invisible sphere colliders, to say the least.

It also has a holding rig set up so that it will float all around one of your hands w/out ever colliding with it. Just pinch and flick to rotate into another position, and use the usual method to...

Read the rest of this update entry...

 

[Omega]

I use appearance load plugin with scale change off. This looks quite ok and is simple. There's more advanced plugin (can't recall name) that recalculate the limbs but it's too slow for my play.

Scale is only a small factor of the problem, scale affects the overall size of the person atom whereas there are tons of different factors in limb length. Since leg length, arm length, forearm length, torso length, upper body length, lower body length, and so on are all individual morphs they are separate from Scale and therefore even if you do change the person atom scale it won't affect the actual morphs that affect the specific limb/body part lengths.

I've spent a LOT of time thinking about solutions to this issue, but I'm not a developer so plugins are out of my reach.

There are many different variables that go into determining a person atom's overall size. One solution I tried that failed was to automatically reset the adjustable "length" morphs back to the default setting to ensure compatibility between animations - but some creators like to package their looks into an "All In One" morph package. This means that a creator's look could contain adjusted arm, leg, torso, hip, etc, lengths but they are essentially baked directly into a single morph slider. Meaning that adjusting the limb length morph sliders won't work anymore, since they are technically already set to the default settings. If that makes sense.

I have no idea how to solve this problem purely inside of VirtAMate, but in terms of concepts I've had for potential plugins as a solution - if a plugin existed that could determine the "physical length" of each limb and body part based on the default appearance for that scene and set THOSE lengths as the "Default Proportions" for that person. We could hypothetically automatically adjust any newly loaded appearance presets according to the "Default Proportions" and force the newly loaded appearance preset to sync up with the original look.

The way you could determine the "physical lengths" of limbs could be measuring the distance between bones in the rig, if that's even possible. For example if you get the distance between the L-Shoulder bone and the L-Elbow bone which let's say is 24cm, and then get the distance between the L-Forearm bone and the L-Hand bone which let's say is 36cm. With those distances you would now have the "Default Proportions" of the L-Arm for that person atom being 60cm. Then we load in a new appearance preset on that person. It's a tall woman with long arms, so the arms are too long - we automatically adjust the length of her arms based on the "Default Proportions" based on the original appearance preset.

If you are capable and well versed in the process of writing plugins for VirtAMate, I would love to investigate this concept with you further! I don't have the time or experience with development to really be able to do it myself.

 

[Omega]

Also in response to your offering me to test your plugin out, I'd be happy to give it a go. I can't make any promises about making any real scenes with it at the moment, I have a lot I'm working on, but I'd be happy to give it a go and try make at least something with it!

 

[entitycs]

entitycs updated A simple state machine with a new update entry:

They Said It Cannot Be Done

"The BodyLanguage Sliders are not Triggerable," they said.

... Innovations say otherwise.

I guess it's difficult to see what was thought of as not possible.

Only 3 forward-lookers on my (free) Patreon so far, who will receive priority support.

Currently working on the last steps of saving/restoring from JSON, and other integration testing.

Read the rest of this update entry...

 

[entitycs]

entitycs updated A simple state machine with a new update entry:

Beta version now available!

I've been so busy working on getting it to save/load along with the scene that I have only played around with it so much.

Ready to start building a complex, multi-state scene, finally - but might be too tired at the moment. I've been dropping sneak peaks into the official VaM Discord channel work-in-progress - will drop this there while I rest so others can start getting familiar with its capabilities.

Read the rest of this update entry...

 

[entitycs]

entitycs updated A simple state machine with a new update entry:

Early Release Feedback Needed

Opening up free access to these early states of the plugin to more people, as I am lacking the amount of feedback I would like to receive before public (and/or paid) releases.

• There will definitely be a free version of the plugin.
  
  
• But... in the case there is a Creator's version
  • those providing feedback showing a modicum of effort will have access to at least all versions through the plugins' development lifetime.
    
• Attaching a quick vid of what I am...

Read the rest of this update entry...

 

[entitycs]

entitycs updated A simple state machine with a new update entry:

No more links to Patreon Content?

I understand the developments. But I'm not releasing the free version of the plugin onto the Hub until it has gone through some user testing on both the Creator and User ends. Hope you guys will be patient, or join up, try it out, and provide feedback.

Frankly, I've only gotten feedback from one user, but it was valuable enough to make it worth is so far, opening it up to others.

Patreon members have been given the right to release scenes using the code as a helper, but it is not to be...

Read the rest of this update entry...

 

[VirtuaBanger]

Frankly, I've only gotten feedback from one user, but it was valuable enough to make it worth is so far, opening it up to others.

I was interested in the plugin when I first read the description of it until I read this part:

"I find it powerful enough to consider the ethical implications of releasing it, given I don't want to pull support from those who have worked hard to create multi-part scenes that get the community excited, by making it too easy to replay their scenes 100x over instead of at least throwing some support to get a fuller version of a clip-length or otherwise teased version of a scene."

That could be said of literally any asset whether it is a plugin, texture, CUA, or whatever that is uploaded to the hub. Anything that enables users to better express their creativity and grow the capabilities of both themselves and VAM even if it takes away subs from Patreon. VAM isn't just for people to sell Patreon subs. To me it sounds like you were planning on neutering the plugin for fear of other creators complaining about their revenue. Personally, for me, I wouldn't be as interested in a plugin that is deliberately hampered for such a reason.

 

[entitycs]

I was interested in the plugin when I first read the description of it until I read this part:

"I find it powerful enough to consider the ethical implications of releasing it, given I don't want to pull support from those who have worked hard to create multi-part scenes that get the community excited, by making it too easy to replay their scenes 100x over instead of at least throwing some support to get a fuller version of a clip-length or otherwise teased version of a scene."

That could be said of literally any asset whether it is a plugin, texture, CUA, or whatever that is uploaded to the hub. Anything that enables users to better express their creativity and grow the capabilities of both themselves and VAM even if it takes away subs from Patreon. VAM isn't just for people to sell Patreon subs. To me it sounds like you were planning on neutering the plugin for fear of other creators complaining about their revenue. Personally, for me, I wouldn't be as interested in a plugin that is deliberately hampered for such a reason.

I can understand your points.

From my perspective, this is what I see. Please don't take it the wrong way, but it sounds like you are in agreement with the logic behind my developing this plugin, and sharing it at all...

Early on, it seemed most scenes were pretty simple - using native Atoms, like CycleForce, and the ColliderTrigger, LookAtTrigger, etc. When you loaded a scene, you could start messing around with things. Some of the setups were of better quality than others, but the sense I got was that most people were doing a lot of fiddling themselves. At some point, some creators put in more and more work, and over time started releasing much more immersive, yet less modifiable content. That wasn't, from what I can tell, all about limiting - but more about expanding, under constraints of what is/was available.

What inspired this plugin is the notion of re-igniting that creativity.

I think there are a few assumptions or miscommunications as to the intention of not releasing something without warning, that would hamper the efforts of those who have put in so much work to build and attract a growing community -- even if their content is limiting in the sense you described. Those people will have to likely redesign a lot of their content or frameworks for VaM2, supposing it's not too far down the horizon. Were it not for such creators, who could have together decided to work on a new, separate, competing platform, I think the community would be at a higher risk of being split up. I'm not saying "no pay, no good." as a blanket statement, which brings me to the next point.

I do not intend to keep the plugin behind a "paywall" forever. I have no paid membership level, in fact, to even keep it behind a paywall now - so anyone who was interested could have joined up for free and started playing with what I have spent a lot of time on to help inspire people on how to use it - I gave them a license to create their own things from it, with credit. Eventually, I'd plan to release the Creator version as well, but until people know what it is capable of, the potential immediate user base would not be one I could support without some early backers helping me test and find bugs, work out best next steps, etc.

Finally, because of how difficult I found it to even imagine being able to create multi-state scenes like the ones being released - the way things break - or the headset feels to test in VR while playing with a dozen dropdown menus... etc... I thought some respect for the process was due -- but again, I didn't mean to suggest scenes should all be static teases. I just thought I was being fair to both creators and end users - especially the brave end users who would see this and join up for free to help me develop the concept before releasing on the Hub.

 

[VirtuaBanger]

I can understand your points.

From my perspective, this is what I see. Please don't take it the wrong way, but it sounds like you are in agreement with the logic behind my developing this plugin, and sharing it at all...

Early on, it seemed most scenes were pretty simple - using native Atoms, like CycleForce, and the ColliderTrigger, LookAtTrigger, etc. When you loaded a scene, you could start messing around with things. Some of the setups were of better quality than others, but the sense I got was that most people were doing a lot of fiddling themselves. At some point, some creators put in more and more work, and over time started releasing much more immersive, yet less modifiable content. That wasn't, from what I can tell, all about limiting - but more about expanding, under constraints of what is/was available.

What inspired this plugin is the notion of re-igniting that creativity.

I think there are a few assumptions or miscommunications as to the intention of not releasing something without warning, that would hamper the efforts of those who have put in so much work to build and attract a growing community -- even if their content is limiting in the sense you described. Those people will have to likely redesign a lot of their content or frameworks for VaM2, supposing it's not too far down the horizon. Were it not for such creators, who could have together decided to work on a new, separate, competing platform, I think the community would be at a higher risk of being split up. I'm not saying "no pay, no good." as a blanket statement, which brings me to the next point.

I do not intend to keep the plugin behind a "paywall" forever. I have no paid membership level, in fact, to even keep it behind a paywall now - so anyone who was interested could have joined up for free and started playing with what I have spent a lot of time on to help inspire people on how to use it - I gave them a license to create their own things from it, with credit. Eventually, I'd plan to release the Creator version as well, but until people know what it is capable of, the potential immediate user base would not be one I could support without some early backers helping me test and find bugs, work out best next steps, etc.

Finally, because of how difficult I found it to even imagine being able to create multi-state scenes like the ones being released - the way things break - or the headset feels to test in VR while playing with a dozen dropdown menus... etc... I thought some respect for the process was due -- but again, I didn't mean to suggest scenes should all be static teases. I just thought I was being fair to both creators and end users - especially the brave end users who would see this and join up for free to help me develop the concept before releasing on the Hub.

Thank you for the reply, I appreciate it.

The only thing I can add is in response to what you said at the end: "I just thought I was being fair to both creators and end users" and that is to consider the (extremely appropriate use of the bible in this context) quote “No one can serve two masters."