- User Since
- Jul 1 2019, 4:50 PM (73 w, 3 h)
Mon, Nov 9
Not sure what you mean, treat zero as AO disabled?
Fri, Nov 6
Oct 9 2020
Oct 1 2020
Sep 23 2020
Sep 9 2020
Jul 24 2020
It would mean selecting in the middle of the bone could miss the bone
Jul 22 2020
Selecting bones using their wire. (we probably don't want to do this, just noting that it could work, perhaps wire as a first pass, then depth as a second pass if the first pass fails)
Jul 15 2020
Whatever happened to this? What we're asking is simple. Let bones be selectable by the closest wire to the mouse cursor, like Objects in wireframe mode already are, not just by their closest zdepth surface.
Jun 5 2020
Please let this go on 2.83 lts
Feb 12 2020
Another quirk is that, if you're using just 1 flow object, you seem to be able to change the color of the smoke sim a posteriori after simulating. Maybe it's a clue
Feb 4 2020
Feb 3 2020
Jan 23 2020
Tried it on 81b7f8efaf7a from Jan20th and it still happens after rebaking
Jan 17 2020
Might be addon related. Happened on 2.82 only after importing the settings from 2.81
Jan 13 2020
One thing you can do with the current Multiresolution is modify the base mesh without losing or corrupting the already scupted parts in higher levels, you can add extra edgeloops, extrusions... I hope you guys don't break that
Jan 10 2020
Jan 8 2020
Dec 13 2019
Oct 31 2019
Oct 24 2019
Oct 8 2019
It's a shame that every time something is suggested, it's always turned down if it looks like it will interfere with a future deep systemic change. The problem is that those deep systemic changes take a long while to come to fruition or never happen at all. Think of all the modifiers that are in the burner because the modifier system is always promised to be replaced. A lot of times not having a feature in the present hurts Blender more than dealing with maintaining that feature through systemic changes in the future.
Oct 2 2019
Update. Tip Selection mode seems to work. And you can press A in Path selection mode. The only one that seems broken is Key selection mode.
Sep 27 2019
Sep 26 2019
In terms of UV packing and UV unwrapping, it's common in other software to have a progressive heuristic solver. Something that you let run for a couple of seconds until you're satisfied with the result.
All those things may make it less noticeable but it doesn't solve it. More samples don't make it converge either.
Here's an example with with big radius, higher res shadows, soft shadows, lots of sss samples and viewport/render samples, high bitdepth, etc. Still visible
Sep 25 2019
Sep 18 2019
I remember an old Gsoc or something like that that had GPU generated children, it was like a modifier. Really cool. I wish we had that, for the viewport and editing. Even if it doesn't match the same seed as the Render and Render uses CPU
Sep 9 2019
Sep 6 2019
+1 for renaming files to come back
Sep 4 2019
Sep 3 2019
Right now I'm working in something architectural that involves constantly tweaking the position of buildings to know where sun light and shadow falls, and Eevee's shadows are accurate enough that I don't have to switch to full a rendered Cycles view, which would be slower in this asset heavy scene. But I do use the full rendered view as well. This is more about feedback in the viewport than rendering a playblast. Could you still do it in this new design? Sure, only if you switch to eevee as the default render engine.
Aug 28 2019
Please don't remove Use Scene Lights/World from the Material preview. I already outlined good reasons above. Please.
Aug 22 2019
That's a known limitation https://docs.blender.org/manual/en/latest/render/eevee/limitations.html#subsurface-scattering
Aug 21 2019
While I'm happy that previewing materials with HDRI and Eevee is back, now there's the opposite issue if you remove Use Scene Lights from the 3rd shading mode. Being able to see the scene lights with Eevee when authoring Cycles materials is also useful (eg the specular from light sources is more accurate than the HDRI, or the sharp contrast of lights might be better sometimes) Both things are useful. And this new change, while an improvement over the past version of the document still looks like a middle ground compromise, politician style, that doesn't improve over what exists just for the sake of semantics. To summarize, see this chart:
Aug 16 2019
The checkmark + value proposal esentially puts two things in one row, going against the new philosophy for animated properties. What would the keyframe icon on the right do, would it animate the checkmark or the value? Center alignment looks good otherwise, and addressing excesive nesting is something that could be tackled in the future in another design task.
Aug 9 2019
Aug 8 2019
Thank you! @Brecht Van Lommel (brecht)
I feel this is important and it's not being addressed or acknowledged despite being the third time I bring this up. Please acknowledge this, even if to tell me I'm crazy. This design is saying to me that I should not be allowed to lookdev Cycles materials with an Eevee preview, like it's somehow wrong or a second class thing to do even though I constantly check Cycles materials using Eevee in the current Lookdev mode, when the shaders are not too different. All I see is two or three extra step that will make that more cumbersome, as it hasn't been properly explained what the Eevee preview mode will do. Will it...?:
Aug 7 2019
His first point echoes what I said. In this current design, you can't change HDRI in Fast view without switching to Rendered first.
Let's say I'm using Cycles, but using the Fast preview mode with Eevee underneath. How would I change HDRI and toggle lights on Fast Preview? They are not in the popover so I would have to click on Rendered mode, open the popover and change the HDRI, and then go back to Fast preview? Not having the HDRI toggles and selector affects more negatively Fast preview/Lookdev than it does Rendered view. And if you put Eevee settings in Fast preview together with the HDRI and toggles, then it would make the popover too long.
Aug 6 2019
Aug 2 2019
From the developers point of view, I would first focus on the drawing mode and snapping to start with. These are the low hanging fruit but the most important ones, they don't need to be bound to retopology.
Aug 1 2019
I agree that it should be part of Edit mode. At certain point meeting halfway between what it's easier for the developer and what's best for the user steers too much into the developer side. The same way flat design is popular because it's easier to produce and mantain, not because of the end user.
Jul 25 2019
Jul 24 2019
Jul 19 2019
Jul 18 2019
How does this tie with the future of rigging? Currently it's very hard to have a base set of deforming bones and swap the rig around it, similar to what Source Filmmaker does. You can't swap Object data because the dropdown doesn't allow for that, nor can you do it swapping Armature data, because constraints and other rigging values are stored on an object/bone level, not on the armature. You have to duplicate the Armature object, along with all its children objects if you don't want to rebind each object to it. Could rigs be their own datablock or something like that? I heard stuff about rig compilation, would the new nodes even allow for that?
Jul 15 2019
how would I go about doing this in 2.8?
Jul 8 2019
This is 66684bdff30f, you can't adjust Span, and offset basically controls both density and orientation.