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 packaged in its state and released as "the" plugin.
I also still do not have a paid tier to my patreon, but if feedback doesn't increase, I might have to create that tier, to start justifying the effort of trying to imitate Steve Jobs.
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.
At least that much has already been achieved and proven as a concept. Now comes the general ideas of pathing through these state collections, and of parenting structure and influence (think tree structures w/ leaf and subtree nodes).
- 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 turning my attention to at the moment since I have nothing else in line to change/alter/open up for testing ...
- the UI.
- I will have to, in my mind, use more ingenuity than used for the plugin core, in order to have the UI be in the same class of usefulness.
- The core ability of the plugin (again, b/c I know if it's only clearing up for me, I've likely not cleared it up for others)
- creating "unlimited" collections of your scene/subscene's state, by clicking/triggering "Add Slot"
- state includes any change that would persist through a scene load/save.
- eg. character pose, clothing material diffuse offset, rigidbody link, controller max velocity, etc.
- "monitoring changes in the background" to any/all of those states
- (any automated or manual change made to any parameter of any targeted Atom + state, made through UIs or plugins)
- auto-saving changes (optionally) on each state change
- providing an "undo", but for all state as a collection - not for every change - unless a slot was made for every change...
- editing of the state collection list
- linearly iterating through states
- didn't have incentive to test direct state transition by index. I think it's around 95% implemented.
- While the simple side of the plugin, which has already been uploaded for free members of my Patreon, can already build and play / iterate through collection states just fine, and save/restore well enough, provided a few caveats (such as needing to assure each atom existed in the subscene for all collected states of the subscene (or at least the initial one? not positive) - else the state will likely not restore as expected on reload). At least... that's as far as I know, as the feedback has been lacking.
That's all for now. Thanks for reading!
P.S.
Almost forgot. While the video shows that I've accomplish drag & drop + reparenting, I have much more ambitious plans for the UI, which involves size minimization of dropped elements. + other general inspirations from the works of the Author/Designers Tufte and Norman, to make tracking what you're building more intuitive. I myself have been too busy to create with the version capable of saving to have shared anything with it myself, so it's understandable if others haven't. Also, with everything said, I do think I CAN support more early release users at this point.
If you do give it a try, note I have forgotten to mention that the Appearance/Physics Lock toggles were never implemented, and just not removed, I suppose, because I liked my UI element placement enough to forget they existed as something other than spacers.
P.P.S. This UI feature isn't in the released version, and I will not be releasing another version until I have all of my basic UI components done. I will in the meantime be available to provide support for making custom edits to the script, to yield desired behaviors / state component selection (it's very easy, I promise).
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.
"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.
I've also heard non-snap-restoring poses were in the works for BodyLanguage?
In the meantime...
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 give it the hand-off hold.
I used the SimpleStateMachine to build the controller. The "Edit" / "Editing" trigger when the EditSphere touches the StateSphere, would otherwise take a series of sets of triggers that would be a pain to navigate through to make adjustments. With the SimpleStateMachine, it's just one Start-Collision trigger: Controller.Next. And on the End-Collision trigger, the same exact thing: Controller.Next. Setting the UIText and the color, etc., was just done via the UI while the plugin essentially creates and ties a trigger to any/all changes I made to the controller. It was... simple.
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 SimpleStateMachine are provided.
Because I had to rework the controller, I am using my own plugin on it (it is a SubScene after all, which I specifically designed the state machine to be attached to (if not to a person directly)). This has helped me play with ideas that have yielded a much better version of that initial controller, so that will be worth the wait.
Hoping the scene physics setup I am putting together as I type (after I eat) is also worth the wait.
spoiler: Being somewhat active in the Discord has its benefits *wink, wink - work-in-progress
---
Usage:
(note: saving is not enabled - this version is for playing around with. If not being able to save is upsetting, that means you must like the capabilities. Please show support. Coding contributions, free membership patreon tier level... all welcome)
- Attach to a SubScene Atom, or because it is tested for the case, throw a Person in CyberPunkApt.
- Parent the Person to that/a SubScene.
- Try adding additional lights, some toys, etc... and set all of them to be parented by the Apt/Subscene...
- THEN, once everything you want as a child of your state machine sees that Apt/Subscene as its parent...
- Move the person into the shower doorway, if the former.
The plugin will auto-create two state collections for you.
- Go to the Plugin's UI and toggle on BOTH Play and Edit.
- Press Next a couple of times, and watch the Plugin UI scroller iterate back and forth between 1 and 2.
- Now you're ready to start editing your first state.
- Go ahead... I'm not stopping you. Don't stare at the plugin UI. Go create your state. Use your fav. plugin to give the person idle movements - dress things up. Set up the lighting such that it yields a mood...
- If using the CyberPunkApt
- Move the person from the shower doorway, straight back, to the shower wall -- not into the shower, yet - just further inside, to that back wall.
- Turn on the shower, Change some of the lights. Go back to the plugin's UI, and press Next.
- From here, you can add slots, and add more states, and start playing with "small" movement transitions.
I myself like to use the Player's main controller UI to set their max velocity to 0.01, their damper to 0, and their joint spring "percentage" to about 7 (equates to a value of 700 for hold spring, for every controller). I make sure to do it before creating too many states so that I don't have to go back and adjust the main characteristics I wanted, by iterating through and changing them later.
- Careful not to put a collider between the person btwn states in this version as it was made for small, incremental movements.
- To make a backup of your current state, just add a state. It is stacked to the end of the list.
- To undo changes made before iterating back or forth while Edit is on (which would save that state), just click "Revert Unsaved Changes".
- Replacing one state with another is a little less straightforward in this initial version.
- You'll have to navigate to the state you want to replace the other with, make sure you "Played" into that state.
- Now toggle off both Play and Edit, and Hit Next/Previous until you get to the state you want to replace.
- No states should be overriden while Edit is toggled off.
- Toggling off Play just lets you avoid jumping into states on the way to the target one.
- Once the target state index is reached, toggle back on Edit, then go Prev/Next.
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 achieve that.
Two more releases planned over the weekend. Next is the 1st draft of the in-game VR widget that will do everything that can be done via the plugin's menu.
The last is a starter scene pack, with the plugin attached to the CyberPunkApartment, and some items / physics setups placed about to help users get familiar with the plugin's capabilities.