*C&G-STUDIO* "A Dangerous Candy"
Added 2023-07-12 11:35:45 +0000 UTCThis show is out of this world!
Enjoy a massive show release and be taken away from reality just to be thrown directly into a strange dual universe. POGVRs new model "Leigh" is going to show you both sides of her naughty fantasy.
Join a magical candy world and become buffed by her cuteness - but in the next second you will discover the deamon inside!
Not gonna spoil more - enjoy the show!
Whats IN this release?...
- A beautifully arranged MoCap ShowOff / Dance
- POGVR model "Leigh"
- Candy World / Dark World - you can even choose from in the end
- Sexy Candy + The Goddess appearance presets to choose from
-> Yep, you can also let the Goddess ride you in the Candy World =D
- Sex part with two poses
- 4 cameras to choose in the sex part
- NEW: Integrated Camride POV + Camride Display option
- Performance version without any assets for max FPS
The Candy World assets are included and been ported by SuperSamoth!
***
Finally I depend on your feedback here on this feature! With this release I try to get "rid" of the camride versions. Instead of a separate camride version you can now go into the camride mode whenever you want using the "Camride POV" button or enjoy the camride on the Tablet display by pressing the "Camride Display" button.
How did you like this? Did you encounter any problems? Note that the Embody plugin used for the camride uses your referenced room position as orientation! So if you are *not* facing the same direction like the "Camride Display" shows you definitely need to rotate your cute butt a bit to the left or right *or* adjust the rotation in the plugins tab :P
***
Enjoy!
Your C&G-STUDIO
*INSTALLATION*
1. You got a DM with the link to this content
2. If you are new you got a welcome note (check your mails & membership area)
3. Download the content and throw it into your "AddonPackages" folder
4. Download any missing dependencies here or within VaM
*DEPENDENCIES / EXCLUSIVES*
MODEL
POGVR - Leigh
ASSETS
SuperSamoth - CG - Candy Bundle (inlcuded in .var file)
*DEPENDENCIES*
CLOTHING
Hunting-Succubus - Enhanced Eyes 2
Riddler - Glitter
maru01 - Short Dress
VirtaArtieMitchel - Artie's Secret Lingerie Set
Juno - Thigh High Chunky Knit Stocking Socks
paledriver - Nails Mask for Female/Male/Futa
PLUGINS / ASSETS
Acid Bubbles - Timeline
Acid Bubbles - Glance: Realistic head-driven eye motion
PluginIdea - High Performance Volume Lighting
MacGruber - LogicBricks
NoStage3 - UnityAssetVamifier
MacGruber - PostMagic
Jackaroo - Mocap Based Expression movements
Matt Richard - Dragon Fire
TheOriginalBatatis - Universe Sky (Skybox)
Farger - Farger's Particle Pack Vol 2
Griffo11709 - SpyCam&Tablet
TEXTURES
Riddler - Molly Mormon Texture
Riddler - Skin 6
Spacedog - Wet Bits
WeebUVR - Zero FU Penis normal maps
Comments
Sounds interesting. I am going to answer this in moee detail once are fully back in round about a week :)
KamiGato
2023-07-22 20:13:38 +0000 UTC"If no the animation patterns for randomizations of the voice are getting forced inactive. If yes, the triggers are active again. Since voice activation appears in different ways (either direct trigger or randomized) an over the top "if" function is needed." Ummmmh - an idea, if I may? It's a shot from the hip, so take with a truckloads of salt: In most LogicBricks that are able to receive a trigger signal, there's an "accept trigger" option for just that purpose of implementing 'an over the top "if" function', as you called it. I've seen this used a while ago in a scene by SlamT - instead of fiddling with dozens of different plugins to tell them to stop firing triggers if a certain condition is met, you just tell their (single) target to STOP LISTENING ... much simpler to implement. You don't even have to switch the containing atom to OFF (could have other unintended consequence, eg when other LogicBricks are housed in the same atom). P.S.: I'm no coder myself, but I know that this need for "an over-the-top IF" thingy arises pretty often -> where you split a simple "IF" into an "IF (condtion) x" and a "WHEN (event) e" part - I think this is what the real coders call a State Machine? And ... there happens to be a plugin for that, implemented by MacGruber? And yes, the StateMachine can do all that stuff - randomization, "over-the-top-IF" etcetc. And it can do "IF x WHEN e(vent) THEN a(ction)" - logic. Could you explain in more detail what exactly the purpose(s) of AnimPattern/Collisionsphere are? I'd be willing to go look around for a simple and robust solution - I do this kind of "nosing around for stuff" as a hobby anyway all the time. And if I find one, I'm familiar enough with your scenes that I could easily build a "testing/demonstration edit" of one of your scenes.
CaseEP
2023-07-22 04:09:52 +0000 UTCNormally i dislike cam rides, but WOW you did an amazing job on this one. Everything is so well put together in this scene and the cam ride is just right. Amazing work!!
shisou
2023-07-20 19:51:39 +0000 UTCHey again! Don't worry no need to feel stupid. VaM has a steep learning curve and everytime I think I've seen everything now or think my way of doing things can't be improved more or is the easiest / best there opens an other door to proof me wrong. With that said of course and I BET there are a lot of other ways to implement the trigger system I build up using for example a combination of Acid Bubbles Scripter and parts of Grubers Logic Bricks. However these animation patterns are doing two things mainly. Either to trigger random events (voive trigger for example or lighting ) or to trigger "if X then Y"...so speaking in programming terms a simple "If" function. Mostly used to trigger user choices like my latest implementation to allow female voice yes / no. If no the animation patterns for randomizations of the voice are getting forced inactive. If yes, the triggers are active again. Since voice activation appears in different ways (either direct trigger or randomized) an over the top "if" function is needed. This is just an example why for me personally it is more easy to work with anim patterns in such cases. Of course and like said there is definitely a way to make it more easy with plugins. Honestly the only reason I am taking "longer" to develop new ways for exisitng inplementation is that other scene related things take a crazy ammount of time and in order to deveolop the scenes like we do I am more likely to stick to the scene design, mocap, visuals and so on + release an reasonable ammount of content per month than sticking to the "background" functions. However of course I develop our scenes further with each release. I Thinnk compared to our releases from 1-2 years there is a TON new things and improvement done "behind" the scenes :)
KamiGato
2023-07-20 13:43:19 +0000 UTCOk, now I feel STOOPID ... Thanks for the detailed reply! (and also thanks for ... being cool with my pontificating ...). Ok, I guess years of experience creating scenes DO pay off, huh? Also guess that I still have a lot to learn ... eg, I thought that bcs the interface for VaM-native mocap recording is so clunky, it'd also be inferior technically. So I was ... VERY wrong ... ;) Yeah, in hindsight, it's kinda obvious that veteran creators might have a reason for doing stuff the way they do. Sorry! Still kinda ... bothered? ... by the AnimPattern-Collider-Randomizer thingies. There's got to be a plugin for that (or a combo of plugins). But maybe that's just my OCD talking. Anywhoo - Thanks for implementing my other suggestion (the Camera/Screen Combo). NICE! Best, C
CaseEP
2023-07-19 00:58:21 +0000 UTCHi there. Firdt of all thank you for the feedback. I will go through it in detail after we are back in the studio again but just for information. We use a winder range of recording / animation techniques and what I do is to put the best working ´/ efficient technique into the specific scenes. The majority of our scenes are running with timeline (except older content longer than 1.5 years ago). The "6 times smaller" file size reduction you are refering to is something acid came up just two weeks ago (not sure if its still in alpha stage and even available for use to public). Note that the intern animatiion recording in fact IS the way with the smallest MB impact in the end. However coming back to a scene like Dangerous Candy it would be simply impossible to think or even record it using the standart recording method. So what we did is to record it in timeline with multiple takes and re-record it back into the animation time. In our experience the scenes work best and with less interference running all-in one on one animation time rather then be layer sequenced. FYI the raw records in timeline for this scene were about roughly 350 MB. With our technique we didn't even need to "reduce" keyframes (witch always ends in resulution loss anyways) and brought the complete 350MB including ALL candy assets and everything down to raughly 45MB...like said with 100FPS resultion. Summing up we have three ways of recording we are taking advantage of whenever we see a benefir from it in this or that scene. So with all respect I personally think our way of technical scene design is the opposite of outdated. Finally about the poses and presets it doesn't matter if they are stored within a timeline trigger or within the animation time. Actually guys loving to edit those scenes having it more easy since all triggers are named propperly within the animation time trigger system. Generally spoken scenes like dangerous candy are so big they are closed expierience / system on its own. Editing those scenes takes time - yeah sure. But it would take time no matter how it would be set up. If you set up with 10 more buttons to enable/disable presets, hairs, lighting, scene setting or not. It all ends up in the scene being like said *big* and a closed experience. Other releases - especially the "stripped" ones are way more easy to change and play around with as they are also meant to be played with that way. Hope this helps for a better understanding and you on your end also don't feel attacked in any way! :) Some things are simply not true or displayed the wrong way so I gave my best too explain it a bit more in detail. However please feel free to reach out at any time also on Discord as it might be easier to chat there too :) Thanks again fot the feedback. I will go through everything more detailed once I have more time left and see how we can imporve of course :)
KamiGato
2023-07-18 13:05:50 +0000 UTCOk, some Feedback: To start: Absolutely gorgeous scene - high quality animations, many advanced "mechnisms", stunning effects. Superb handiwork! None of the following takes anything away from that! Criticism: * Recording - Is there some really pressing reason to stick with Vam-native animations instead of Timeline? Because this really (!) bugs me. Timeline has many (maaaaaaaaany!) advantages over Vam-native Mocap tracks. To name just a few: * Timeline (especially in the latest version) would allow to significantly reduce the size of Mocap-tracks. By a factor of SIX! (https://hub.virtamate.com/resources/timeline.94/updates) - That alone would bring some significant performance advantages: Less RAM required. Likely also advantages for the CPU (less JSON-nodes = less things the main thread on the CPU has to keep track off ). * Using Timeline enables VaM's UIDnamechange callback - means that there's less risk of triggerbreaks during editing (you can change atom-names without triggerbreaks) * More comfortable editing of Triggertrack (both for you and the user) * Sequencing - you could eg divide this scene into four sequences - would greatly simplify the "World-Switching" (right now, you have to manually keep track of all pose-changes, LightingRig changes, clothing etcetc). * Poses - You can integrate the starting poses (M1-M4, F1-F4) into the Timeline-animation. No manual loading of starting poses necessary! * Layers - Also don't really see why you use two instances of Timeline on the Girl: Why not one instance with two layers? Or better yet: Convert the body-animations into Timeline, run them through "Reduce" to make them smaller, then add as additional layer. - The way you set up the Logic is incredibly "RIGID" - It's almost impossible to edit the scene with a custom look, or to adjust (poses for that custom look) bcs you have dozens of triggers that revert eg the Hair back to default. Or when I want to adjust the poses slightly (eg modify the headnode of the male, or move the female's main control slightly to adjust for my custom lookl). And that's mostly bcs you don't use Timeline, and hence, your scene-logic isn't "modular" - it's one big "chunk" - so you end up having to keep track of every change manuallyy which forces you have to dozens of "reset-triggers" (load pose, load hair etcetc) distributed over ten or so atoms (and the main triggertrack) that revert each change in pose, hair, clothing etcetc back to default. I've rarely seen a modern scene that is THIS hard to edit - which is a shame, bcs a priori, your scenes should be great for customization, nottheleast bcs you use largely standard body-dimensions. TL;DR - Great Scene, great Effects, but (partially) outdated "mechanics" - Note it's not "mechanics" themselves (the ideas are GREAT!), it's the way you implement them that cost performance!. I realize it's a pain in the b**t to change procedures developed over years - but IMO, there's some significant benefits Please (!!!) consider using Timeline & making the logic more modular! P.S.: I love eg your randomization - but the implementation via AnimPattern & CollisionAtoms is another (unneccessary) Performance-hog (according to MacGruber) - you're using (parts of) the physics engine to implement effects that plugins could do just as well. P.P.S.: Sorry for "Wall of Text" & Brashness - Even my family & friends consider me ... "direct". I don't mean any disrespect or anything.
CaseEP
2023-07-17 21:37:03 +0000 UTCexactly =D
KamiGato
2023-07-12 20:17:34 +0000 UTCThis is wrong on so many levels XD I hope you are joking though....?
KamiGato
2023-07-12 20:16:45 +0000 UTCHi I am having trouble trying to view the animations on my iPhone
Ming
2023-07-12 19:41:32 +0000 UTCWhat The ... ? ;)
CaseEP
2023-07-12 12:37:31 +0000 UTC
