Feedback & Questions - Dreams Update 2.44: Create Mode TLC Part #2 đ
Hey, CoMmunity! đ
Back in September 2021, we released a batch of updates focused on Dreamsâ Create mode, introducing a host of exciting changes and improvements to our creative toolset. Now it's time to set out eyes on Create Mode once again! We've got everything from new calculator options, a NEW FLECK type (yes, really!), to new gadgets, and so much more!Â
There's lots going on in this update! To find out more, read our release notes here: đ https://drms.me/dreams-v244 đ
After you've got your hands on this update, if you have any questions or feedback, please let us know in this thread! We can't wait to hear what you think! đ
-
Please add Insert Previous Frame option when creating paintings frame by frame! This would certainly be useful especially now that you can convert sculpts to paint! I've also posted the amazing potential of this tool in particular on Twitter here: https://twitter.com/kubacAkaGoomba/status/1521941060364251140?t=wewjd8hfpqOD51Yb83G4OQ&s=19
-
When I wire the Local Time output of the new Time gadget to the new Time input of the Sun and Sky, I get a sun position 15° ahead of what I get when I do the same thing with the Time gadget's UTC output. Correct at first glance - BST is 1 hour ahead of UTC. But the UK isn't on rails that move the country 15° west in March and back 15° east in October, so the difference between GMT - same as UTC - and BST shouldn't affect sun position.
Here's a way this could be fixed. Fat wires can have at least 8 channels - 8 numbers and transform are examples of types that already have 8 - but the new date and time fat wire type only uses 7 - year, month, day, hour, minute, second and millisecond. The 8th channel could be used for the daylight saving time offset, and the Sun and Sky gadget could use that to calculate the true local time to use for calculating the sun position.
-
I'd love to be able to predetermine the amount of flecks/fleck size/fleck type before converting a sculpture into paint. Something like that would make it a lot more convenient to make transparent objects such as bottles or ice.
-
JCGoomba This thread is for feedback on the features added in the latest update, not for feature requests. If you go to the Ideas section of this forum, that's where Mm want us to post feature requests like this, so I'd recommend copying that over there instead.
TheBeardyMan While that would be cool, I don't think it was ever the intention for "local time" to produce the exact same sun position on the sun & sky gadget. To do that it's a lot more complicated than giving it a time and a daylight savings offset. Time zones would also have to be taken into account, which is very complex to start with. And the player's lat/lng on Earth also. At that point we'd be better off having a signal for "player's location on Earth," its sun-pitch/yaw would be ignored, and the sun position would sort itself out so it's spot on. That might be a feature you could request for a future update.
The way I see it, the local date/time is just whatever the console says the date and time is. We can use that to set clocks and stuff in a game. And the sun reads a date/time wire, regardless of where that and puts the sun in the sky to mimic the time in some way. We can make any adjustments however we like to the time before it goes in, and adjust the pitch/yaw so it feels right for our game. But it's not meant to be 100% accurate to what the player sees out their window, if that makes sense.
But as I say, maybe a more "complete" 1:1 sun position representation would be cool as a new feature. (These are just my thoughts on the topic, don't take me seriously; Mm may think differently.)
TheNamelesGhst12 You can currently do that on the sculpt, by using looseness/detail, using the style > apply fleck tool on the sculpt (or the painting after the conversion). Maybe that helps?
-
Sun & Sky > Sun Position's "distance" (vector magnitude) is inconsistent: The output takes into account the sun gizmo's distance along the stalk. Changing the brightness changes the distance the sun gizmo is along the stalk, but does not affect the sun position output. When sending a 3-number vector into the input, its magnitude is ignored and does not affect the brightness. The only time the vector's magnitude is updated is when the sun gizmo itself is dragged around.
This indicates to me that internally, the sun position is a simple normalised vector. When dragging the sun gizmo it remembers the distance. Then when outputting the sun position it sets the magnitude of the normalised vector to that distance. As opposed to it being coupled to the brightness or anything.
My suggestion would be that it outputs the normalised vector, and that's it. I would also guess that would be the most common usage of the output; to always normalise it first, because the magnitude is not normally helpful (or reliable, according to these tests).
Footage of my initial testing: https://www.twitch.tv/videos/1475546189?t=1h4m53s
"Wide Calculator" name: It seems funny to me that the gadget is called "Wide Calculator" when it is literally thinner than the normal calculator. It's certainly very tall, so perhaps "Tall Calculator" would be better? Though honestly the name should be something that tells the creator what it does, which "wide" and "tall" do no help on whatsoever. đ
Trigonometry functions accessibility: I understand the reason for this... computers like radians, there are pros to radians, etc. One big pro for degrees is that the average person knows what they are and how to use them. In fact, Dreams uses already degrees when talking about angles, likely because of that. For example, the rotation wire type you'd get from a tag uses degrees (I would think this will be the most common use case for using trig functions in a game).
This means that a creator cannot simply wire an angle generated by Dreams and wire it into a calculator to perform trig operations on it. They need to: 1) know what a radian is, 2) know that trig functions in programming languages use radians and not degrees to know they even need to know about radians (or happen to hover long enough for the popup to appear), 3) know how to convert degrees into radians, and/or 4) know how to convert radians into degrees.
I feel like that list is a pretty big burden of knowledge to even get started using these functions, even if they understand what the different functions are for and how to use them. I learned all about sin/cos/tan from school, using degrees. I would not have been able to use these sin/cos/tan functions without doing external research.
Trigonometry function tooltips: The names for these are not inconsistent. Some just say the text of the icon, which doesn't help understanding (sin, cos, tan, atan, Atan2). Some say the proper name for the function but not completely (arcsin is really "arcsine", arccos is really "arccosine"). To find their true mathematical names, the user has to hover and wait for the popup. Ideally, I'd expect the tooltips to give the full proper name to give the user the best chance of finding the right thing when they Google it ;p
Bake Emitted Tool sets the initial state of all logic: As demonstrated here... https://www.twitch.tv/videos/1475546189?t=1h46m47s
It may not be obvious why that's a problem, so let me give you an example... If we emit some zombies, their internal logic will begin running. They may change into some special mode because they get close to the player puppet which is already in the scene. They may have activated an animation to lunge at them. Now we bake, and rewind, and the zombies are still there. But they're mid-lunge, and in that special mode. But then if we move the player away to start in a different room, none of that makes any sense.
What would make sense is if the zombie was in its initial default state: standing doing nothing, waiting for the player to be in the same room, not lunging from the start of the scene. If the internal logic state was not set as the initial state at the start of the scene, that would all be resolved.
We also get some other odd behaviours for gadgets where we cannot normally set its initial state such as the selector. If we emit a selector, change it to mode C, and bake it... now it will start at mode C from the start of the scene. This could create some confusing bugs until we figure out it's starting on C instead of A. And the only way to fix it would be to completely replace the gadget because we cannot set that initial state ourselves.
And think of how this will affect things like exclusive gates, which are already hard to understand, and it can be quite easy to mess one up and it winds up starting open when you didn't intend it to be. Even nodes can have weird "stuck state," which might be caused by this byproduct of "bake emitted." And something like a timeline half-way through seems to also start from halfway through. Imagine trying to adjust the logic of the object you baked and then realising it has a stuck timeline so you can't just power it to play it because it's going to start halfway through, forever.
There are likely cases where this doesn't matter, but there are also cases where it will definitely be a problem.
On the other hand, it could lead to some weird hacky uses to set such initial state--emitting a selector purely to create a selector that starts from C for example. Which seems hacky and unintentional. (Though an actual setting for which starts as default, and opening up these hidden initial states would be great as an official addition.) So some sort of option may be the best way of introducing this, so that people who like these hacky things or find some special use for this quirk can still do so... Not sure.
My old baking methods were more involved and tricky to set up, but have the benefit of not keeping all the initial state of the internal logic, so it will run completely fresh from the start of the scene. This means you can make an element that is some creation tool or other (eg. planting trees around the place) that also has internal logic that won't start in the middle of it when you start the scene. All the instructions a user of such a tool would need are: how to use the tool itself, and then they bake, and job done.
I did show a couple of workarounds on-stream for how to emit without running internal logic, then bake, then allow that logic to run only after it's been baked. https://www.twitch.tv/videos/1475546189?t=1h57m25s But both are kind of hacky, and would require the user of the logic to mess about with things unrelated to just using the built tool to create.
Apply Fleck Tool cannot apply the square fleck: https://www.twitch.tv/videos/1475546189?t=1h50m34s This is unexpected, as all other fleck types can be applied after-the-fact. This means that we cannot apply the square fleck to any existing paintings, or paintings that were converted from sculpts. Only new strokes can be square flecks. This is pretty frustrating for people who want to turn their old paintings into square-fleck paintings (eg. pixel art that was made with paint cannot be converted). Such paintings need to be created again from complete scratch if they want it to use the square fleck.
It also means if we make a square fleck stroke and then apply a different fleck to it, we cannot get back to the original square fleck.
I understand there are reasons that making the square fleck work for sculpts is a more involved process so that may or may not come in the future. But if we could apply the square fleck to just paintings that would save a lot of time and frustration for creators who want to use it.
-
But as I say, maybe a more "complete" 1:1 sun position representation would be cool as a new feature. (These are just my thoughts on the topic, don't take me seriously; Mm may think differently.)
My thoughts on a complete procedural sun position system; the logic of this can be broken down into three functional blocks:
- Calender / Sidereal conversion. For Earth's sky the direction of processing for this is calendar to sidereal - it takes a Date & Time fat wire and outputs a sidereal time of year and a sidereal time of day. It has to deal with the edge cases of the Gregorian Calendar and the fact that northern winter solstice doesn't coincide with new year exactly. The new features of 2.44 don't simplify this. For alien skies, the sidereal time of year and sidereal time of day are raw inputs, this functional block works in the opposite direction, and it's also optional - you don't have to invent an alien calendar if you don't want to.
- Sun Position Calculator. Takes the sidereal time of year and sidereal time of day - raw inputs or outputs of the previous block - and combines them with three more raw inputs - latitude, longitude, and axial tilt - to produce two outputs: sun azimuth and sun elevation. The new features of 2.44 don't simplify this either. But they could have. One more new calculator function in the vector operations tab - rotate vector by orientation - would have simplified it a lot.
- Sun Position Effector. Takes the sun azimuth and sun elevation and makes the sun appear at that position. This is where the new features of 2.44 are a huge win. You can probably make this functional block with one logic gadget - a Sun & Sky. Pre 2.44, you had to record Keyframes with the sun at nadir, zenith, and cardinal points on the horizon, and those were difficult Keyframes to record - the sun position couldn't be aligned to the grid. And you had to do trigonometry to calculate the power values for the Timelines you put the Keyframes on. Pre 2.44 trigonometry. And we know what a pain that was.
Trigonometry functions accessibility
I seem to remember that the first incarnation of the Calculator Improvements item on the Trello mentioned mathematical constants. I understand why they didn't add these as calculator functions - no reason to waste a gadget's worth of thermo for something that you can do by typing a number into a tweak. But some other way of accessing mathematical constants - perhaps a cluster of shortcut buttons when typing a number - would have made it easier to use trigonometric functions. The constants would of course include pi / 180 and 180 / pi, and you could quickly set a tweak to one of those values and set the blend mode to modulate whenever you needed to convert between radians and degrees.
On the other hand, it could lead to some weird hacky uses to set such initial state--emitting a selector purely to create a selector that starts from C for example. Which seems hacky and unintentional. (Though an actual setting for which starts as default, and opening up these hidden initial states would be great as an official addition.) So some sort of option may be the best way of introducing this, so that people who like these hacky things or find some special use for this quirk can still do so... Not sure.
Indeed, the bake tool preserving the current state of the baked object's logic as its initial state is a thing that I've already found useful: https://indreams.me/element/owrvMZjyiBL.
-
Live Clone UI can be very confusing: (Below I just refer to sculpts, but I know paintings can also be "live" in a similar way.)
There is no explanation of what the highlighting represents, so the user has to guess and experiment and test for a while before it's even useful to them. I was utterly confused by the highlighting and needed help from chat (including Tad from Mm, username RbdJellyfish in the chat) to even get close to what it was trying to tell me.
You can watch me seeing all this for the first time on-stream, and how much difficult I had: https://www.twitch.tv/videos/1475546189?t=3h22m10s
As an explanation for readers who do not yet understand how this works... this is how it works:
While hovering a sculpt, it and some other sculpts are highlighted in the following ways:
Solid green for sculpts that will change if I edit the sculpt I am hovering over.
Flashing yellow-green for sculpts that are currently identical to the sculpt I am hovering over, but will not change if I edit the sculpt I am hovering over. But only while holding L1.
These are the things the user needs to go through to understand what the highlighting is telling them:
- Understand that normal clones and live clones are all considered identical unless a normal clone is edited.
- This highlighting is called "Live Clone Visuals" by Dreams. So my assumption was that it was telling me something about which sculpts were live clones and which weren't. That isn't the case. It highlights live and non-live sculpts. And the visual distinctions do not always match up to indicating a live vs non-live sculpt.
- I also thought that the highlighting may have been related to the "liven clone" shortcut. That perhaps the flashing sculpts were the ones that would become live if I use the shortcut. But that was not always the case.
- I did not even consider it being related to editing a sculpt, because while using the clone tool nothing would edit a sculpt. "I'm here to clone, not to edit" sort of thing.
- Needing to hold L1 to see the highlighting in some cases and not others meant the highlighting would disappear and appear seemingly at random, while I was trying to focus on figuring out what the highlighting meant. If you're hovering over a non-live sculpt, all other sculpts wouldn't be affected by editing it, so they would all be shown as flashing yellow-green, which means no highlighting works at all, unless you stumble upon holding L1 in that instance.
- Even once I'd figured out I needed to hold L1, it is easy to forget that I was hovering over a non-live sculpt and that's why the highlighting wasn't working and I needed to hold L1. So there were many false starts as I tried to piece together how the highlighting worked.
- Hovering over a live clone makes it and all the other live clones solid green, and non-live clones flashing green. This leads you to think that solid green = live, which is incorrect.
- Using "liven clone" makes all clones "live." Because you are now hovering over a live clone, editing the sculpt you're hovering over would change all the other clones because all the other clones are live. Therefore all the clones and the one you're hovering over will be solid green. This leads you to think solid green = live, which is incorrect.
- The fact that we need to hold L1 to see the highlighting in some cases can lead you into thinking it's related to the only available shortcut that uses L1--"liven"--and that the flashing sculpts will be the ones that will be changed by using the shortcut. This is incorrect.
- Using "unliven" makes the sculpt you are hovering over non-live. You're first hovering over a live clone so it and other live clones are green. You then use the shortcut. As this shortcut does not require holding L1, all highlighting disappears. This leads you to think they've all been unlivened. Or that you somehow used a shortcut to turn off highlighting. Or... something, who knows? It's a very confusing moment.
- Two slightly different shades of green are used, so it's easy to be momentarily mistake one for the other while the flash of the yellow-green is at full strength. Also, if there are non-identical sculpts in the scene that are also these shades of green that's going to get pretty confusing.
So without help, in order to understand anything about how to read the highlights, the user has to muddle through all of the above before they have a handle on how the highlighting works. There are multiple rules to how the highlighting itself works, which are difficult to work out unless you already know them. And needing to hold L1 sometimes but not all the times adds even more complication. There are so many dead-ends you can go down, so many ways to intuit the incorrect thing.
And before you've figured out all those rules by testing and guessing, the visuals are not useful to you at all.
There are no popups to guide the user, no tooltips to hint at what's happening. For most users there are no people in chat to make suggestions, and no Mm programmer to point them in the right direction. Looking back at my stream recording, even Tad had difficulty in accurately describing how it works. I don't know how long it would take the average person to figure this stuff out, honestly.
When I was figuring it out on-stream, I actually stumbled on the right answer in about 5 minutes. (Which still shows how difficult it was to understand, considering I'm an experienced dreamer and programmer, and had plenty of people helping.) But chat was telling me it was different to what I thought, which was incorrect. So perhaps they thought they knew how it worked but didn't? Or maybe the rules are just that hard describe accurately? I just got all turned around and ended up thinking I didn't know what "Live" even meant in the first place (which I actually did) XD
Suggestion: The way I would have it work is the following...
You go into clone mode, and by default visuals are off. If you turn them on, they're always on. The rules for highlighting are as follows:
Hover over a sculpt and live clones of it are shaded green.
Non-live clones of it are shaded blue.
For good measure, everything that isn't an identical sculpt is shaded grey.
And that's all. Very simple, pretty intuitive as to what they could mean, shouldn't take more than a few seconds or a simple test to get the entirety of the rules correct. Using the shortcut to make all sculpts live will just make them all go green. Using the shortcut to unliven a sculpt will make that sculpt go blue.
Also, put a complete explanation into the "live clone visuals" button's popup.
Â
Liven Clone: (L1+triangle)
Unless only 1 object will become live by using the tool, the name should be plural as "Liven Clones." This would help people understand how it works also--to expect it to not just liven the one sculpt being hovered over, but multiple.
Even then, it's not made clear that all similar sculpts will turn into live clones. So it may be better to call it "Liven All Clones."
Currently we can only liven all clones. This means if we have 20 non-live clones of a sculpt and we want 2 of them to be live clones of each other, we need to make all 20 into live clones using the shortcut and then make 18 of them non-live clones one by one.
Even if technically editing a live sculpt that has no other live sculpts wouldn't do anything special, the user can simply pick and choose which sculpts they want to be live. And there's no harm in allowing just 1 live clone in a set to exist in the scene. It won't change any behaviour. If all clones are live, L1+triangle would be ignored but triangle will work so the Unliven shortcut will be used instead. If the sculpt is non-live, L1+triangle would make it live again.
Unliven: (triangle)
Here, we can only use it on a single sculpt. So again, if we had 20 live sculpts and we wanted them all to be non-live, we'd have to use it 20 times.
If you don't have button prompts on, and don't know if a particular sculpt is live or not, there's no way of knowing what using triangle will do if you use it on the sculpt. And that's even with the visuals turned on--as no matter what, the sculpt you're hovering over will show as green. Triangle could unliven it, or it could delete it.
Shortcuts doing different things at different times isn't good for building up the muscle memory of those shortcuts. It's hard to feel "safe" using them without relying on button prompts.
Live/Non-Live Sculpt Editing Setting: An idea I've had for a while now (but the post seems to have disappeared from the archives)... is to make the live/non-live stuff work in a fundamentally different way. A way that would be more powerful, intuitive to use, and requires no special tools like the clone tool to use it.
-
Luma Noise: In my research, my understanding is that "luma noise" is variation in brightness/luminance, and "chroma noise" is variation in hue/colour/chrominance. According the the popup in-game, the "Luma Noise" setting turns on and off the variation in colour (hue), not brightness. So should it more accurately be named "Chroma Noise"?
-
IK-to-FK / FK-to-IK hard to figure out how to use it: There is no tooltip, prompt, or popup regarding how to get access to this feature. Luckily I had chat to tell me how it's done, but without them I don't know how long it would take me to figure this out, or if I would have just given up. Most users of Dreams don't watch the streams telling them how it's done, most don't check the patch notes and watch the videos to see it demonstrated. I only watched the streams with a half-eye on them and half watching chat so I missed some of the details. But even with that bit of knowledge before going in, I couldn't figure out how to get started.
Here's me flailing around trying to work it out: https://www.twitch.tv/videos/1475546189?t=4h37m27sÂ
-
Trigonometry needs a radian/degrees toggle, not one or the other. Everything in dreams already is based off of degrees though but now that the calculator was released with radians as default you cant just switch it with an update, radians has to be the default of the calculator and degrees as a toggle, kind of like the splitter with rotations and orientations output.Â
An initial bake state as tapgiles suggests would be nice as an option, not a complete replacement as tap seems to suggest from his language. Baking something with logic running was the whole point of the tool. -
Radians: When a scene is loaded up for editing that's an old version there is a conversion step that runs to turn it into the latest version. So you can have the default be degrees. Then for upgrading existing calculators when entering edit mode, you could set its radians/degrees setting to radians. I think that's the kind of thing they've done in the past--like for when gadgets got the "big gadget" setting, which defaults to off, but old gadgets would have it turned on when upgrading.
Optional baking without initial state: I agree, the feature change should be an option. I said this in my comment; you may have missed it:
On the other hand, it could lead to some weird hacky uses to set such initial state... So some sort of option may be the best way of introducing this, so that people who like these hacky things or find some special use for this quirk can still do so.
-
TAPgiles Luma Noise: In my research, my understanding is that "luma noise" is variation in brightness/luminance, and "chroma noise" is variation in hue/colour/chrominance. According the the popup in-game, the "Luma Noise" setting turns on and off the variation in colour (hue), not brightness. So should it more accurately be named "Chroma Noise"?
Counter point: luma noise sounds cooler.
-
Thank you so much for all your in-depth feedback JCGoomba TheBeardyMan TheNamelesGhst12 TAPgiles NeonTheCoder! đ I've passed it onto the team who worked on Create Mode TLC #2! đ
Vous devez vous connecter pour laisser un commentaire.